The ten-thousand-parameter decision

Ten thousand parameters.

That's the routing head. The part of Trinity that decides which model to call, when to call it, and what role to assign it. Ten thousand parameters — smaller than the CSS file that styles this page. And it outperformed GPT-5, Gemini 2.5 Pro, and every individual model in its pool.

The scale difference is absurd.

Three roles. One decision at a time.

Trinity doesn't generate answers. It coordinates. At each step of a multi-turn process, the routing head assigns one of three roles to a model from its pool: Thinker — devises strategy and analyses state. Worker — executes problem-solving steps. Verifier — evaluates whether the solution is complete and correct.

The routing head doesn't need to be smart. It needs to know who to ask. That's a routing problem, not a reasoning problem. And routing problems can be solved with very few parameters — if the graph of available specialists is rich enough.

It wasn't trained. It was evolved.

The routing head was optimised through CMA-ES — an evolutionary algorithm, not gradient descent. The team at Sakana AI didn't backpropagate through the router. They evolved it, generation by generation, selecting the routing strategies that produced better outcomes. The same mechanism as article 03 — selection beats blending. The same mechanism as the Ren & Stimpy swarm — generate many, select the best, discard the rest.

The routing head is the Mr Horse of the system. Small. Focused. Its entire job is to say "not this one, try that one" until the right model gets the right role for the right step.

Then it generalised.

Without any retraining, Trinity transferred zero-shot to four unseen tasks: AIME (mathematics), BigCodeBench (coding), MT-Bench (multi-turn conversation), and GPQA (graduate-level science). The evolved coordinator surpassed every individual model in its pool on average — including GPT-5 and Gemini 2.5 Pro.

The routing head had never seen these tasks. It had never been trained on them. It just knew how to route — and routing, it turns out, is a generalisable skill. Learn the graph, not the task.

This is the architecture Alan is building.

Intershapes is a routing layer. The surfacing system — the thing that decides what to show, when, and from which specialist — is a router across a graph of knowledge and agents. It doesn't need to be a frontier model. It needs to know the edges: which specialist for which problem, which context for which task, which fragment for which query.

Trinity proves the principle: a tiny router pointing at a pool of specialists can beat any single specialist. The intelligence isn't in the router. It's in the graph it routes across. The edges — which model, which role, which step — are where the meaning lives. Same thesis as article 08. Now with evidence.

And it connects to sovereignty.

If the router is small enough to run on a Mac mini, and the specialists can be small models running locally, then the entire orchestration layer — the part that decides who does what — is yours. You don't need a cloud API to route. You need a 10K-parameter head and a graph of specialists you control.

The frontier model isn't the future. The router is. And the router is small enough to own.

Trinity is the proof. A 10K-parameter head, evolved not trained, coordinating models it was never fine-tuned for, beating every one of them on average across tasks it had never seen. The intelligence was never in the parameters. It was in the routing — the edges between the specialists, the decisions about who to call and when.

The same principle that powers the Spumco swarm. The same principle behind Intershapes. The same principle Alan is betting the architecture on. Generate many, select one, route to the right specialist. The intelligence is in the loop — and the loop is small enough to run on your desk.