The Cost Control Plane

An autonomous coding agent can produce a $20 patch, spend $200 discovering its first idea was wrong, or burn $2,000 re-reading the same repository while six subagents argue about it. All three runs can end with identical code. That is the whole problem in one sentence: cost has decoupled from output. The engineering task is not to buy a cheaper model. It is to build the control plane that connects spend to accepted work.

This is written for the company that already went all-in. Flagship models — Anthropic's Fable 5, OpenAI's GPT-5.6 "Sol" — pinned at maximum reasoning. Auto-approve on. Loops that run unattended for hours. Velocity is excellent and quality is high. Then the bill arrives, or the usage wall hits mid-batch, and someone asks the question nobody scoped: what is this actually costing, and per what?

TL;DR

You don't have a cost problem. You have a visibility-and-control problem that shows up as a bill. The fix is a layered control plane, shipped in ROI order:

1. See it. Put every agent call behind one instrumented gateway. Tag each request with task, PR, feature, phase, model, and outcome. If you can't attribute a dollar to a merged PR, you don't have a strategy — you have an invoice.
2. Cache first. Structure prompts as *stable prefix → volatile content last*. Cache reads run at ~10% of input price. Highest-leverage, lowest-risk lever, and most teams leave it on the floor.
3. Tier the models. Flagship for architecture and hard judgment; a mid-tier workhorse for implementation; a cheap or local model for search, classification, and bulk edits. The current flagship-to-cheap gap is ~5×, up to ~25× against open models.
4. Make advisor–executor the default. A cheap executor runs the loop; the flagship is consulted only at decisions that change the shape of the work. Most tokens bill cheap; judgment stays near the top.
5. Govern the loops. Hard per-task budgets, aggregate concurrency caps, a circuit breaker on token velocity, and a kill switch that fires *before* the call leaves your system.
6. Split billing. Subscription seats for interactive work; metered — ideally Batch, −50% — for parallel automation.

Optimize cost per accepted outcome, not cost per token. And calibrate: vendors advertise "up to 90–98%"; real company case studies land at 40–70%. Design for half.

Where the money actually goes

Before you cut anything, get the accounting identity straight. For a single agent job:

cost = uncached input + cache writes + cache reads + output (reasoning included) + retries

The formula is boring. The danger is that agent *architecture* multiplies every term at once. The mental model that matters is not "how expensive is this model" but:

model rate  ×  repeated context  ×  branch count  ×  retry count  ×  reasoning multiplier

Switching to a cheaper model attacks exactly one factor. The other four are where 24/7 agents quietly hemorrhage.

Two numbers anchor the intuition. On flagship pricing (mid-2026), output costs 5× input ($10 vs $50 per million tokens for Fable 5), and a generated token is roughly 50× the price of a cached input token. Per token, output and reasoning dominate — which is why "max reasoning effort everywhere" is not a quality setting. It's a spending setting, and on at least one popular coding agent the default effort is already the second-highest tier.

Context growth is the invisible one. Suppose a loop starts at 25,000 input tokens and appends 5,000 tokens of history per turn. Over 20 turns it sends ~1.45 million input tokens — not the 120,000-token final context a trace would show you. Hold each turn near 35,000 and you cut that to ~700,000. Nobody notices this in a demo; everybody pays for it in production.

Fan-out compounds it. Six subagents each handed a 100,000-token snapshot create 600,000 input tokens before any work happens — and if their reports append back to the parent, you pay again to read the investigation you just paid to generate. Anthropic's own numbers trace the ladder: a single agent uses ~4× the tokens of chat, agent teams ~7×, and multi-agent research ~15×. That multiplier earns its keep on high-value parallelizable research. On routine coding it's a bonfire — Anthropic says as much, calling multi-agent a poor fit for most coding work.

Then the silent multipliers. The newest-generation models moved to a tokenizer that emits ~30% more tokens for the same text — a 30% bump on identical work that no dashboard flags for you. And as context re-accumulates, input becomes the larger share of the bill by volume: twenty tool calls can carry orders of magnitude more tokens than one. Which is exactly why the first lever is caching, not model choice.

The two billing worlds

Every token you buy comes from one of two economies, and confusing them is the most expensive mistake on this list.

A subscription seat is dramatically cheaper per productive token — its effective rate is monthly cost ÷ productive usage, and inside the allowance the marginal request adds no charge. That advantage ends, hard, at the rate-limit wall. A 24/7 loop can drain a weekly allowance in a day and leave your engineers idle.

The top-model trap is worse. The best model is often metered *on top of* the subscription: Fable 5 bills ~$10/$50 per million tokens even though you already pay for Max or Team — while the "included" flagships (Opus 4.8 at $5/$25, Sol at ~$5/$30) still throw usage walls under a loop. And when you blow past the plan ceiling, the overage doesn't come at a discount: it bills at standard API rates, the same $/token an API-key user pays, on top of the flat fee. "$200 a month means unlimited Opus" is a myth — it's a metered ceiling with full-price spillover, and the default when it's exhausted is a hard stop. Paying for a plan does not make the frontier free.

And the arbitrage shifts under your feet. In mid-2026 Anthropic announced that headless and Agent-SDK usage would leave the subscription pools onto metered credits — then paused the change before it took effect. Flat-rate automation still works, but it has been openly flagged as temporary. Do not architect a business-critical pipeline on the assumption that subscription headless usage stays free. The clean split survives any pricing change: subscriptions for human-paced interactive work, metered API for elastic automation you can budget and attribute.

Part I — See it

Put all agent traffic behind one instrumented layer — a gateway or wrapper — and record, per request: provider, model, tier, billing channel, reasoning setting; input / output / cache-read / cache-write / reasoning token counts; estimated and invoiced cost; and the metadata that makes it *mean* something — task ID, run ID, PR, commit, feature, repo, team, developer, phase (planning / execution / validation / review), and final outcome (merged, rolled back, abandoned, still running).

The tooling splits into layers that do different jobs. Pick one trace plane and one invoice source of truth — five dashboards produce five different totals.

A blunt truth sits under all of it: OpenTelemetry's GenAI conventions standardize tokens, not dollars — there is no cost field in the spec — so most tools compute cost as tokens × their own price table. Miss a model in that table and it can silently log $0 and sail through your budget, so fail closed on unknown models. It also means your two agents aren't equally legible: Claude Code emits a first-class per-request cost metric (USD, tagged by model, user, and whether it came from the main loop or a subagent) plus a per-developer analytics API; Codex emits token-count logs with no cost field and a metrics gap in headless mode. Normalize both to one price table you own — and check whether a provider's input count already includes cached tokens before you price them, or you'll over-count every cached call.

The unit of management is cost per outcome, not cost per token:

And here is the counterintuitive result that settles the argument: in one published benchmark, cost-*to-merge* ran ~2.5× apart for the *identical model* on different harnesses — and a cheaper model can cost more to merge, because weaker output buys extra rounds of paid senior review. Cost per token flatters the cheap model; cost per merged PR tells the truth. (It also keeps the number honest: token spend is often only a fraction of the real per-task cost once tool calls, retrieval, and human review are counted.)

Two disciplines make this real. Attribution: compute cost at the leaf (tokens × your price table) and roll it up by whatever key you stamped on the request — task, PR, team. Keep low-cardinality tags (team, feature, env) for charts and high-cardinality ones (user, repo, run ID) for forensics, or your dashboards explode. Subscription spend is fixed and needs an allocation convention — call it showback, not precise accounting, and never weaponize per-developer cost into a productivity ranking. Anomaly detection on behavior, not just dollars: a cache-hit-rate collapse, an output-token spike, or a jump in flagship-token share shows up *before* the invoice moves — the best leading indicators are tokens-per-task and retries-per-request. The teams that run this well route every AI request through an internal gateway, precisely so guardrails, analytics, and model swaps live in one place.

Part II — Cut it

Now the levers, in ROI order — effort in, savings out — because you should ship them in exactly this sequence.

Cache like it's free money

Agentic coding re-sends the same system prompt, tool schemas, and repo context on every single turn. Caching that stable prefix is the highest-leverage move available, and it's low-risk to adopt. Anthropic serves cache reads at 0.1× the base input rate — a 90% discount — with a 1.25× write premium on the 5-minute tier; break-even is a *single* cache hit. OpenAI caches automatically at ~50–90% off. Batch and cache stack: batched, cached repeated context lands around 95% off.

The catch is that caching is a prefix game: any change early in the prompt invalidates everything after it. Order context most-stable-first — system instructions, tool definitions, durable repo conventions, reference material — and push volatile content (timestamps, current state, logs) to the very end. Put a request ID near the top and you've turned your cache off without noticing.

This is not theoretical. A security-agent team restructured their prompt to move dynamic memory out of the cacheable prefix and watched cache hit rate go from 7% to 84%, cutting cost ~70% on real invoices. "We enabled caching" is not a metric. Cache-read ratio is.

Build a portfolio, not a monoculture

Quality is preserved by concentrating frontier judgment where being wrong is expensive — not by spraying it across every token.

A correction worth internalizing: the flagship-to-cheap gap is not the 15–18× of last generation. Current-gen it's ~5× (Opus 4.8 $5/$25 vs Haiku 4.5 $1/$5), and wider still against small open models. GitHub prices the same shape into Copilot as request multipliers — 0.33× for the budget tier, 6× for mid, ~27× for premium — the frontier eating your quota an order of magnitude faster than the cheap tier. Route by real evaluation on your own tasks, not brand loyalty: a model that costs half as much but needs three attempts is not cheaper. Teams that tier well report roughly 50% off a uniform-flagship baseline.

On local and open models: deploy them for the cheap tier — classify, extract, summarize, route — where they're genuinely competitive and, in at least one production benchmark, self-hosting only beat API economics below ~14B parameters. Do not reach for them as a frontier-agent replacement yet; the blocker isn't raw intelligence, it's tool-calling reliability inside an agent loop.

Advisor–executor: the backbone

The single pattern that does the most work — the advisor–executor split — puts a cheap executor on the main loop (reading files, editing, running tools, iterating) and calls a flagship advisor only at decisions that change the shape of the work. Most tokens bill at the executor rate; judgment stays near the frontier. This reframes orchestration as an economic control surface, not just a quality trick.

The whole system lives or dies on the escalation rule. Escalate on *observable* triggers, not the model's self-reported "confidence" (which isn't calibrated): the same error twice, a change that crosses an API or data boundary, a diff past approved scope, a validation loop failed more than once, or 70–80% of the task budget consumed without acceptance. Ask the advisor to rubber-stamp every edit and you've built an expensive single-model system with extra latency.

The economics, illustratively — hold a workload at 20M input / 2M output tokens, executor at ~10% of flagship cost:

The 90/10 split is the interesting operating point: most tokens cheap, hard calls still frontier-grade. The exact ratio isn't the point; the *shape* is.

Route by exception, not by habit

Above the portfolio sits routing: send each task to the right tier automatically. A cascade tries the cheap tier first and escalates on failure; a router — a cheap classifier or an embedding match, ~100ms and near-zero tokens — predicts the tier up front. The token math is simple: cheap-first wins whenever cheap attempt cost < success probability × flagship cost, so a cheap attempt at 10% of flagship cost only needs to beat a 10% success rate.

Now the honesty the vendors skip. Independent benchmarking (RouterArena, 12 routers) found the realistic win is ~35% cost at under 2% accuracy loss — not the 85–98% in the marketing. Some routers *added* cost; one commercial router ranked 12th of 12. Start with hand-written rules keyed to task class, risk, and repo — inspectable, cheap, auditable. Buy a learned router only after you have outcome data to calibrate it against; before that, it's an expensive way to encode guesses.

Context is a budget, not a bucket

Stuffing everything into a giant window is the most seductive waste in the stack. The "Token Tax" result: the full-context approach scored 73.1% vs retrieval's 65.4% — but at 26× the per-query token cost. You'd pay a 26× bill for 7.7 points, and for high-volume agents that math favors retrieval overwhelmingly. There's a second, independent reason to keep context lean: *context rot*, where models measurably degrade as the window fills — so past a point, trimming tokens lifts quality as well as cutting cost. The vendors are pricing bloat in, too: some of the newest models now surcharge long requests (one charges 2× input and 1.5× output past ~272K tokens), so the giant window you're tempted to fill is the most expensive real estate you can buy.

Three techniques, all shipping in current tooling: automatic context editing / compaction (clearing stale tool calls mid-run has measured ~84% token reduction while *improving* task performance — the compaction pass is itself billed, a one-time cost that pays off across every later turn); retrieval over stuffing (fetch the relevant files, don't paste the repo); and sub-agent isolation (each child keeps its own window; only its final answer returns to the parent, so the orchestrator's context stays small and clean). Spend more total tokens on isolation to dodge the context-rot tax on the main thread — but remember multi-agent is that ~15× multiplier, justified only when the task is high-value and parallelizable.

Batch the rest

Anything not latency-sensitive — evals, doc generation, backfills, scheduled overnight work — goes to a Batch API: 50% off input and output, on both major providers, with a 24-hour SLA that usually returns far sooner. Stacked with caching, that's ~95% off the repeated portions. The only cost is latency, so it never touches the interactive path — but a huge share of a 24/7 fleet's work is exactly the async bulk that Batch was built for.

Part III — Govern it

The failure mode that produces horror-story invoices is not one greedy agent — it's five agents, each within budget, drawing from one pool, blowing 3× past the aggregate before any dashboard refreshes. So the controls have to be structural:

The non-negotiable is the pre-call kill switch: estimate worst-case cost, reserve it atomically, make the call only if the reservation succeeds, reconcile after. This is the exact line between observability and control — your traces *measure and alert*, but only a gateway in the request path can *block* a charge. A budget that lives in a dashboard is a cost report, not a cost control (and note the sharp edges: some providers' "spend limits" are soft — they alert while the requests keep flowing). Cap velocity, not just totals — a per-hour or per-session ceiling trips a fast retry loop long before a daily budget notices, and loop detection (the same tool call two or three times over) kills the classic runaway. And pause-on-limit must not become retry-on-limit: hit a wall, persist state, compute the next window, add jitter, and resume *once* — thrashing a rate limit just wastes capacity and duplicates work.

Budget *transitions* matter more than the numbers: reserve a per-task budget up front (a routine task $5, a hard debug $25, a migration $100); at 50% consumed, compact and reassess; at 80%, forbid new fan-out and require escalation; at 100%, checkpoint and pause. A loop without these isn't autonomous engineering. It's an unbounded recursive purchase order.

The recommendation: a layered plane, in this order

Everything above is the menu. Here's the sequence to ship it in — and the sequence is the point, because each layer protects quality while attacking the largest remaining multiplier.

1. Instrument first. Unmeasured optimization just relocates cost. Get cost-per-task and cost-per-PR before you touch a model contract.
2. Turn on caching. Near-zero risk, largest immediate win. Fix prefix ordering and measure cache-read ratio.
3. Tier the portfolio, with advisor–executor as the default architecture. Flagship judgment, cheap volume, escalate by exception.
4. Make caching and context hygiene non-negotiable across every model — duplicated tokens are waste at any rate, and retrieval and compaction buy quality too.
5. Split billing — subscriptions for interactive, Batch and metered for automation.
6. Put hard budgets and kill switches on every loop. Then re-benchmark quarterly — inference costs have been falling roughly an order of magnitude a year, so last quarter's flagship keeps becoming this quarter's cheap tier.

Monday morning, concretely: put every call behind one wrapper; require task_id, PR, phase, and tier on each request; reconcile yesterday's estimate against the provider invoice; publish cost-per-merged-PR, retry-waste, and cache-read ratio; move stable instructions into a cached prefix; stand up one advisor–executor workflow with objective escalation triggers; set per-loop dollar, token, concurrency, and wall-clock caps; and review your ten most expensive *failed* runs before you argue about model choice. That last one usually finds more money than the model debate ever will.

Four hot takes

• Max reasoning effort everywhere is a bug, not a flex. It means your orchestration layer can't tell architectural judgment from formatting a file. Effort is a dial — wire it to task difficulty.
• Your biggest lever is caching, not model choice. A 50%-cheaper model matters little if you re-read a huge stable prefix at full price every turn. Fix the prefix before you fight about the model.
• If you can't attribute cost to a PR, you don't have a cost strategy — you have a bill. Provider totals explain procurement. They say nothing about engineering economics.
• Rate limits are a scheduler signal, not a budget. Hitting a wall proves only that capacity was consumed. It says nothing about whether the work was worth buying.

You can't afford infinity

The point of the AI-native shop was to remove the human bottleneck from engineering. It worked — and it moved the bottleneck to the meter. The answer is not to throttle ambition back down to a spreadsheet. It's to build the plane that lets you spend aggressively *where it compounds* and refuse to spend *where it doesn't*: judgment at the frontier, volume at the floor, every dollar attributed, every loop bounded.

Do that, and 24/7 agents stop being a liability with excellent output and start being what they were supposed to be — the highest-leverage engineering spend on your books. Skip it, and you've built a beautiful machine whose one job is to purchase infinity, one token at a time.