TRINITY: A 0.6B-Parameter "AI Foreman" That Coordinates GPT-5, Gemini, and Claude
TL;DR: Sakana AI used a 0.6B-parameter small model plus a ~10K-parameter lightweight head as a "commander" over top-tier large language models, achieving 86.2% SOTA on LiveCodeBench—without ever touching the closed-source models' weights.
Why This Matters
You may have heard of "model merging"—blending weights of several models hoping for 1+1>2. But this path has a fatal flaw: different companies use different architectures, and for closed-source APIs you simply cannot access the weights.
TRINITY's idea: if you can't merge at the parameter level, collaborate at inference time.
Imagine a hard coding problem. GPT-5 writes good 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 a single model, let a small "foreman" orchestrate—GPT-5 writes code, Gemini checks the math logic, Claude does final review. That's the core idea of TRINITY.
Architecture: Minimalism Wins
| Component | Parameters | Role | |------|---------|---------| | Backbone SLM | 0.6B (Qwen3-0.6B) | Extract contextual representation of input | | Lightweight head | ~10K | Pick which model + what role to assign | | SVD fine-tune | <10K | Fine-tune the SLM's singular value scales | | Total | < 20K | All learnable parameters |
You read that right: the entire coordinator has fewer than 20,000 learnable parameters, versus trillions in GPT-4-class models. Yet this tiny thing directs giants like GPT-5, Gemini-2.5-pro, and Claude-4-Sonnet.
Key Design: Hidden-State Driven
TRINITY generates no text. It only looks at the penultimate token's hidden state from the SLM, then the lightweight head makes two decisions:
1. Which model to select (from a pool of LLMs) 2. What role to assign (Thinker / Worker / Verifier)
A neat observation from the paper: the penultimate token's hidden state already encodes sufficient context, since self-attention lets it attend to the whole sequence. Using the last token (usually EOS) causes performance to plummet—EOS semantics are too sparse.
Three-Role Collaboration: Thinker → Worker → Verifier
🧠 Thinker (Strategist)
- Analyzes current state
- Proposes high-level plans, decomposes tasks
- Can specify who acts next and what to do
- Directly solves problems
- Writes code, does derivations, produces numeric results
- Produces actionable intermediate outputs
- Checks whether the current solution is correct and complete
- 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 via fitness-weighted aggregation
- Gradient-free, black-box optimization
- A linear SVM perfectly classifies task types (well above the 0.25 random baseline)
- t-SNE shows clearly separated clusters
- The EOS token is a trap: using the last token's hidden state plummets performance because EOS semantics are sparse
- Role division matters: removing the Thinker role costs 6 points on MATH500
- Agent selection and role assignment are both indispensable
- Cost: each query calls multiple LLMs; token cost is higher than a single model. Token efficiency beats other coordination methods, but absolute cost is still non-trivial
- Latency: multi-round API calls mean higher latency; real-time scenarios may not be suitable
- Black-box fragility: if a called model's output distribution changes (e.g., OpenAI quietly updates it), the coordinator's decisions may degrade
- Training coverage: validated only on code/math/reasoning tasks; generalization to creative writing or 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
🔨 Worker (Executor)
✅ Verifier (Reviewer)
The loop runs at most K rounds (5 in the paper). Verifier passes → 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—use REINFORCE/PPO. But the authors found RL very hard to train here:
1. High parameter dimensionality (~10K), yet each parameter barely affects final reward 2. Sparse rewards (binary, only final answer correct/incorrect) 3. Extremely high per-step cost (each evaluation calls multiple LLM APIs)
Result: REINFORCE's gradient signal-to-noise ratio is too low to learn anything.
TRINITY's solution is separable CMA-ES:
The paper proves two key propositions:
> Proposition 1: In the small-iteration regime, sep-CMA-ES improves linearly with iterations, while random search improves only as log(number of candidates). > > Proposition 2: After roughly n calibration iterations, sep-CMA-ES enters a steady state, reducing remaining error by ~1/n per step.
Experiments confirm sep-CMA-ES significantly outperforms REINFORCE, SFT, and random search.
Results: SOTA + Zero-Shot Generalization
In-Distribution (seen during training)
| 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 scores 86.2% pass@1 on LiveCodeBench, beating GPT-5, Gemini 2.5 Pro, and Claude-4-Sonnet.
Zero-Shot Transfer (completely unseen tasks)
| 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 |
Beats every single model across the board. This shows TRINITY learned not a simple "which model for which task" routing, but a more fundamental collaboration strategy.
Core Insight: Two Kinds of "Separability"
1. Representation Separability
Using SVM and t-SNE analysis of the SLM's hidden states:
Different tasks' hidden states are highly separable in representation space—the foundation for the lightweight head's effective decisions.
2. Objective Separability
The authors tested heads of different structures:
| Head type | Params | Performance | |-----------|--------|------| | Linear (default) | ~10K | Best | | Sparse | ~10K | Nearly tied | | Block-diagonal-10 | ~1K | Moderate |
Most striking: block-diagonal-10 keeps competitive performance with only 1K parameters (10x fewer), indicating the coordination objective has strong block-ε-separability—each agent/role's decisions are relatively independent with minimal cross-interference.
Ablations: Every Component Necessary
| Variant | MATH500 | RLPR | LiveCodeBench | |------|---------|------|---------------| | TRINITY (full) | 0.91 | 0.45 | 0.61 | | Without SVD fine-tune | ↓ | ↓ | ↓ | | Without Thinker role | 0.85 | - | - | | Without all roles | 0.82 | 0.40 | - | | Using last token (EOS) | - | - | drops 10+ points | | Without agent selection | significant drop | significant drop | significant drop |
Key findings:
Why This Paper Matters
1. Proves "small brain directing big brains" works: a 0.6B coordinator can orchestrate GPT-5-class models, with the strategy itself learned via evolution 2. A new paradigm for model collaboration: not a simple router, 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 weights needed—just API access to build a TRINITY system