78x
tokens read versus written in our metered Claude Code session (144,919 vs 1,859)
Blog
Agents through a router: what the meter actually says
Agent workloads do not pay per answer, they pay per everything-they-read. Our measured session read 78x more tokens than it wrote. Route that through a catalog and three things start to matter.
2.6x
what caching saved on that session: $0.59 with it, $1.54 without
Per step
the selection question inside an agent loop: trivial steps and hard steps, one rate
Agent workloads through any router bill on context: our metered session read 144,919 tokens to write 1,859 (78x) and cost $0.59 with caching against $1.54 without. Running agents through OpenRouter works; the decisive factors are cache behavior through the hop, per-step model fit, and provider variance on tool calls.
The meter, from a real session
We published a full agent session ledger so this argument runs on receipts: five API calls to fix one bug, 144,919 context tokens read, 1,859 written, $0.5887 metered with caching and $1.54 re-priced without it. Output was 1.3% of tokens moved. Whatever your agent runs on and whatever routes it, context handling dominates the bill.
The first question for any routing layer is therefore not the fee; it is whether your caching survives the trip. Cache reads bill at roughly a tenth of input rates, and losing them costs 2.6x on a session like ours.
Three catalog-specific checks
Caching semantics: confirm cache-control behavior end-to-end through the router for your specific models, then meter one real session both ways; the 2.6x is too big to take on faith. Tool-call reliability: agent loops are tool-call chains, and tool-call accuracy is exactly where OpenRouter's own telemetry found provider variance on open-weights models; pin providers or run first-party models for agentic steps. Per-step economics: a session mixes trivial steps (run the tests) with hard ones (find the bug), and a fixed model choice pays one rate for both.
None of these disqualify a catalog for agents. They are the homework a catalog assigns you; do it once and you will know more about your agent's economics than most teams do.
The session ledger, interactive: flip caching off
| # | What the agent did | Context in | Out | Cost |
|---|---|---|---|---|
| 1 | Read the repo, ran the tests | 27,261 | 307 | $0.3561 |
| 2 | Read the buggy file | 28,202 | 129 | $0.0455 |
| 3 | Fixed both bugs (two edits) | 28,808 | 1,022 | $0.0869 |
| 4 | Re-ran the tests: all pass | 30,148 | 157 | $0.0534 |
| 5 | Wrote the summary | 30,500 | 244 | $0.0467 |
| One bug fix, five calls | 144,929 | 1,859 | $0.5887 |
$0.59 total. Call 1 pays the cache-write premium ($0.36) so calls 2–5 can reread 114k tokens at a tenth of the rate.
Metered on Claude Fable 5 rates: $10/M input, $50/M output, cache writes at 1.25× input, cache reads at 0.1×. The "without caching" column re-prices the identical token movement with every call re-sending full context at the input rate. Totals also include the session's 10 uncached fresh input tokens. Full narrative in the Fable 5 breakdown.
The per-step selection problem
That third check deserves its own paragraph, because agents multiply the selection problem: it stops being 'which model for my app' and becomes 'which model for each class of step, times every step, times every market reprice.' Hand-rolled per-step routing tables work and then rot; the ladder moved three times in nine months.
This is the specific case where a blended model is strongest, which is our lane, disclosed: Pareto routes inside every request and bills at cost, measured +0 latency on agentic work, with the agentic benchmark receipts (SWE-Bench Verified, Terminal-Bench) on the model card. $100 of credits is roughly 170 sessions like our published one; run your own eval suite against it.
Questions, answered
Does prompt caching work through OpenRouter?
Verify per model and route: caching semantics vary across providers, and preserving them through any middle layer is the single biggest cost factor for agents. Meter one real session with and without before trusting configuration.
Why is my agent so expensive on a router?
Same reason it is expensive anywhere: context reads. Our measured session moved 78x more tokens reading than writing. Cut rereads and fix caching before blaming the router or switching models.
Should agent steps run on different models?
Economically, yes: trivial steps do not need frontier rates. Practically, a hand-maintained step-to-model table is a config file that rots. Per-request routing (a blended model) is the version of that idea that maintains itself.
Is provider variance worse for agents?
It bites harder: agents chain tool calls, and tool-call accuracy is where variance was measured. One flaky step can fail a whole session, so pin providers for agentic traffic or use first-party models.
Compare any two models
VS
Rates verified 2026-07-28. "Measured task" = our identical dashboard-generation prompt, metered where marked ✓ and list-math otherwise. Verbosity from the Verbosity Index, Edition 1. Data: prices.json.
Run the comparison on your own traffic. $100 to verify.
Buy Pareto API credits