Your agent bill is a context problem, not a budget problem

Every new primitive eventually becomes a bill. Cloud taught us that with compute, storage, egress and GPU hours. Tokens are next, and the first team to hit the wall in public was Uber: their CTO reportedly said the company had exhausted its AI budget months into 2026, largely from coding-agent usage.

The instinct is to treat this as a budgeting problem. Set limits, build dashboards, make teams justify usage. Some of that is necessary and none of it touches the cause.

Here is the actual cause, and you can compute it yourself.

The arithmetic nobody runs before the invoice

Anthropic's published rates, as of August 2026 (per million tokens):

Model	Input	Output
Claude Fable 5	$10	$50
Claude Opus 5	$5	$25
Claude Sonnet 5	$2	$10
Claude Haiku 4.5	$1	$5

Now a fleet. Five agents, 200 model calls each per day, 20,000 input tokens and 1,500 output tokens per call:

agents, calls_per_day, days = 5, 200, 30
in_tok, out_tok = 20_000, 1_500

requests = agents * calls_per_day * days        # 30,000
input_mtok  = requests * in_tok  / 1_000_000    # 600 MTok
output_mtok = requests * out_tok / 1_000_000    # 45 MTok

# Opus 5: $5 in / $25 out
monthly = input_mtok * 5 + output_mtok * 25      # 3000 + 1125
print(monthly)                                   # 4125.0

$4,125 a month, and 73% of it is input. You are not paying for what the model writes. You are paying for what you keep re-telling it.

That ratio is the whole story. Most cost work targets the wrong 27%.

Four levers, ranked by what they actually do

1. Prompt caching: lowers the price, not the volume

Anthropic bills cache reads at 0.1x the base input rate, with writes at 1.25x for a five-minute window or 2x for one hour. So a stable prefix gets 90% cheaper to resend.

cacheable = 0.40          # share of input that is a stable prefix
cached   = input_mtok * cacheable * 5 * 0.1     # 120 MTok at 0.1x
uncached = input_mtok * (1 - cacheable) * 5     # 480 MTok at full
print(cached + uncached + output_mtok * 25)     #  ~3765.0

Saves about 9% here. Real, free to adopt, and it has one property worth internalising: caching is indifferent to whether the content is true. A policy that changed last month caches exactly as happily as one that changed this morning. It is a price lever, never a correctness lever.

2. Model routing: the biggest single line item

Same fleet, same context, Haiku 4.5 instead of Opus 5:

# Haiku 4.5: $1 in / $5 out
print(input_mtok * 1 + output_mtok * 5)          # 825.0

$4,125 to $825. Most teams resist this longest and it is usually the largest available reduction. Route by difficulty, not by habit.

3. Batch processing: half price for anything asynchronous

Both major providers discount batch APIs by 50% on input and output. If a workload can tolerate latency, this is a config change worth exactly half the bill on that traffic.

4. Send less context: the only lever that compounds

The first three lower the price of the tokens you send. This one lowers how many you need to send, which is the only approach that keeps working as your corpus grows.

Retrieval payloads grow with document count, because more documents match. Compiled facts do not:

// retrieval: 4 documents, ~7,000 tokens, 2 of them contradictory
{ "results": [
  {"source":"gdrive","title":"Acme QBR v3","chunk":"...2400 tokens..."},
  {"source":"gdrive","title":"Acme QBR v2","chunk":"...2200 tokens..."},
  {"source":"slack","channel":"#eng-acme","chunk":"...1800 tokens..."},
  {"source":"crm","record":"Opportunity","chunk":"...900 tokens..."}
]}

// resolved facts: ~200 tokens, with validity and provenance
{ "facts": [
  {"statement":"Acme latency fix slipped to Q3",
   "valid_from":"2026-04-03",
   "supersedes":"fact_8812 (Q2 commitment)",
   "source":"meeting:2026-04-03#turn-58"}
]}

On Terminal-Bench 2.1 we measured this directly: an agent given a task-scoped memory layer used 41.2% fewer tokens at 72.6% lower model cost, while accuracy rose from 83.37% to 88.31% mean reward across 445 trials. Our own evaluation, so read the methodology rather than trusting the number, and note the shape: cost down and accuracy up is what you expect when the mechanism is less-but-better context rather than a cleverer model.

The cost reduction exceeds the token reduction because fewer retries and shorter runs compound with smaller payloads.

What to do this week, in order

1. Split the bill into four buckets: system prompt, retrieved context, conversation history, output. One day of work, and it redirects everything after it. Most teams find one bucket dominates and it is rarely the one they assumed.
2. Delete dead weight from the system prompt. It is billed on every request, forever.
3. Turn on caching for stable prefixes. Move every variable token to the end of the prompt, or your hit rate will be near zero for reasons that look mysterious.
4. Cap conversation history. Resending a full transcript each turn grows cost quadratically across a long session.
5. Route easy work to a smaller model.
6. Then look at whether your agents are re-deriving the same context repeatedly. If they are, that is a knowledge-layer problem and no amount of caching fixes it.

You can model your own numbers with our agent token cost calculator, which applies the published rates and both reduction paths to your fleet shape.

The uncomfortable framing

The phrase going around is tokenmaxxing: maximise usage, burn tokens, trust that value follows. The critique writes itself, token budgets measure input rather than output.

But tokenmaxxing is not stupid. It is the first rational response to genuinely useful AI. If an engineer ships faster with a coding agent, they will run the coding agent, and telling them to run it less is a bad trade dressed as discipline.

The better question is what each token is spent on. An agent that re-reads your repository every session is not doing more work than one that remembers it. It is doing the same work more expensively, and slightly worse, because the context it rebuilds is noisier than the context it could have kept.

Contextmaxxing beats tokenmaxxing. Spend on relevance, not volume.

---

I work on Sentra, a company brain that resolves cross-system facts once and serves them to agents over MCP, which is the fourth lever above. The longer argument, minus the arithmetic, is in the original essay. If you want every published figure in this category with sources, we maintain a statistics page.