The Cost Control Checklist

Your AI bill is not a pile of line items. It is one multiplication:

total spend  =  users  ×  sessions per user
               ×  turns per session  ×  requests per turn  ×  tokens per request
               ×  price per token

Put real numbers in it and the shape becomes obvious:

100 users × 20 sessions × 50 turns × 3 requests × 20,000 tokens × $3/M  =  $18,000/month

Because it is a multiplication, halving any single term halves the whole bill. Cache properly so each request carries 10,000 tokens instead of 20,000, and you are at $9,000. Leave the tokens alone and route the work to a model at half the price — also $9,000. Ground the agent so it finishes in 25 turns instead of 50 — also $9,000. Do all three and the same delivered work costs $2,250.

The decomposition is Uber's, and its best feature is that the terms are signed:

Terms	What to do with them
users, sessions per user	Grow. This is adoption, and it is the entire point
turns per session, requests per turn, tokens per request	Shrink. Uber calls this the agent trajectory — the work the agent does on its own behalf, on top of what you actually asked for
price per token	Shrink. Unit price

That signing dissolves the argument everyone has. "Control AI spend" and "drive AI adoption" are not opposed; they are different terms in the same product. You grow the first two and shrink the other four, and total spend can hold flat while usage climbs. Uber grew weekly active users 7x and weekly agentic requests 9.4x between February and mid-August 2026 with total spend flat from April onward, which is only possible if the other four terms fell by roughly the same factor.

So this checklist has four dials, not forty tips. Each item is a testable claim about your setup; the unchecked items are your gaps. Essential items apply to anyone running agents at scale, and items marked (when applicable) depend on your position — your vendor mix, your volume, whether you serve your own models. Each section carries the effort it costs, so you can still triage, but effort no longer decides the order. Where your money actually goes decides the order.

Act 1 — See the numbers You cannot shrink a term you cannot read. Everything in Act 2 assumes this exists.

01 Meter Every Term Low effort

One invoice line per vendor per month tells you nothing about which of the six terms moved. Metering is the precondition for every other section here.

Cost attributed per user, per tool, per session — not one line per vendor per month
Cost per 1,000 requests and cost per session both tracked over time — these are the two rates that distinguish "the tool got cheaper" from "usage moved somewhere else"
Input, output and cached tokens counted separately — they carry different prices, so a single token count hides the lever
Cache hit rate measured per tool — this is the number you will act on in section 05
Cost per completed task, not cost per call — for every managed agent: cost per merged PR, per review posted, per alert triaged, per cleanup landed
Cost changes decomposed into the terms that moved — users, then sessions per user, then turns, then requests, then tokens, then price, taken sequentially, with nothing left in an unexplained residual
One model held fixed when measuring your own gains — behaviour and price both shift on every upgrade, so nothing can be attributed across one
(when applicable) A quality signal beside every cost number — revert rate, F1, MTTR. A cost reduction with no quality series next to it is not a result, it is a risk you have not priced

02 Put the Number in Front of the Person Spending It Low effort

Someone who can see the running cost makes the ROI call themselves. A hard cap makes it for them, in the middle of their work, badly.

Live cost counter in the status line — running session spend visible without asking for it
One shared spend tier across interactive tools, not a budget per tool — per-tool budgets make people optimise the allocation instead of the spend
Separate tiers for managed agents — automated sessions have different economics and should not compete with humans for the same pool
Nudges at 50, 80 and 100% of expected spend — early enough to change behaviour rather than to explain it afterwards
Self-serve cost breakdown on demand — a skill or dashboard the user runs themselves, no ticket to a platform team
Spend caps exist, with a fast override path — manager sign-off, quick propagation. The cap is the backstop; the counter is the control
(when applicable) Guidance that is session-specific rather than a page of principles — general advice cannot evaluate an individual workflow, and the patterns that cost the most are the ones specific to how one person works

03 Benchmark Before You Change Anything Medium effort

The benchmark is what converts "cheaper" into "cheaper at the same quality". Without it, every item in Act 2 is a quality regression you cannot detect.

Benchmark built from the agent's own real work — Uber built uReview's from real pull requests with known bugs, graded easy, medium and hard
Quality metric named and measured, not asserted — precision, recall and F1 against those known bugs; revert rate for generated code
Operational metrics scored alongside quality — cost per completed unit, latency, timeout rate, output noise. A model that is cheaper and slower may still lose
Candidates plotted as a frontier rather than ranked — anything beaten by something both cheaper and better is out. What remains is a genuine trade-off, and you choose on it explicitly
One harness serves every candidate behind a single interface — frontier and open-weight alike. Without this, every model comparison is also, silently, a harness comparison
Re-run on a schedule, not once — the frontier moves every few weeks, and a fixed routing table decays into an expensive default nobody remembers choosing
(when applicable) Coverage extended per language and per repository — capability varies enough across stacks that a single benchmark will route the wrong way somewhere
(when applicable) A shared benchmark across your repositories, not only per-agent ones — Uber runs an internal SWE benchmark over thousands of real PRs from its monorepos and uses it to inform selection across every managed agent

Act 2 — Shrink the four terms One section per term. Defaults do the heaviest lifting here, because a default applies to every session, every user, indefinitely, without anyone agreeing to it.

04 First, Delete What Should Not Be in the Equation Low effort

Before shrinking any term, remove the work that should never have been counted. This is the only section that costs nothing and needs nobody's cooperation.

Retries, duplicate runs and test traffic identified and removed from the bill — start here. No model change, no negotiation, no permission
Parallel subagents capped — each one pays a fixed token cost to start before doing any work
Deferrable work moved to a batch endpoint — provider batch APIs run at roughly half price for anything that tolerates delay
(when applicable) Anti-pattern detection automated per session — Uber's dashboard flags 16 named anti-patterns, each paired with its dollar impact and a specific remediation, rather than reporting one aggregate number nobody can act on

05 Tokens per Request Low effort

Every turn re-sends the whole conversation, so anything you remove from the payload compounds across the session. Cache reads run at 0.1x the input rate; cache writes carry a premium. The TTL — time-to-live, how long a cached prefix stays valid before the provider discards it — is an economic choice disguised as a config value.

06 Requests per Turn Medium effort

Most of what a coding agent does is not thinking. It is reading files, and emitting output predictable from the files next to it. Both can leave the expensive context entirely — Spotify measured mean savings of around 90% on bulk reads across a Java monorepo by routing them to a cheap worker model. See also section 07: grounding cuts requests per turn as well as turns per session.

Tool calls batched in code rather than in turns — a chatty protocol costs a model turn per step, with every intermediate response landing in context. Uber measured 55 to 71% savings even on single-row query results, where nothing large was being avoided, and over 90% once the loop runs in a subprocess instead of the context window
Large whole-file reads delegated to a cheap worker model — the worker reads the corpus and returns the answer; the files never enter the expensive context, so re-asking against the same corpus is free where it matters
Pattern-following generation delegated — tests, config scaffolding, type stubs. Output goes straight to disk and the frontier model never pays output tokens for it
A reference file required on every generation delegation — without something to match against, the worker produces context-free code that fits nothing in the repository
"Output only the code" in the worker's instructions — otherwise the frontier model pays to parse the worker's markdown fences and explanatory prose
Delegation enforced by a hook, not requested in a prompt — routing rules in a context file are advisory and get ignored. A pre-tool-use hook that blocks reads above a line threshold does not, and it degrades gracefully: even if the agent never reads the instructions, the expensive read is still blocked
A line threshold set, and small reads left alone — below it the network round-trip costs more than the tokens saved. Spotify defaults to 350 lines and makes it configurable
Editing and reasoning explicitly excluded from delegation — worker summaries lack reliable line numbers, so edits still need a direct targeted read; and a cheap worker finds surface patterns while missing the subtle bug. Spotify's worker missed a thread-safety issue the frontier model caught in seconds once given the right context
(when applicable) Delegation targets defined as named, shared configurations rather than as code — a named worker mode carrying its own model, prompt and tools can be forked, swapped or re-pointed without touching the routing layer at all

07 Turns per Session Medium effort

This is the term almost nobody instruments, and it is where the ugliest waste lives. An ungrounded agent fails slowly rather than cheaply, sending an ever-larger context window to search one more place.

Agents grounded before they are routed — Uber's graph-grounded agent answered a table-lineage question in 38 seconds. The same prompt and the same model without grounding spent 20 minutes, spawned 2 subagents, hit 3 errors, and concluded the dataset was unqueryable. It was not: the grounded run found the table over 50 analysts were already using
The grounding source queryable in natural language by any agent — Uber's context graph spans 24 million nodes and 80 million edges across 30+ internal systems: services, teams, incident logs, PRs, design docs, deployments, datasets and query history. A graph no agent can query is documentation
Escalation on failure rather than escalation by default — attempt at the cheap tier, retry stronger only when a check fails. This presupposes a check that can fail, which is why it belongs after section 03
Common workflows encapsulated as skills — so the efficient path is the default path rather than the expert path. Uber ships 25+ pre-built skills for its most-accessed tools
(when applicable) Papercuts from skill executions recorded and folded back into the skills — the turns you waste twice are a fixable defect, not a cost of doing business

08 Price per Token: Run a Cheaper Model Medium effort

There are two ways to cut the last term. This is the first: use a model that costs less. Safe only with section 03 in place — otherwise it is how you quietly ship a quality regression.

Subagent model defaulted to a cheaper tier — subagents do bounded work with specified inputs and rarely need frontier reasoning; the primary model decomposes and evaluates, subagents execute. Uber found this the single most impactful default, and its weight grows as multi-agent orchestration becomes more common
A proven low-cost model set as the default for routine work — proven means it passed the benchmark, not that the output looked fine in a demo
Task-level routing for managed agents — each agent pinned to what is Pareto-optimal for its own workload, not to one house model chosen once
Exact model versions pinned — a silent upgrade invalidates the benchmark that justified the routing
Hosted open-weight models used wherever the benchmark allows — someone else's GPUs, published per-million rates, no infrastructure of your own
(when applicable) A distilled small model for stable, high-volume tasks — only where the task will hold still long enough to amortise the training
(when applicable) Open-weight models routed routinely, frontier APIs reserved for hard tasks — the widest unit-cost gap available to you, and the most work to hold in place

09 Price per Token: Pay Less for the Same Model Low to high effort

The second way to cut the last term, and the one that needs no model change at all. It reads like procurement's job, but procurement cannot pick a billing model without the per-user consumption data from section 01.

Act 3 — Own the plumbing, then sell it What makes Act 2 executable, and what it turns into once it works.

10 Own the Switchboard Medium effort

Routing you cannot change is not routing. One layer between your agents and every provider is what makes sections 08 and 09 executable, and it is also where you either take on lock-in or shed it.

One gateway between every agent and every provider — bought managed or self-hosted. Either beats per-tool integrations, which multiply the places a model swap has to be made
Auth and policy enforced at the gateway, once — this alone justifies the build even if routing never saves a cent
Tools projected as CLI commands the model resolves at call time — the catalogue stops loading schemas into context and starts being searched. Uber projects 1,000+ MCP tools this way
Third-party vendor tools routed through the same path as internal ones — vendors expose their full product surface because they cannot anticipate your usage. The gateway is the only place you get to narrow it
One wrapper owns install, auth, config and cost reporting across harnesses — you cannot change a default you do not own, and Act 2 is mostly defaults
(when applicable) Your own coding harness across providers — the strongest position on this list and the largest commitment. It is what turns a model swap into a configuration change

11 Sell the Control System High effort

The metering, benchmarks, routing and gateway are an asset. Most organisations buying AI have none of it, and know they need it.

The control system inventoried as an asset — metering, evaluation harness, benchmark corpus, routing policy, gateway, anti-pattern library
Generic parts separated from the parts that encode your domain — the gateway is a commodity. The benchmark built from your own real work is not, and that is the defensible piece
A decision made about hoarding versus publishing — a benchmark kept private is a trade secret; published, it is a standard other people have to reference. These are opposite strategies and only one of them can be chosen
(when applicable) Offered to clients as metering, evaluation and routing — new revenue against work you have already paid for

The loop. Cost control has no finish line, because both inputs to the equation move continuously: your workload mix, and the vendors' prices. Every model release resets the frontier in section 03, which invalidates the routing in section 08. Every jump in adoption changes which of the four terms now dominates, and therefore which section is worth your quarter. Go back to the benchmark, not to the spreadsheet — re-measure the terms and let them tell you where to work next.

There is one move underneath the whole equation, and it is a migration rather than a saving.

Uber sorts its agent sessions into four layers by how narrow the task boundary is. At the top sit specialised agents — one for code review, one for incident triage, one for maintenance — each with a real denominator: cost per merged PR, cost per review, cost per alert. At the bottom sit raw interactive sessions, and the caption on that row is the whole argument: no task boundary. With no task boundary there is no unit of work, so the only denominator available is cost per session, and cost per session cannot tell you whether the money bought anything.

That is why interactive sessions can only be nudged and managed agents can be optimised. A session is improved by persuading a person. An agent is improved by changing a config value — its own benchmark, its own Pareto-efficient model, its own outcome-denominated cost. Moving work up the layers is not a platform team's preference; it is how a denominator comes into existence.

The bill is an engineering artifact. It responds to engineering.

Sources

Uday Kiran Medisetty — "Running a Software Factory Efficiently at Uber Scale", Uber Engineering Blog. The spine of this checklist: the signed six-term cost equation and its driver decomposition, the four layers of agent usage and their denominators, the weekly and monthly metric set, benchmark-driven Pareto model selection (uReview and the internal SWE benchmark), prompt-cache TTL economics, CLI-resolved tool calls and code-mode batching, the AI Context Graph and graph grounding, the status line and spend tiers, and the session anti-pattern dashboard. Every figure attributed to Uber above comes from this post, including the growth-against-flat-spend numbers and the model-held-constant reductions.

Dimitri Mazmanov — "Portal by Spotify cut my Claude Code token usage by 90%", Spotify Engineering. Delegating I/O and boilerplate generation to a cheap worker model: the two worker modes, the three-layer enforcement pattern of hooks, scripts and skills, the roughly 90% mean bulk-read saving measured across a Java monorepo, the 350-line threshold, and — as useful as the savings — the explicit non-delegables: editing, reasoning, and anything small enough that the round-trip costs more than the tokens it saves.

Gartner — "AI coding costs will surpass average developer salary by 2028 as token consumption surges", June 2026. Cited via the Spotify post, along with its accompanying figures: a quarter of engineering leaders already spend $200 to $500 per developer per month on tokens, and some are well past $2,000.

Provider pricing and prompt-caching documentation (Anthropic, OpenAI). The multipliers behind section 05 — cache reads at 0.1x the standard input rate, 5-minute cache writes at 1.25x and 1-hour writes at 2x, with TTL options of 5 minutes and 1 hour from Anthropic and 30 minutes from OpenAI — and the roughly half-price batch endpoints behind section 04. Summarised in the Uber post; check current published pricing before modelling any of it.