TRINITY: A 0.6B-Parameter "Foreman" That Coordinates GPT-5, Gemini, and Claude
> TL;DR: Sakana AI used a tiny 0.6B-parameter model plus a ~10K-parameter lightweight head as a "commander" of frontier LLMs, achieving a SOTA 86.2% on LiveCodeBench—without ever touching the closed-source models' weights.
Why This Is Cool
You may have heard of model merging—blending weights from several models hoping for 1+1>2. But it has a fatal flaw: models from different companies have different architectures, and for closed-source APIs you simply cannot access the weights.
TRINITY's idea: since parameter-level fusion is impossible, do the coordination at inference time.
Imagine a super-hard programming problem. GPT-5 writes great code but misses edge cases; Gemini has strong math reasoning but an academic coding style; Claude reviews code well but is sometimes overly cautious.
Rather than betting on one model getting everything right, let a small "foreman" dispatch work: GPT-5 writes code, Gemini checks the math logic, Claude does the final review. That is TRINITY's core idea.
Architecture: Minimalism Wins
| Component | Size | Purpose | |-----------|------|---------| | Backbone SLM | 0.6B (Qwen3-0.6B) | Extract contextual representation of the input | | Lightweight head | ~10K | Pick which model + assign its role | | SVD fine-tune | <10K | Tune singular-value scales of the SLM | | Total | < 20K | All learnable parameters |
Yes, under 20K learnable parameters total—versus trillions in a GPT-4-class model. Yet this tiny coordinator directs GPT-5, Gemini-2.5-Pro, and Claude-4-Sonnet.
Key Design: Hidden-State Driven
TRINITY generates no text. It only reads the penultimate token's hidden state from the SLM, and the lightweight head makes two decisions:
1. Which model to call (picked from the LLM pool) 2. What role to assign (Thinker / Worker / Verifier)
A neat observation from the paper: the penultimate token's hidden state already encodes enough context, because self-attention lets it attend to the entire sequence. Using the last token (usually EOS) causes performance to plummet—EOS semantics are too sparse.
Three Roles: Thinker → Worker → Verifier
- Thinker (strategist): analyzes the current state, proposes high-level plans and task decomposition, specifies who acts next and on what.
- Worker (executor): directly solves subproblems—writes code, derives, computes—producing actionable intermediate results.
- Verifier (auditor): checks correctness and completeness, outputs ACCEPT or REVISE. If ACCEPT, the process terminates.
- Maintains only a diagonal covariance matrix (assuming weak parameter coupling)
- Samples a batch of candidate solutions per generation, updates weighted by fitness
- Gradient-free, black-box optimization
- A linear SVM perfectly classifies task types (far above the 0.25 random baseline)
- t-SNE shows clearly separated clusters
- EOS token is a trap: using the last token's hidden state collapses performance—EOS semantics are too sparse.
- Role specialization matters: removing the Thinker drops MATH500 by 6 points.
- Agent selection and role assignment are both indispensable.
- Cost: each query calls multiple LLMs; token cost exceeds a single model. Token efficiency is better than other coordination methods, but absolute cost is still nontrivial.
- Latency: multi-round API calls mean higher latency—real-time scenarios may not fit.
- Closed-source black boxes: if a called model's output distribution shifts (e.g., a silent provider update), the coordinator's decisions may degrade.
- Training coverage: validated only on code/math/reasoning tasks; generalization to creative writing and dialogue is unknown.
- Paper: Trinity: Evolutionary Large Language Model Coordination via Lightweight Hidden-State Routing
- Authors: Jinglue Xu, Qi Sun, Peter Schwendeman, Stefan Nielsen, Edoardo Cetin, Yujin Tang (Sakana AI)
- arXiv: https://arxiv.org/abs/2512.04695
- Institutions: Sakana AI (Japan), University of Michigan, Institute of Science Tokyo
The loop runs at most K rounds (K = 5 in the paper). Verifier pass → done. Budget exhausted → return the last round's result.
Why Evolutionary Strategies (CMA-ES) Instead of RL?
The natural idea: this is sequential decision-making, so use REINFORCE/PPO. But the authors found RL extremely hard to train here:
1. High parameter dimension (~10K), yet each parameter barely affects the final reward 2. Sparse rewards (binary right/wrong on the final answer only) 3. Very high per-step cost (each evaluation calls multiple LLM APIs)
REINFORCE's gradient signal-to-noise ratio is too low to learn.
TRINITY uses separable CMA-ES (separable Covariance Matrix Adaptation Evolution Strategy):
Two key propositions are proven:
> Proposition 1: In the small-iteration regime, sep-CMA-ES improves linearly with iterations, while random search scales only as log(number of candidates). > > Proposition 2: After ~n calibration iterations, sep-CMA-ES reaches a steady state, reducing remaining error by roughly a 1/n fraction per step.
Experiments confirm sep-CMA-ES clearly beats REINFORCE, SFT, and random search.
Results: SOTA + Zero-Shot Generalization
In-Distribution
| Task | TRINITY | Runner-up | Relative error reduction | |------|---------|-----------|--------------------------| | MATH500 | 0.91 | Gemini 2.5 Pro (5x budget) | 11.76% | | MMLU | 0.88 | - | - | | RLPR | 0.45 | MoA | - | | LiveCodeBench v6 | 0.862 | GPT-5 (0.838) | New SOTA |
TRINITY hits 86.2% pass@1 on LiveCodeBench, surpassing GPT-5, Gemini 2.5 Pro, and Claude-4-Sonnet.
Zero-Shot Transfer
| Task | TRINITY | Best single model | |------|---------|-------------------| | AIME2025 | 50.00 | 40.00 | | BigCodeBench | 35.80 | 32.00 | | MT-Bench | 9.60 | 9.20 | | GPQA-D | 76.82 | 69.00 |
It beats the best single model across the board. This suggests TRINITY learned something more fundamental than "which model for which task"—a genuine collaboration strategy.
Core Insight: Two Kinds of "Separability"
1. Representation Separability
Using SVM and t-SNE on the SLM's hidden states:
Task hidden states are highly separable in representation space—the foundation for the lightweight head's effective decisions.
2. Objective Separability
Different head structures were tested:
| Head type | Params | Performance | |-----------|--------|-------------| | Linear (default) | ~10K | Best | | Sparse | ~10K | Nearly tied | | Block-diagonal-10 | ~1K | Moderate |
Strikingly, block-diagonal-10 with only 1K parameters (10x fewer) stays competitive. The coordination objective has strong block-ε-separability—per-agent/role decisions are largely independent with minimal cross-interference.
Ablations: Every Component Matters
| Variant | MATH500 | RLPR | LiveCodeBench | |---------|---------|------|---------------| | Full TRINITY | 0.91 | 0.45 | 0.61 | | No SVD fine-tune | ↓ | ↓ | ↓ | | No Thinker role | 0.85 | - | - | | No roles at all | 0.82 | 0.40 | - | | Last token (EOS) | - | - | drops 10+ points | | No agent selection | significant drop | significant drop | significant drop |
Key findings:
Why This Paper Matters
1. "Small brain commanding big brains" works: a 0.6B coordinator can direct GPT-5-class models, with the coordination policy learned via evolution. 2. A new paradigm for model collaboration: not a router doing simple routing, but stateful, multi-round, role-based collaboration. 3. Evolutionary strategies win in high-dimensional, sparse-reward settings—a methodological breakthrough that may inspire the RL community. 4. Extremely friendly to closed-source API users: no model weights needed—just APIs.