We built Entelligence Router to make coding agents cheaper. We did not expect the clearest result from our latest benchmark to be about accuracy.

The original idea came from reading agent traces. A frontier model would do something genuinely difficult find the root cause of a race condition, untangle a bad assumption, plan a fix across several files and then spend the next ten turns reading files, rerunning tests, and writing a summary. We were paying frontier prices for the whole session even though only a few moments needed frontier reasoning.

So we put a router in the middle. Instead of choosing one model at the start and keeping it for every turn, Entelligence Router reads the work in front of the agent and selects the least expensive model that can handle it. When the trace shows the agent is stuck, the router escalates. When progress returns, it steps back down. It also accounts for context windows, provider availability, and the cost of abandoning a warm prompt cache.

That should reduce spend. The harder question was whether it would preserve the quality of an all-frontier setup.

To find out, we ran Entelligence Router, Claude Opus 4.8, and Claude Opus 5 through the same 89 Terminal-Bench 2.1 tasks.

The router did not merely preserve quality. It solved more tasks than either Opus configuration.

The test

Terminal-Bench 2.1 is useful here because it looks more like agent work than a one-shot question-answer benchmark. Each task drops an agent into an isolated terminal environment and asks it to produce a real outcome: repair a build, debug a system, extract data, fix configuration, or complete another terminal-based engineering task. A hidden verifier checks the final state. There is no partial credit for sounding convincing.

We kept Claude Code unchanged across all three runs. The machines, concurrency, task set, per-task time budget, and graders were also the same. Provider or API exceptions counted as no-data, never as a pass. The only meaningful difference was how model calls were served.

In the first run, Claude Opus 5 handled every turn. In the second, Claude Opus 4.8 handled every turn. In the third, Entelligence Router chose from a multi-family model pool and could escalate when the active model stopped making progress.

That gave us a clean comparison between two common deployment strategies: choose a frontier model once for the entire session, or choose a model turn by turn from the evidence in the trajectory.

Here is what happened:

Entelligence Router solved eight more tasks than Opus 5 while spending 65.5% less. Against Opus 4.8, it solved 13 more tasks while spending 57.7% less.

The total bill tells only part of the story. What matters to an engineering team is the cost of work that actually gets completed. On that measure, the router cost $0.93 per solved task. Opus 5 cost $3.03, and Opus 4.8 cost $2.68. The router therefore delivered a verified solution for 69.4% less than Opus 5.

Accuracy uses all 89 tasks as the denominator. The cost-per-valid-run figures exclude capped no-data tasks, giving denominators of 89 for the router, 84 for Opus 5, and 87 for Opus 4.8. Cost per solved task divides total provider spend by verified passes.

Why routing improved the score

Calling the router “better than Opus” would be the wrong lesson. Entelligence Router is not a single model, and this benchmark does not establish a universal model ranking. What it shows is that placement can outperform one static model choice across a varied agent workload.

A coding-agent session contains many different kinds of work. The agent interprets an instruction, searches the repository, reads code, forms a hypothesis, edits a file, runs tests, and reacts to the result. The hardest of those turns may deserve the strongest available model. Most do not.

The router makes a fresh decision as that work changes. A mechanical continuation after a file read can start on efficient capacity. A request that needs a larger context window can move to a model that can hold it without automatically paying for more reasoning. A difficult instruction can begin higher. The point is not to force every task onto a cheaper model. It is to avoid paying for capability the current turn cannot use.

The more important part happens after the first decision. An up-front classifier can estimate difficulty, but a coding trajectory provides better evidence than the prompt alone. The router watches whether commands succeed, whether test output changes, whether the agent makes an edit, and whether several different approaches keep producing materially the same failure.

One failed command is normal. The same failure returning while the agent keeps moving is different. That is evidence of a stall.

When those signals accumulate, the router raises the required tier and gives the task stronger reasoning. Once the trace starts moving again, the escalation can decay. Frontier capacity behaves like a lease: available when the session earns it, but not automatically retained for every file read and test rerun that follows.

Prompt caching complicates that decision. A lower-priced model is not always cheaper if switching requires it to ingest a long transcript from scratch. For a deep session, staying on a warm model for one more turn can cost less than moving to a nominally cheaper one. The router compares those paths before switching, so cost savings do not come from blindly bouncing between providers.

The model pool is evidence-driven too. A model does not earn traffic because it leads a launch-day demo or carries the strongest brand name. It has to prove itself on measured workloads. When a new model is released, the router can evaluate it and move it into the appropriate work within days, without someone maintaining a hand-written map of models to tasks.

That evidence keeps accumulating after deployment. Because the router sits at the gateway, it can learn from what happened in real agent sessions rather than relying only on one-shot prompt benchmarks. Each completed task, stalled trajectory, and successful escalation gives the system better evidence for future placement. In that sense, the router gets smarter as more work passes through it.

Put together, those choices produce a different agent trajectory. Routine turns do not consume frontier budget. Hard stretches can still reach stronger models. A model that is looping does not keep the task forever simply because it was chosen at the beginning.

That is how routing can improve completion rate as well as cost. The gain does not come from downgrading the agent. It comes from correcting the model choice while the agent works.

What the benchmark does and does not prove

These are strong results, but they need their boundaries.

First, each configuration was run with a single seed. Agentic benchmarks are noisy, and our observed run-to-run variance on this benchmark is roughly ±2 tasks. It is better to read the router score as approximately 71±2 than as an immutable 71. Even with that variation, the measured gaps eight tasks over Opus 5 and 13 over Opus 4.8 are larger than the noise band we have seen. Repeated runs would still produce a more precise estimate.

Second, the Opus configurations were served through the same gateway translation path used by our BYOK customers. A native first-party deployment may score differently. This is a comparison of three configurations on the same platform, not a claim about Anthropic’s models under every possible harness and serving path.

Third, five Opus 5 tasks and two Opus 4.8 tasks reached the per-task cap. We classified those runs as no-data rather than provider or model failures. The accuracy table still uses all 89 tasks for every configuration, so the Opus percentages are conservative floors. The different valid-run denominators are why the table labels that cost column explicitly.

Finally, Terminal-Bench is broad, but it is still one benchmark on one harness. The correct conclusion is not that routing will beat Opus on every workload. It is that, in this controlled 89-task comparison, turn-by-turn placement produced more verified outcomes for substantially less money than either all-Opus configuration.

The router was not given benchmark-specific task mappings or grader information. It ran the same general policy we use for coding-agent traffic. That matters because a router tuned to a test set may make a good chart while learning nothing useful about real work.

The practical takeaway

Choosing the strongest available model for every call feels safe. It is also a static answer to a workload that changes from turn to turn.

This benchmark suggests a better default. Use efficient capacity for routine execution, watch the trajectory for evidence of trouble, and bring in frontier reasoning when the session earns it. Then measure the result in completed tasks rather than cheap tokens or impressive model names.

We are not replacing frontier models. We are making their role more precise.

If your workload resembles the terminal and coding tasks in this benchmark, running every turn on one frontier model may mean paying two to three times as much for the accuracy you get or leaving accuracy on the table at the price you already pay.

For teams already running Claude Code or another coding-agent harness, Entelligence Router is a drop-in change at the gateway. The harness and workflow stay the same; point the agent at one BYOK gateway URL, and the model choice becomes adaptive.

We are not done benchmarking. The next targets are the strongest single-model configurations across other agent harnesses. Closing the remaining gap will come from the same flywheel that produced these results: more evidence, better placement, and leaner trajectories.

See Entelligence Model Router in action.

Methodology: Terminal-Bench 2.1, 89 tasks, Claude Code harness, identical infrastructure across configurations, July 2026. Task-level results, run logs, and additional methodology details are available on request.