Cheaper Per Token Isn't Cheaper Per Outcome: A Model Routing Framework

A 40% cost cut looks like free money until the model that got cheaper is also the one handling the workload you can't afford to get wrong. That's not what happened with Claude Opus 5.5 (the independent reads so far show parity, not regression). But the reflex it triggers is worth talking about: a cheaper point release arrives, someone changes the default model globally, and nobody re-scores anything.

Our position is simple. A cheaper, faster point release is a reason to re-examine your model routing table. It's not a reason to move the default. What decides the routing table is an evaluation suite with a measured reasoning floor per task class, not the price sheet.

What actually shipped, and what the numbers mean

What does a 40% cheaper model actually cost you? Depends which 40% you mean. This is where model routing decisions begin, not at the price sheet.

Anthropic released Claude Opus 5.5 on September 22, 2026, saying it costs 40% less to run than Opus 5 on typical workloads at default settings and generates output more than 30% faster (Anthropic). Two numbers are doing different work there. Posted API pricing fell 20%: $4 per million input tokens and $20 per million output, against Opus 5's $5/$25, with cache reads cut 60% to $0.20 per million. Anthropic attributes the rest of the claimed saving to the model using fewer tokens per task (Anthropic).

So one figure is a list price you can check on a rate card. The other is a workload outcome that depends on your workload. Quoted side by side without that distinction they read like a contradiction. They aren't one.

The independent reads make the distinction visible. Artificial Analysis scored Opus 5.5 at 58 on its Intelligence Index at max effort, the highest score it has recorded, by several points. Yet the model comes out even with Opus 5 on cost per task, because it emits roughly 1.6x the output tokens (about 119k per task versus about 73k) (Artificial Analysis). The New Stack's hands-on comparison found identical accuracy across three hard reasoning problems, with total test cost falling from $6.55 to $3.95. But it measured 103.4 output tokens per second against Opus 5's 93.1, about 11% faster rather than 30% (The New Stack).

That's a three-problem test run once, on reasoning tasks only. Treat it as an outside signal; it doesn't generalize to coding or agentic work. Its own conclusion leans pro-upgrade: same results on hard reasoning, for less money and less waiting.

The unit that matters is cost per completed task

Here's why the per-token frame misleads. A PayPal-authored framework paper, first posted August 9, 2026 and revised August 31, states plainly that "naive token-cost minimization often fails to reduce end-to-end cost once retries, escalations, and developer wait time are included," and proposes optimizing expected cost per completed task instead (arXiv).

The same paper argues model routing should be decided per task category by difficulty cell rather than per prompt (a cell is one task type at one difficulty band, say "refactor a service, hard"), and derives a routing boundary: the minimum pass rate a cheaper model must reach on a given cell to be worth deploying. The boundary depends on the cost gap between the cheap model and the incumbent and on the penalty you pay when a call has to escalate, plug in your own numbers. Its warning is the sentence worth pinning above the dashboard: "a model with a lower token price can still be more expensive end-to-end if it fails often enough to force retries on a stronger incumbent" (arXiv).

Agentic workloads amplify this. EY's Total Cost of Agents paper puts it in a single line: "A chat that once cost $0.04 may now involve tool retrieval, planning and subagents that turn it into a $1.20 orchestration" (EY). The same paper cites a Gartner poll finding more than 40% of agentic AI projects will be canceled by the end of 2027 on escalating costs, unclear value, or inadequate risk controls.

The failure mode costs wall-clock time as well as dollars. On The New Stack's third test, an ordering problem, both models burned long runs for nothing: Opus 5.5 spent 18 minutes 56 seconds and 112,733 output tokens ($2.26) before refusing; Opus 5 spent 25 minutes 24 seconds and 128,000 tokens ($3.20) with no answer at all (The New Stack). The reviewer's advice, set a hard output limit, give the model a code execution tool for counting problems, is a spend control. Budget for it the way you'd budget for a retry ceiling.

The honest case against building a routing table

Let's be direct about the other side, because model routing isn't free. DigitalOcean's analysis argues routing inserts a decision into the path of every request and carries three unavoidable costs: added latency (its own router adds roughly 200ms), a new failure surface, and silent misrouting that "comes back as a worse answer rather than an error" (DigitalOcean).

The savings are also baseline-dependent. The same analysis reports tiered routing saved about 39.6% against hardcoding a mid-tier model, but only about 7.7% against an already-cheap baseline, and concedes that for a meaningful slice of workloads, you probably should just pin the frontier model.

We agree with more of that than you'd expect. Routing is infrastructure. If your baseline is already cheap and your traffic is uniform, a routing table is an engineering project with a thin return. Re-scoring is the ask; a router is a separate decision you may never need to make. Know your per-task-class numbers before you change anything, including before you decide to change nothing. Staying put has a cost too.

Tune the reasoning floor before you change the model

A reasoning floor is the minimum accuracy a task class must hit before the run counts as done. There's a cheaper lever for holding that floor than model switching, and most teams reach for it last. Artificial Analysis reports Opus 5.5 exposes five effort settings, low, medium, high, xhigh, max, and that four of the five sit on its Intelligence vs Cost per Task Pareto frontier (Artificial Analysis). Anthropic reports the model scores 52.5% on CursorBench, an agentic coding benchmark, at default (medium) effort versus 46.6% for Opus 5 at max (Anthropic).

Think of effort the way you'd think about reading a contract. Low effort is skimming for the gist: fast, fine for a routine renewal. Max effort is reading it twice with a pen in hand, checking every cross-reference. Most work sits somewhere in between, and you choose per document. Effort is a dial with far less blast radius than a default-model swap. Set a reasoning floor per task class, measure against it, and only then ask whether the model underneath needs to change.

Cache hygiene is the other under-used lever. Cache reads fell 60% while list tokens fell 20%. How much of the advertised saving you actually book depends heavily on whether your agent loops reuse a stable prefix. Prompt caching is listed among the supported capabilities for Opus 5.5 on Google Cloud's Agent Platform, alongside batch predictions, function calling, web search and computer use, with Provisioned Throughput supported as a usage type (Google Cloud docs).

What a re-scoring pass looks like

For teams running Claude on their own Google Cloud estate, Opus 5.5 is generally available on the Gemini Enterprise Agent Platform as claude-opus-5-5, with a retirement date not sooner than September 22, 2027, a 1,000,000-token input limit and a 128,000-token output limit (Google Cloud docs). The clock that matters is Opus 5's, though: Google lists its retirement date as not sooner than January 24, 2027 (Google Cloud docs). Teams still on Opus 5 have roughly four months, not a year. Stage the move across task classes rather than flipping the default, and let the same scorecard guide each stage.

• Pin versions and re-run evaluations after every model update. An arXiv paper on evaluation-driven iteration names "Silent Regressions After Model Updates" as a common failure mode: behavior changes without warning and goes undetected until users complain. It recommends pinned versions, evaluation suites run after any update including minor versions, and canary cases that detect characteristic behaviors (arXiv).
• Build the golden set from real production failures. Arthur AI's chain is the right one: a failure becomes a trace, the trace becomes a test case, the test case joins a golden dataset, and that dataset becomes a release gate on every prompt change, model swap, retrieval tweak or tool update (Arthur AI).
• Score one task class at a time. Four columns per cell: accuracy floor, tokens per completed task, retry and escalation rate, latency budget.
• Attribute spend per model and per workload. Cost per completed task isn't computable otherwise; per-model and per-workload attribution is the granularity this calculation needs. Cloud Companion attributes AI spend per model and per workload and surfaces hourly anomaly recommendations.
• Cap runaway reasoning. Hard output limits, and a kill switch for the run that's 19 minutes into producing nothing.
• Set a cadence. Quarterly FinOps reviews are a better rhythm for re-scoring a routing table than reacting to each launch, and point releases now land on a cadence measured in weeks, so a scorecard you build today should be cheap to re-run.

The call

Upgrade where your evaluations say upgrade. On the current evidence, Opus 5.5 looks like parity at lower cost on reasoning, plus the highest intelligence score one independent house has measured. That's a good release, and refusing it out of caution is its own form of waste. What we'd resist is the jump from "cheaper per token" straight to "new global default," with no per-task-class scorecard in between and no regression gate to catch the cell where it quietly got worse.

The price sheet is one number. Your hardest workload is the one that decides.

If you're weighing a staged routing change across a Claude deployment on your own Google Cloud estate, WALT Labs runs that as an evaluation-first engagement, governance, billing and evidence intact.