The incident thread always starts the same way: a bill that surprised the engineer who signed it. $200, $1,900, $6,000 for the month. Community threads about it are easy to find, and the same mechanics show up in another thread on the same topic and over on r/ChatGPTCoding. Different tools, different numbers, the same arithmetic.
This is an anatomy of a $6,000 month — a composite built from the mechanics that recur across those reports, not one billed line item. Two halves: the three mechanics that spike the bill, and the four controls that would have stopped it.
What was actually running
The most common profile in those threads: an agentic coding setup — Claude Code, Codex, or an equivalent — pointed at a production key, running work longer than a person is watching it. The morning notice arrives after the overnight batch: dozens of tasks, each with a long context, each on the most expensive model class the key can reach.
For the math to land at $6,000, nothing needs to be dramatic. Suppose one hard task costs $12 in model calls — thirty long-context steps on a frontier-class model, output-heavy, no cache. A human running twenty hard tasks a day lands near that number in a month. That is a strong working month, not an incident. The incident is when the loop runs without a person in it: retries on failing steps, a scheduler that fires sixty times a day, a "quick fix" that spawns subtasks of its own.
Three mechanics carry the arithmetic.
Mechanic 1: the arithmetic of unattended autonomy
Every hour a loop runs unwatched, spend scales with step count, not task count. If a task fails at step 18 of 20 and the harness restarts from step 1, you pay for twenty steps twice — and a retry at step 18 is more expensive than one at step 1, because the context has grown. An overnight batch of failed-and-retried tasks is not 2x spend; it is 2x spend per step, applied to a context that keeps growing while it retries.
The check is one query: bills per task, not per day. When the median drifts from the tasks you know were healthy, the loop is misbehaving — and the $6,000 month is already in flight, not a surprise.
Mechanic 2: context replay
Agent context grows monotonically: system prompt, tool definitions, conversation, tool results — re-sent on every single step. By step 30, the request carries all thirty steps. If the stable prefix (system + tools) is not cached, a long run is quadratic in cost, not linear.
There is a list of reasons a cache silently stops applying — a format change mid-request, truncation, a forked session id, a parameter that routes the request off the cached path — and each one quietly turns "pay about 10% for the prefix read" back into "pay full input price for the prefix," on every step of the long run. For an overnight batch, that is usually the single largest line item: long context, no cache, on an output-heavy model class.
Mechanic 3: invisible sub-calls
Big-bill threads usually contain a line like "I thought it was making one call per file." Agentic tools fan out: one visible user action becomes a planning call, per-file analyses, verification passes, rework passes — each with its own context. A "fix this bug" that looks like five calls can be thirty. You see the action; the meter sees the fan-out.
This mechanic is specific to agentic tooling — a one-shot chat app does not have it. If your spend surprised you but your app makes direct requests, skip it and audit the model mix your app is actually configured to call.
The four controls, in the order they would have fired
- A cap that trips the key, not a cap that emails you. Alerts are read by humans. When no human is in the loop at 3 a.m., no alert stops the burn — a per-key monthly (or daily) spend cap that returns a clean 4xx does. The stop is the response; there is no automatic retry on a tripped cap. The notification arrives after the stop, for a person to investigate.
- A per-hour anomaly alert on the key, not the account. The tell in these reports is shape: spend per hour at 3-5x your business-hours baseline, during hours nobody is at a keyboard. That takes one aggregation over a usage log — the cost tracking post has the minimal ledger that makes the query possible.
- A per-task budget with a clean stop. Cap the task, not just the key. When a task hits its budget, the tool returns an error the agent can act on — retry cheaper, give up, or escalate to a person — instead of continuing to spend. That is the difference between "task failed at $12" and "task failed at $400."
- Attribution: one key per workload, not one key for everything. The coding agent, the production API, and internal research each get their own key, with their own caps and model policies. When the bill lands, "what spent this" is a one-row lookup, not a reconstruction.
A postmortem checklist, for when it still happens
When the surprise bill arrives anyway, walk the log before touching the config:
- Group by hour. Find the spike — in most of these reports it is the overnight batch.
- Group by model. A frontier-class row dominating work that should have run mid-tier is the most common root cause.
- Group by request shape. The same long context re-sent across many requests means the cache was not engaged — including the "it was engaged, then stopped being" variants from the list above.
- Look for retries. The same task, or the same prompt prefix, at multiple timestamps means the harness re-ran work you had already paid for.
Fix the cause. Then add the control that would have caught it. Then add a control for the next cause — one control per fix is how you end up writing this post twice.
Spend is tokens × price, and no billing design shows you the spike in the line item — subscription metering or pure API, the physics are the same. Caps, per-hour alerts, per-task budgets, and per-key attribution are in the docs; a key to try all four end to end is at signup.