Kibble Blog

Why did our coding-agent bill double this week?

By Kibble · 1 September 2026 · 6 min read

Check reporting coverage, headcount, heavy sessions, model mix, cache usage and retries when coding-agent spend jumps. First establish whether the billed amount or only the estimate changed. The sequence below is a diagnostic method, not a measured ranking of how often each cause occurs.

What are the six causes?

Use these fingerprints to choose the next check. Start with whichever the data supports; the table does not assign probabilities.

1. Headcount grew

One explanation is that more people used an agent this week. Two hires whose seats started mid-month, a contractor who finally installed the CLI, a team that just got access. The fingerprint is that spend per engineer barely moves while the total jumps. Also watch for the half-week effect: someone who started on Thursday contributes two days to last week and five to this one, which reads as growth without anyone changing behaviour.

2. One engineer went heavy

Coding-agent spend is not evenly distributed, and a single engineer on a migration, a greenfield service or a long refactor can out-spend the rest of the team combined for a week. The fingerprint is a flat median with one outlier: sort engineers by week-on-week change and the answer is the first row. A concentrated increase can reflect useful work. Ask what they shipped before asking what they spent, and note that answering this question never requires reading anyone's prompts; the per-engineer total is enough to know who to talk to.

3. The model mix shifted

Top-tier models cost several times the mid-tier ones per token, so a team drifting from a mid-tier default to a top-tier one raises cost without raising token counts. The drift has mundane triggers: a new model ships and everyone tries it, a tool update changes the default, one team standardises on the expensive one for planning work. The fingerprint is cost up while tokens stay roughly flat, and the spend-per-model cut names the model doing it. Check Anthropic's current rates and the model version; what a token count is worth walks the arithmetic.

4. Cache hit rate fell

Most of a coding agent's input tokens are prompt-cache reads, billed at a small fraction of the fresh-input rate, so cost depends less on how many tokens a team uses than on what share of them hit the cache. That share falls for quiet reasons: an agent version change, a rewritten system prompt, a big instructions file or a pile of newly installed skills that invalidate the cached prefix, or a shift toward many short sessions instead of few long ones. The fingerprint is the same volume of work costing more, with the cache-read share visibly down in the token categories. This one is worth finding because it is often reversible with one change to configuration rather than to anyone's behaviour.

5. A runaway loop

Look for an agent retrying in a loop, a repeatedly failing hook, or a background job resubmitting the same task. One useful clue is concentrated activity: a repo has longer turns, more attempts or more errors than its own baseline. The pattern is a reason to investigate, not proof of a loop. The fix is the hook or the task, not the person running it, and the activity counters find it without anyone opening a transcript.

6. Last week arrived late

Sometimes the bill did not double; the baseline was wrong when you first read it. A laptop that was offline pushes its backlog when it returns, and those days land on their correct dates, which means last week's total grows after you first looked at it. A comparison made on Monday against an undercounted week reads as a spike by Friday. The tell is to read the same range twice: if last week is bigger today than it was on Monday, machines reported late and part of the "doubling" is the baseline correcting itself. Month boundaries add the same flavour of noise, which estimated vs billed covers in detail.

Is it real money or an accounting artifact?

Before acting on a spike, establish the cost basis. An increase in actual invoice charges is different from an increase in API-equivalent estimated usage. Claude Console analytics reports estimated cost too, so a rise there alone does not prove the bill changed. A newly installed collector or broader vendor coverage can raise the reported estimate without changing charges, and a stale rate card can skew it in either direction. Label the basis and never sum overlapping sources; the merge rule is what makes a spike diagnosable in the first place.

What can week-over-week answer that the invoice cannot?

The invoice answers "how much". A week-over-week view broken down by engineer, model and repo answers "what changed", which is the actual question behind every bill-doubling conversation. The diagnosis above is five comparisons, each one a sort or a glance once the data is on a screen:

1. Compare the engineer count this week against last. If it grew, divide before you worry.
2. Sort engineers by change. One outlier means cause two; ask about the work, not the tokens.
3. Compare spend per model across the two weeks. A mix shift names itself.
4. Check the cache-read share of input tokens. Down means cause four; look for what changed in the shared prompt or configuration.
5. Look at activity per repo for one repo whose turns, durations and errors all spiked together.
6. Re-read last week's total. If it grew since you first saw it, the baseline moved, not the spend.

None of these steps involve reading a prompt, a diff or a file path. Counts, totals and names are enough to answer the question a CFO actually asks, which is who, which model, which repo, and whether it will happen again next week.