Goldenfish G1 started on a free T4 because that was the GPU we had. We were trying to build a small System One model for code review. The idea was simple enough to feel slightly rude to a language model. Give it code state and context, give it a typed question and the valid decisions, then make it choose. A structured decision did not need to become a paragraph before the model decided whether a change was safe.
The first prototype used microsoft/codebert-base with roughly 125 million parameters. Context was limited, the microbatch was small and gradient accumulation filled in for hardware we did not have. The setup was enough to test the interface. Code review was a narrow target, which made it a good place to ask whether direct typed choice was worth building at all.
Then Supersonic Labs published Julia 1. It put a Brazilian System One model into the world with a concrete interface, public benchmarks and a CPU path that people could actually try. We looked at it and asked the obvious question. Why were we limiting this idea to code review when the same interface could choose a route, a tool, a policy action or a label. Supersonic had put a target on the wall. We decided to make the problem larger.
That was the moment code review stopped being the whole story. Goldenfish became a general purpose typed decision model. It receives state and a typed question on the request side, candidates on the other side and returns scores or probabilities in one forward path. System One is an operational description for direct inference with no autoregressive decode and no requirement to produce a chain of thought. Jev at TypeSafe AI pioneered this direction. We were following that line with a different serving bet.
After the Colab runs, we used Modal signup credits that became available after adding a payment method. We were feeling unusually brave. That put an A100 80 GB within reach and changed the scale of the question. We could iterate on architecture, data, training recipes, benchmarks and serving until there was a real model to freeze. We did not have a frontier lab budget. We had a free T4, a few signup credits and a reason to run the next experiment.
Devin from Cognition was there for an unreasonable amount of this project. We used it across research, debugging, benchmark tooling, backend work, infrastructure and the plumbing between experiments. It compressed the distance between a question and a run we could inspect. The architecture and model decisions stayed with us. Devin helped us spend more time deciding what to test and less time making the next script behave.
What Goldenfish G1 is
Goldenfish G1 is a 576,164,355 parameter general purpose typed decision model built on the pretrained BAAI/bge-m3 backbone. The backbone accounts for 566,705,152 parameters and the heads and additional components account for 9,459,203. It is bidirectional and non-autoregressive. We kept the complete model near six hundred million parameters on purpose because latency belongs in the design from the beginning.
State and the typed question share a representation on the request side. Candidates receive separate representations that can be reused. When a catalog is stable, those representations can be computed once and cached. Goldenfish G1 scores candidates in parallel, projects through a 512 dimensional decision space and sends the strongest candidates through a two layer set or listwise mixer with eight heads. The current implementation uses refine_top_k = 8. A learned temperature turns the result into a probability distribution over the candidates supplied for that request.
Imagine an agent with forty tools. The request changes, the action inventory does not, and Goldenfish can keep the candidate representations ready while scoring the current state. The same pattern works for a router with hundreds of intents, a policy system whose valid actions change with context or a classifier that sees the same labels thousands of times. Ranking also fits naturally because the candidates arrive with the request. Goldenfish spends more parameters than a compact CPU specialist in exchange for a serving path where repeated catalogs can pay that cost back.
A simplified view of the final probability is
pi = exp(si / τ) / Σj exp(sj / τ)
The scoring equation is ordinary. The useful part is the interface around it. Goldenfish G1 can choose a policy action, route an intent, select a tool, rank documents or classify a ticket against candidates supplied at request time. One request can contain a small action menu and the next can contain a larger label inventory. The application owns the valid choices, which keeps the decision space close to the system that needs the answer.
Latency is one of the reasons this architecture exists. Earlier A100 BF16 measurements put uncached inference around 29 to 32 milliseconds and candidate cached inference around 15 to 16 milliseconds. A later harness using the frozen release checkpoint measured 12.77 milliseconds at model p50, 13.49 milliseconds at model p95 and 13.52 milliseconds end to end at p50, with about 73 decisions per second in a serial batch one setup and about 1.17 GB of peak VRAM. Goldenfish G1 also runs on CPU. In one Xeon 2.2 GHz test with two FP32 threads, cached candidates were about 250 milliseconds at p50 and the full request was about 259 milliseconds at p50. The first call with four candidates was about 567 milliseconds, and a context near 400 tokens took about 3.1 seconds in that measurement. That is practical for staging, lower volume, batch or applications where a few hundred milliseconds are acceptable. The value changes with context, candidate count, cache state and runtime. The low latency path we have measured most carefully is still the A100 path, where candidate caching removes a meaningful part of the request and serving lives in low tens of milliseconds.
The first real model
The first serious Goldenfish G1 corpus had 202,871 training rows, 10,547 calibration rows, 12,859 development rows, 12,905 test rows and 3,996 gauntlet rows. It was mostly English with about 19 percent Portuguese. The decision families covered commonsense multiple choice, contextual binary decisions, entailment, intent routing, ordinal scoring, policy decisions and ranking preference. The run used an A100 SXM4 80 GB and four main stages named stage1_contrastive, stage2_decisions, stage3_hardening and stage4_agentic. The prototype had become a general model with a real evaluation surface.
Stage 1 trained only part of the system and Stage 2 opened the full model. The result made the original idea hard to dismiss. Goldenfish G1 reached 78.98 percent development accuracy, 78.88 percent test accuracy, 75.57 percent test macro family accuracy, 0.5567 negative log likelihood, 2.41 percent expected calibration error and 45.77 percent gauntlet accuracy. A small bidirectional model had become a useful decision engine.
| Measure | Result |
|---|---|
| Complete model | 576,164,355 parameters |
| Backbone | BAAI/bge-m3 with 566,705,152 parameters |
| Development accuracy | 78.98 percent |
| Test accuracy | 78.88 percent |
| Test macro family | 75.57 percent |
| Negative log likelihood | 0.5567 |
| Expected calibration error | 2.41 percent |
| Gauntlet accuracy | 45.77 percent |
The first run was good enough to keep building and messy enough to demand better instruments. The effective family and language mixture drifted, out of distribution performance was weaker, checkpoint selection was fragile and calibration moved differently across slices. An INT8 export changed quality more than we wanted. Fast development subsets could make a run look healthier than the full evaluator. None of that made the premise smaller. It told us the training loop had to become worthy of the model.
Making the training catch up
G2 focused on making each training decision inspectable. Family and language sampling became explicit. Replay and hard example mining entered the loop. Checkpoints were separated into roles such as best_id, best_ood and best_composite. Forgetting guards, rollback, gradient diagnostics and per pool accounting turned the stages into measured steps toward a release.
We still broke the model more than once. An older checkpoint rule selected the weaker Stage 2 step 8000 snapshot at about 71.92 percent development accuracy, 70.94 percent macro family accuracy and 40.33 percent mini gauntlet accuracy, even though step 16000 reached about 76.73 percent development accuracy, 74.11 percent macro family accuracy, 41.87 percent mini gauntlet accuracy and 0.5903 negative log likelihood. Specialization then started from the wrong point. Stage 3 fell to about 68.48 percent full development accuracy and Stage 4 recovered to about 70.80 percent while improving some hard slices. The mistake made checkpoint choice part of the model, which is where it should have been all along.
We repaired stage initialization, checkpoint handling, forgetting guards and adaptive clipping. The corrected Stage 4 reached about 76.35 percent full development accuracy, 73.78 percent macro family accuracy, 42.73 percent mini gauntlet accuracy and 1.82 percent expected calibration error. Clipping fell to 8.2 percent across 1,000 optimizer updates, and that stage took about 18.1 minutes on the A100. The trace became readable again. That mattered because a readable training loop lets a good idea keep moving.
The simpler path produced the largest gain
By then the objective had accumulated cross entropy, contrastive, pairwise, ordinal, score, anchor, consistency, Brier and confidence terms. Gradient accounting showed cross entropy carrying most of the useful signal in many windows, with pairwise and anchor helping in some settings and several other terms contributing very little. The loss function had become more sophisticated than the evidence. We went back to controlled ablations and let the boring objective make its case.
The healthy control sat near 77.72 percent full development accuracy. Short cross entropy runs reached 77.62 percent at 500 updates and 79.37 percent at 1,500 updates. Cross entropy with distillation reached 78.64 percent at 500 updates and 79.78 percent with an NLI teacher at 1,500 updates. A longer cross entropy run reached 80.62 percent. That was enough evidence to spend the next serious run on the simple path. The same accounting showed why row count was a poor proxy for usefulness. Agentic examples could reach 93 to 99 percent training accuracy with almost zero gradient contribution, while hard mining on near random tasks could find failures that were difficult without being learnable.
The important run was dv_ce_xlong_seed1. It trained for 12,000 trainer steps and about 3,000 optimizer updates in that configuration. The final checkpoint reached 83.85 percent full development accuracy, about 80.9 percent macro family accuracy, about 1.6 percent expected calibration error and about 46.2 percent gauntlet accuracy. A paired analysis recorded 1,558 corrected examples and 478 regressions, for 1,080 net corrections and a relative error reduction near 31.1 percent. We had our strongest internal checkpoint yet.
At 83.85 percent, xlong earned a bigger test. Reasoning and commonsense families remained in the high 30s or low 40s on HellaSwag, ARC Challenge, OpenBookQA, ARC Easy and CommonsenseQA. The model was moving quickly on our full development suite, and the next useful question was whether the typed interface would travel with it.
The plot twist was transfer
Then we put xlong through the external Typed protocol used for the public Julia 1 comparison. It scored 727 of 2,000 decisions, or 36.35 percent. The 83.85 percent checkpoint had looked excellent until we put it somewhere it had never seen before. Typed ended the celebration efficiently and showed us the actual problem. We had trained a strong checkpoint for our own distribution and needed to teach the interface to travel.
We audited the protocol before changing the story. State and question were together as intended. Candidate criteria were separate. The audited examples showed no label leakage and no truncation. Permutation equivariance was correct. Changing refine_top_k did not explain the fall. The problem was transfer, which gave us a concrete training target. So we trained the problem we had actually found.
Teaching the interface to travel
The priority moved from another point on full development to transfer. Probe A, trained on the official Typed data for 400 updates, reached about 65.25 percent on Typed TEST and 82.98 percent on full development. A-long reached about 77.11 percent on Typed validation, 73.70 percent on Typed TEST and 81.16 percent on full development. A WiSE interpolation reached about 75.22 percent on Typed validation, 72.45 percent on Typed TEST and 82.44 percent on full development. The message was encouraging. Transfer was learnable, and the backbone could carry the interface when the training target matched the job.
Some obvious fixes stayed local. Synthetic rule gold did not resolve the mismatch, and a Qwen teacher path did not become a reliable universal recipe. Task specific probes were much stronger than the shared mixture on AG News, Emotion, native 72 way Banking77 and MASSIVE. That gap still gave us something valuable. The model could learn these interfaces in isolation, so the shared recipe had a real path forward.
The mix2 checkpoint carried the campaign further. On validation it reached about 78.78 percent Typed, 89.3 percent AG News, 81.0 percent Emotion, 89.94 percent native Banking77, 85.10 percent MASSIVE and 81.71 percent full development. A targeted Emotion campaign raised balanced accuracy near 90.2 percent in emo3, while Typed validation fell. That trade made the release decision concrete. We wanted the checkpoint that carried the external work across several surfaces.
Choosing Goldenfish G1
The release checkpoint came from a small interpolation between final_emo_b and mix2 with a weight of 0.05. It was chosen with the external transfer campaign in mind. Goldenfish G1 reaches 81.00 percent on the full development suite of 14,802 examples.
xlong remains the highest full development checkpoint trained in the project at 83.85 percent. Goldenfish G1 is the checkpoint we selected for release because it carried the external adaptation work more usefully. The difference is intentional. xlong won our internal race. Goldenfish G1 is the model we wanted people to run.
| Checkpoint | Full development | Why it matters |
|---|---|---|
| Stage 2 reference | 76.55 percent | Standardized baseline for later comparisons |
| xlong | 83.85 percent | Highest internal development score |
| Goldenfish G1 | 81.00 percent on 14,802 examples | Frozen release checkpoint after external adaptation |
The score on the wall
Supersonic Labs published Julia 1 and put a concrete public target on the board. We had signup credits from Modal and a model that kept asking for another experiment. This was a mildly dangerous combination. Julia 1 deserves credit for making the comparison possible in the first place. It uses mmBERT-small, has about 144.3 million parameters and has a CPU friendly public path that chooses among supplied answers.
The comparison covers four benchmarks: Typed decisions, AG News, DAIR Emotion and MASSIVE. The global, pt-PT and en-US MASSIVE rows are an aggregate and two locale slices of the same benchmark, not independent wins. Typed is effectively tied: Goldenfish G1 answered 1,464 of 2,000 decisions correctly, or 73.20 percent, against Julia 1's reported 1,463, or 73.15 percent. That one-decision difference does not establish superiority. AG News was 95 of 100 against 94, and DAIR Emotion was 90 of 100 against 86; both are small pilots. The largest reported numerical gap is on MASSIVE global, at 82.70 percent against 71.50 percent. MASSIVE pt-PT was 87.29 percent against 86.25 percent, and en-US was 88.03 percent against 86.75 percent.
Evaluation caveat: Typed TEST was consulted repeatedly during the adaptation campaign. Its final release score is an adaptation measurement, not an untouched estimate of generalization. A generalization claim would require evaluating the frozen checkpoint on an untouched test set.
AG News and Emotion each use 100 examples, so their observed differences do not establish a reliable advantage on new data. MASSIVE has a larger numerical gap, but Julia 1's exact prompt formulation is not fully reproducible from the public page; the reported values are not a controlled comparison under an identical harness. Banking77 is excluded because Goldenfish G1 used a native 72-way evaluation and Julia 1 reported narrowing or shortlist behavior. These results describe the evaluated workloads, not general superiority over Julia 1.
The architectural difference is the reason both models have a place. Julia 1 is compact, uses mmBERT-small and is tuned for CPU friendly decisions over small candidate sets. Its public interface accepts two to twenty answers and includes a Router for larger lists. Goldenfish G1 is larger, uses BAAI/bge-m3, keeps state and question on the request side and gives candidates reusable representations with parallel scoring. Julia is a strong fit when a few options need direct interaction with the state on ordinary hardware. Goldenfish is built for systems where the same tools, labels or actions appear repeatedly and candidate caching can change the economics of inference.
Julia optimizes one part of the curve very well. Goldenfish G1 optimizes another. Julia makes a compact CPU decision engine feel practical on ordinary hardware. Goldenfish also runs on CPU, while its low latency path is currently GPU oriented because the architecture leans on parallel candidate scoring and reusable candidate representations. The comparison is useful because it shows two serious ways to make typed decisions without turning them into prose.
One boundary for the next model
After freezing the release, we went looking for the next problem with the public Open Jev Snake evaluation. The validation contains 848 rows, with 785 one hot rows after Choice ties are removed from the hard accuracy denominator. Goldenfish G1 scored 407 of 785, or 51.85 percent hard accuracy. The result points to a specific boundary around low option state to candidate binding.
Julia 1 was much stronger on this kind of decision in the same public harness. Goldenfish G1 is designed around reusable candidate scoring, while unfamiliar low option relational binding asks for deeper interaction between state and each option. Those are different demands on an encoder. Our first small interaction branches did not pass the go or no go test. Good. We know what the next model has to work on.
Changing refine_top_k from 8 to 16, 32 and all barely moved full development, and the relevant high candidate families already had Recall at 8 near 0.988. The current evidence points toward representation and interaction quality. That gives the next model a clean target.
Goldenfish G1
Goldenfish G1 is a 576,164,355 parameter general purpose typed decision model built on a pretrained BAAI/bge-m3 backbone. It is bidirectional and non-autoregressive. It accepts state and a typed question, receives candidates at request time, reuses candidate representations when the catalog is stable and scores those candidates in parallel before a small refinement path produces typed probabilities.
The release carries a measured training history. G1 established the baseline near 79 percent. G2 made the training loop serious. Simplifying the objective produced xlong at 83.85 percent internally, and Typed redirected the work toward transfer. Goldenfish G1 settled at 81.00 percent on the full development suite because it carried that adaptation campaign more usefully. The release checkpoint was chosen for the model we wanted to ship.
On the A100 paths we measured, Goldenfish G1 runs in low tens of milliseconds and candidate caching changes the serving economics when inventories repeat. The comparison with Julia 1 shows an effective tie on Typed, small differences in the classification pilots and a larger reported gap on MASSIVE global, with protocol limits that prevent a general superiority claim. Those measurements help define where to evaluate Goldenfish G1 for routing, tool selection, policy decisions or ranking.
We started with a free T4, used signup credits from Modal after adding a payment method and kept the scope disciplined enough to develop a real model. Goldenfish G1 is the first checkpoint of an Aspas Labs model line built around choices that do not need to become prose. It has 576,164,355 parameters, candidate caching, parallel scoring and a measured A100 path in low tens of milliseconds. We wanted to know what a small team with a free T4 and a handful of signup credits could build. The answer is Goldenfish G1.
The Goldenfish G1 weights are now open on Hugging Face. We will make the API available as quickly as possible.