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.

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

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

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%.

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.

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

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.

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.

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.

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 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.