There are now dozens of capable language models, and they are not interchangeable. The most expensive models cost several times more per task than the cheapest ones, and the gap in quality between them depends heavily on the work. On some tasks a small model is as good as anything available. On others it fails most of the time, and only a frontier model will do.
Most teams handle this the simple way: they pick one model and send everything to it. Usually it is the strongest model they can afford, because a wrong answer is easy to picture and an inflated bill is not. Testing every workflow on every model, and doing it again each time a provider ships a new one, is not something most teams have time for.
A router can take over that job. It sits between an application and the model providers and decides, for each request, which model should handle it. The hard part is not routing; it is knowing which model to route to. That knowledge is specific to each kind of work, it changes as models change, and nobody hands it to you.
This post asks a narrow question: can a router learn which model to trust from the results of its own work, without labels and without being told anything about the models? We built one, Sovereign, and tested it on eight public benchmarks against the two choices a team would otherwise make by hand: always use the frontier model, or always use the small one.
We find that it can. On programming and logic, Sovereign matches or exceeds frontier accuracy while spending a fraction of what the frontier model costs. On long industrial and finance workflows it lands between the two, far ahead of the small model for a third of the frontier's price. Where a small model is already good enough, it learns that too. And it gets better the more it works.
Why choosing a model is hard
The cost of a default
Frontier models are priced for the hardest work they do, and most work is not the hardest. A team that sends everything to the strongest model pays frontier prices for questions a model a fraction of the price would answer just as well. A team that sends everything to a small model saves money and quietly loses the cases that needed the big one. Neither default is wrong everywhere; each is wrong somewhere, and the team rarely knows where. Even the ordering is not fixed: on one of our coding benchmarks the small model scored as high as the frontier model.
Fixed rules go stale
The obvious fix is a rule: send easy requests to a small model and hard ones to a large model. In practice "easy" and "hard" are not properties of a request. They describe how a particular model does on a particular kind of work, and they move every time a model is released or repriced. Nobody notices until the bill or the error rate does.
Learning without labels
If rules go stale, the alternative is to learn from outcomes. But outcomes are rarely labeled. In production there is no answer key telling you whether a model's reply to a customer, or its fix to a bug, was right. A router that learns has to judge the work itself, reliably enough that the lessons it draws are true.
That is the design Sovereign follows, shown in Figure 2. Every request goes to the model it picks. Sovereign grades every finished piece of work, using a model that never sees an answer key. Those grades build up a record of what works for each kind of work, and the record shapes the next choice.
Nobody labels anything, and nobody tells Sovereign which model is good at what. Learning does require trying, and trying has a cost; we return to whether that cost is worth paying in the discussion.
What we find
Across eight benchmarks covering programming, logic, reasoning, knowledge, and long manufacturing, semiconductor and finance workflows, we find that:
- On programming and logic, Sovereign reaches frontier accuracy at a fraction of frontier cost. On both programming benchmarks and on logic puzzles it matched or beat the accuracy of Claude Opus 5.5 while spending 30% to 51% of what Opus did.
- Against Opus, Sovereign spent 43% to 81% less on every benchmark.
- Against Claude Haiku 5.5, Sovereign was more accurate on every benchmark, by up to 55 percentage points where the work was hard.
- On long manufacturing, semiconductor and finance workflows, where the frontier model still leads, Sovereign cut cost by roughly two thirds and stayed well ahead of the small model, doubling its score on corporate finance.
- Sovereign improves with use. On competitive programming its accuracy rose steadily from 88% to 97.7% as it learned, passing Opus along the way.
- Where a small model is nearly as good as the frontier, Sovereign learns to lean on cheaper models and stays within four points of frontier accuracy, and within about a point on reasoning puzzles, for a fifth to just over half of the cost.
- Routing costs little in speed. Sovereign was faster than Opus on six of the eight benchmarks.
Methods
We designed the experiments to compare Sovereign against the choices a team actually faces, on equal terms:
- We ran eight public benchmarks three ways: through Sovereign, with every task sent to Claude Opus 5.5, and with every task sent to Claude Haiku 5.5. Opus and Haiku are the two ends a team would realistically choose between.
- All three arms ran the same tasks, under the same time limits, through the same infrastructure. Every comparison counts only tasks that all three arms completed.
- Sovereign started each benchmark knowing nothing about that kind of work. Everything it knew by the end, it learned during the run.
- Each result comes from a single run. Where differences are small, Figure 1 shows 95% intervals so the reader can judge them.
- Accuracy is each benchmark's own scoring. Cost is model spend at list prices.
| Benchmark | What it tests | Tasks |
|---|---|---|
| USACO | Olympiad programming problems, checked against hidden tests | 301 |
| LiveCodeBench | Recent contest coding problems | 95 |
| SATBench | Logic puzzles built from satisfiability problems | 993 |
| SemiKong | Long semiconductor operations workflows with many tool calls | 100 |
| FactoryBench | Long manufacturing operations workflows in an ERP system | 93 |
| LedgerBench | Long corporate finance workflows in an ERP system | 95 |
| Reasoning Gym | Puzzles across dozens of reasoning task families | 282 |
| MMMLU | Professional knowledge questions in many languages | 150 |
Results
Accuracy and cost
Figure 1, at the top of this post, places each arm on one chart per benchmark: accuracy on the vertical axis and cost per task on the horizontal. Opus sits at the top right, accurate and expensive. Haiku sits at the bottom left, cheap and, on most benchmarks, less accurate. A router earns its place if it lands up and to the left of Opus: nearly as accurate, or more so, for less money.
On every benchmark Sovereign lands to the left of Opus, and on three of the eight it also lands above it.
Against the frontier model
Figure 3 shows how much less Sovereign spent than Opus on each benchmark, with the difference in accuracy beneath each name. The savings range from 43% on MMMLU, where even Opus is inexpensive, to 81% on Reasoning Gym.
On USACO, LiveCodeBench and SATBench, Sovereign was also more accurate than Opus. These are the benchmarks where a cheaper model in the pool can match the frontier, and Sovereign found it. On SemiKong, FactoryBench and LedgerBench, long operations and finance workflows with many steps per problem, it spent 67% to 70% less and landed between the two baselines: 4 points below Opus on LedgerBench, 11 on SemiKong and 15 on FactoryBench. On Reasoning Gym it came within about a point of Opus, and on MMMLU within four.
Against the small model
The comparison with Haiku, in Figure 4, asks the opposite question: what does a team gain by routing instead of always using the cheapest option?
Sovereign was more accurate than Haiku on every benchmark, and the size of the gain follows the difficulty of the work. On USACO, where Haiku solved fewer than half the problems, Sovereign added 55 points. On LedgerBench it doubled Haiku's score. On Reasoning Gym, where Haiku was already strong, the gain was small, and so was the extra spend: well under a cent per task.
Getting better with use
The results above are averages over whole runs. They hide the most important property of a router that learns: it starts out knowing nothing, and it improves.
USACO shows this most clearly, because the choice of model matters on almost every task. Haiku solved 43% of the problems and Opus 96%. Sovereign began the run with no record of how any model performed on olympiad programming. Figure 5 tracks its accuracy over all the tasks it had completed so far.
The curve rises steadily. Over its first 25 tasks Sovereign scored 88%. By task 100 it had reached 94%, it drew level with Opus at around task 150, and it finished the run at 97.7%, above Opus. From the hundredth task onward it solved 199 of the next 200 problems.
The same pattern elsewhere
Accuracy so far also depends on which tasks happen to come first, so a fairer test of learning compares Sovereign with Opus on the same tasks, in the same order. Figure 6 does this for every benchmark: each line is Sovereign's accuracy minus Opus's over the tasks completed so far, so zero means level with Opus.
On six of the eight benchmarks the gap closes as the run goes on, or Sovereign's lead grows. On USACO it moves from 13 points behind to ahead. On SemiKong it halves, and on FactoryBench it narrows by nearly ten points. On Reasoning Gym it shrinks to about a point. On SATBench and LiveCodeBench Sovereign ends ahead, and its lead on LiveCodeBench widens through the run. On LedgerBench it holds about four points behind. On MMMLU the gap opens by about three points as Sovereign shifts work to cheaper models; that is the benchmark where a small model is nearly as good as Opus, and Haiku ends up as Sovereign's main model there (Figure 7).
What Sovereign learned is simple to state. GPT-6.1 Terra writes competition code about as well as Opus, at a fraction of the price. Sovereign was never told this. Terra was one option among many, and the grades kept saying it worked, so Sovereign sent it most of the work.
Why not always use the cheaper model?
If Terra solved almost every USACO problem for a fraction of Opus's price, why not simply switch to Terra? Because nobody knew. Before the run, Terra was one of many plausible options, and nothing in its price or its reputation said it would match the frontier on olympiad programming. Finding that out is exactly what Sovereign did.
The alternative is to find out by hand: run every candidate model on every workflow and compare. With a dozen candidate models and dozens of workflows, that is too slow and too expensive to do even once, let alone each time a new model ships. Sovereign does the search as part of serving real work. It tries promising options early, then concentrates on the ones the grades favor, so the cost of searching stays small.
The answer also differs from one kind of work to the next. Figure 7 shows where Sovereign sent work on each benchmark.
Terra carried most of the work on USACO, SATBench and SemiKong. On FactoryBench it shared the work with GPT-6.1 Sol, and on LedgerBench Sol took half. On LiveCodeBench and Reasoning Gym, Sovereign found that DeepSeek V4.1 Flash did well and sent it more than half the tasks. On MMMLU it settled on Haiku. No single cheap model would have done well everywhere. The same will be true from one company to the next: the best model for one team's workflows is unlikely to be the best for another's, and Sovereign finds each one from that team's own results.
When a small model is enough
Learning also means learning when not to spend. On Reasoning Gym and MMMLU, Haiku was already within six points of Opus, and Sovereign leaned on cheap models: DeepSeek V4.1 Flash for reasoning puzzles, Haiku for multilingual knowledge. A router that always reached for the strongest model would have paid frontier prices for very little.
Latency
Routing adds a decision before each request, which takes about half a second. Whether Sovereign ends up faster or slower than Opus overall depends on the models it picks. It was faster than Opus on six of the eight benchmarks, because the models it chose often answer sooner. Switch Figure 1 to latency to compare median wall time per task on each benchmark.
Discussion
The economics of learning
A router that learns pays for its knowledge up front. Early in a run it has little evidence, so it makes some choices it would not make later, and some of those cost accuracy. The question is whether that cost is repaid.
USACO lets us put numbers on it. Over its first 100 tasks Sovereign scored 94%, two points below Opus over the whole run. Over the next 200 it scored 99.5%, more than three points above. Its average cost per task over the run was $0.029, $0.040 less than Opus, as the cost view of Figure 5 shows. The learning period cost roughly two problems; everything after it was better and cheaper.
In production the trade is even more favorable. A workflow that handles thousands of requests a day spends a tiny fraction of its traffic on learning, and keeps the benefit for as long as the models stay the same. When a provider ships a better or cheaper model, the same process finds it without anyone rewriting a rule.
Why grading without an answer key works
Learning from outcomes only works if the outcomes are judged correctly. A grader that passes everything teaches a router that every model is equally good, and the router sensibly picks the cheapest. Everything in this post depends on the grades being right.
Grading without an answer key is possible because checking work is usually easier than doing it. A grader does not need to be able to produce a solution from scratch to tell whether one holds up, and the evidence it needs is usually in the conversation itself. On USACO, measured over Sovereign's own work, the grader's verdicts agreed with the benchmark's hidden answer key 95% of the time, without ever seeing it. That agreement is what turns the curve in Figure 5 upward.
What this changes for teams
The practical result is that choosing a model stops being a decision a team makes once and defends forever. A team points its application at Sovereign, keeps its existing prompts and tools, and lets the choice of model follow the evidence, workflow by workflow. The expensive model is still used, but only where it earns its price.1Sovereign speaks the same APIs as the model providers, so pointing an application at it is a configuration change rather than a rewrite.
Open questions
There are several questions we would like to understand better:
- How quickly can learning transfer between similar kinds of work, so that a new workflow starts from what related ones already taught?
- How should a router grade work whose quality is a matter of judgment rather than correctness, such as writing or design?
- How small can the cost of learning be made, especially for workflows with little traffic?
- How should a router weigh accuracy, cost and speed when a team cares about all three at once?
Closing thoughts
The models will keep changing, and so will their prices. What should not change is how a team decides which one to use: by evidence from its own work, gathered continuously, rather than by a choice made once and left alone.
Sovereign is our attempt to make that the default. On the benchmarks here it matched or beat the frontier where the frontier was needed, saved most of the cost where it was not, and got better the longer it ran. We look forward to sharing more as it learns from real work.