29x and 3–10x: two public numbers about what you really pay for. Neither one is about picking a smarter model.
The usual question about coding agents is which model to run them on. I think that's the wrong first question. The better one is: what happens when the first attempt fails?
Two pieces of public data pushed me there. One is a benchmark that puts a price next to every score. The other is a set of articles from Anthropic about how many agents you actually need. Read together, they say the same thing: most of what you pay for an agent is decided by how you wire it, not by which model sits inside.
Here's what the numbers say, where they stop being useful, and the setup I'd use today.
Number one: 29x the spend for 14.4 points
On October 23, Artificial Analysis released Coding Agent Index v2.0. It doesn't score bare models. It scores a model inside its harness (Claude Code, Codex and so on) across 290 tasks from three benchmarks: FrontierCode v1.1, Terminal-Bench 4.0 and SWE-Atlas-QnA-AA. Next to every score it shows the average API cost per task.
Four configurations sit on the cost frontier, meaning nothing else scores higher for less money. These are the figures from CellCog's write-up and AlphaSignal's summary, and they match the Artificial Analysis comparison page:
- Codex + DeepSeek V4.1 Flash (max): index score 47.3, API cost per task $0.39
- Codex + GPT-6.1 Sol (max): index score 54.1, API cost per task $1.50
- Codex + GPT-6 Astra (max): index score 54.7, API cost per task $7.04
- Claude Code + Claude Opus 5.5 (max): index score 61.7, API cost per task $11.42
The cost frontier. Data: Artificial Analysis Coding Agent Index v2.0, pay-per-token API costs.
The top configuration costs $11.42 per task. The cheapest one on the frontier costs $0.39. That's about 29 times the money for 14.4 more points.
Look at the middle too. GPT-6.1 Sol in Codex scores 54.1 for $1.50. GPT-6 Astra scores 54.7 for $7.04. That's 0.6 points for almost five times the price. If you picked Astra because it's the newer flagship, the benchmark says you're paying for a name.
Where the cheap agent actually breaks
A single index number hides the part that matters most for routing. So I pulled the per-benchmark scores from the Artificial Analysis comparison page:
Per-benchmark scores for three frontier configurations. Data: Artificial Analysis.
- FrontierCode v1.1 (would a maintainer merge this change?): DeepSeek V4.1 Flash 53%, Sol 49%, Opus 5.5 56%.
- Terminal-Bench 4.0: DeepSeek V4.1 Flash 28%, Sol 53%, Opus 5.5 63%.
- SWE-Atlas-QnA-AA (questions about a repository): DeepSeek V4.1 Flash 61%, Sol 60%, Opus 5.5 66%.
The $0.39 agent beats the $1.50 one on merge-quality code changes and on repository Q&A. Then it collapses on terminal work, at less than half of Opus's score.
That's the whole case for routing in one chart. The cheap agent isn't a worse version of the expensive one across the board. It's strong in some places and weak in a specific place. Routing is just writing that knowledge down.
The tradeoffs nobody puts in the tweet
A post on X has 280 characters, so the caveats get cut. An article doesn't get that excuse.
These are API prices, not your bill. Artificial Analysis says it plainly: the costs are pay-per-token API costs, not subscription prices, and not the full cost of running anything in production. If you're on a flat Claude Code or Codex plan, the dollar column doesn't map onto your invoice. It still tells you how much compute each setup burns.
Cheap per task isn't cheap in tokens. DeepSeek V4.1 Flash in Codex used 27.2M tokens per task on average, the most of any Claude Code or Codex configuration on that page. Opus 5.5 in Claude Code used 14.5M, and GPT-6 Astra used 3.2M. The cheap setup is cheap because each token is cheap, not because it's efficient. If your provider's price or cache hit rate changes, that advantage can shrink fast. Artificial Analysis notes that cache hit rates vary a lot by provider routing and can materially change effective cost.
Time is a cost too. Average agent wall time per task: 38.1 minutes for DeepSeek V4.1 Flash, 23.7 minutes for Sol, about an hour for Opus 5.5. If you run cheap first and then escalate, a failed cheap attempt adds its own runtime before the expensive one starts.
It ranks pairs, not models. Opus 5.5 was measured inside Claude Code. Put the same model into another harness and you can get a different score. Your harness is part of the result.
Every leading entry runs at max effort. That setting also drives a big part of the cost column. Lower effort is a separate lever that this table doesn't show.
"Run cheap first, escalate on failure"
So here's the routing rule I'd start with, based on what the numbers above actually support:
- Send everything to the cheap configuration first. For code changes and repository questions, the cheap agent is within a few points of the expensive one.
- Define failure as something a machine can check. Tests fail, the build breaks, a linter rejects the diff, the agent hits its turn or cost budget. Without a cheap, automatic failure signal, escalation turns into a person reading every output, and that person costs more than any model.
- Escalate only the failures. Retry the same task on the strong configuration, with the cheap attempt's error output in context.
- Route terminal-heavy work straight to the strong tier. The benchmark says that's where the cheap agent falls apart, so skipping the first attempt there saves wall time.
The arithmetic is simple. The expected cost per task is $0.39 + (cheap failure rate × $11.42). Running everything on Opus costs $11.42. At a 30% failure rate, the cascade costs about $3.82. At 50%, about $6.10. It only matches always-premium if the cheap attempt fails on about 97% of tasks. I don't have a public number for how often each setup fails on a given task (the index is a composite score, not a pass rate on your repo), so don't treat that as a forecast. It shows how much room for error the cascade has.
What the arithmetic doesn't capture is the risk that matters most: a cheap attempt that passes your checks while being wrong. If your tests are thin, the cascade quietly ships worse code at a low price. Cost routing is only as good as your verification.
Number two: 3–10x more tokens for the org chart
The second number comes from how agents are wired, not which model they use.
In When to use multi-agent systems (and when not to), Anthropic writes that in their testing, multi-agent implementations "typically use 3–10x more tokens than single-agent approaches for equivalent tasks." The overhead comes from duplicated context, coordination messages and the summaries passed at every handoff. They also describe an experiment where agents split by software role (planner, implementer, tester, reviewer) "spent more tokens on coordination than on actual work."
A newer Anthropic piece, When to fold subagents into your main agent loop, goes further. Across several enterprise deployments, they found that a single agent with skills often beat both the one-giant-prompt design and the subagent design on quality, often at lower cost and latency per task. One customer that compared its multi-agent harness against a single loop saw roughly 2x faster runtime.
Left: an agent architecture that copies the org chart. Right: one agent that loads tools and skills when needed.
The way it works is progressive disclosure. The agent sees short descriptions of its skills and tools and loads the full instructions only when a task needs them. A skill is basically a folder with instructions and maybe a script. Anthropic says they cut Claude Code's system prompt for more advanced models by over 80%, partly by disclosing skills and tools this way.
Their name for the failure mode is my favorite line in the piece: agent architecture that becomes "a copy of their org chart." Every team ships its own subagent, every team adds a sentence to the system prompt, and you end up debugging a group chat.
Where single-agent breaks too
Anthropic doesn't say subagents are dead, and I don't either. They list three cases where separate agents still earn their keep:
- the single loop shows measurable degradation from context bloat,
- the work is truly parallel and can use fresh, disposable context windows,
- the agent can't pick the right tool, or the system prompt has conflicting instructions.
They also warn that tool choice tends to degrade once you pass 30–50 tool definitions in the system prompt, which is why they recommend tool search with deferred loading and tools grouped by user intent instead of one tool per API.
The most useful part of the article is a failure. When they folded one subagent into another on a sample support agent, latency dropped, but a process that had been passing broke. The main agent held the order lookup tool and answered on its own, without asking the shipping specialist for the delivery date. The break showed up in only one run out of two. Their advice: have an eval task for every chain of agents that runs together in production, and run each task more than once.
That's the honest version of "simplify your architecture." Simplifying can break things silently, and you need evals to notice.
The setup I'd use today
Both numbers point at the same rule: start simple, measure, and add complexity only when something keeps failing.
In practice:
- One agent, one trace. Start with a single loop. When it breaks, you can read exactly what it did.
- Add a skill when a task keeps failing, not when a new team or a new feature shows up.
- A cheap model by default, a strong model on failure, with failure defined by tests and budgets, not by vibes.
- A small eval before every architecture change. Anthropic says even 10 golden examples are enough to start. Run each one more than once.
- A subagent only when you can name which of the three cases applies.
None of this needs a new framework. It needs a failure signal you trust and the discipline not to add a fifth agent because the diagram looks more serious with five boxes.
What's your default today: one strong model for everything, or a cascade? And what do you use as the failure signal? I'm collecting real setups for a follow-up.
I'm Serhii, a Ukrainian developer in Poland building AI agents and dev tools in public. I post shorter build notes on X and on YouTube at @serhii.builds.
Originally published on Medium.
Top comments (1)
For the follow-up, I'd measure premium cost specifically on the tasks the cheap tier failed. That residual set can be much harder than the benchmark average, and its context now includes a failed attempt. So the useful estimate is cheap cost plus escalation rate times the observed cost of those escalations, with final acceptance and wall time beside it. The standalone premium average is a starting assumption, not necessarily the cascade's second-stage cost.