I metered my own coding agent for a week: 97% of the tokens went to re-reading

An agent turn is not a message. It is the whole conversation so far, re-sent. I spent a week logging per-turn usage objects off the OpenAI-compatible endpoint my agent talks to, and the thing that surprised me was not the total - it was the ratio.

Prompt tokens were 97% of everything the agent consumed, and output tokens were 3%. That is not a rounding artefact. It is what an agent loop does by construction, and once you see the arithmetic you stop optimising the wrong term.

What I logged

Every response from a chat completions call carries a usage block:

{ "usage": { "prompt_tokens": 13800, "completion_tokens": 450, "total_tokens": 14250 } }

I appended one row per turn - {session_id, turn_index, prompt_tokens, completion_tokens, tool_name, wall_ms} - to a JSONL file. Nothing fancy. Roughly 15 minutes of work with the http.client in stdlib, because the client I use lets me set a response hook.

The point of logging per turn rather than per request-day is that the daily total hides the shape. A day with 40 turns across 4 short sessions and a day with 40 turns in one long session cost wildly different amounts, and the billing dashboard shows you the same number.

The growth curve

Here is the arithmetic that matters. Take a session with a 9,000-token base context (system prompt plus tool schemas), each tool result adding 1,200 tokens to the transcript, and a 450-token assistant reply per turn.

Prompt tokens at turn n: 9000 + 1200 × (n − 1). Output tokens at turn n: 450.

The sums are just arithmetic series: prompt total is n × 9000 + 1200 × n(n−1)/2. At n=40 that is 1,296,000 tokens to produce 18,000 tokens of actual text - a 72:1 ratio.

The cost column uses $3 per million input and $15 per million output, roughly frontier-tier rates at time of writing; substitute your model's numbers, the shape does not change.

Two things fall out of that table:

• Tokens per turn rises with session length. It goes 9,450 → 32,850 between turn 1 and turn 40. A dashboard that reports average tokens per request across a month is averaging a distribution that has no stable mean.
• Output price barely matters. At 12 turns, prompt tokens are 97% of volume but only 87% of cost - because output is 5× the input rate. Even at that multiplier, you are paying mostly to re-read.

What a week looked like in requests

The unit my gateway meters is the request, not the token, so the same data has to be re-expressed. A representative session in my logs was 12 turns. At 48 sessions a week:

• 48 × 12 = 576 requests per week
• 576 × 16,050 average tokens = 9.24M tokens per week, of which 9.0M were prompt
• weighted for a 2× model like the Sonnet class: 1,152 weighted requests per week

Compare that to a daily request allowance: 1,152 weighted over seven days is 165 a day on average - comfortably inside a 500/day tier even with a 3× spike on a heavy debugging day.

The same workload on a token meter at those rates is $30.84 a week, or about $133 a month if the pattern holds through four and a half weeks. That number is why I started looking at request-metered gateways in the first place: my monthly token bill was tracking my agent's verbosity, not my output.

The break-even is worth computing before you argue about either model. At $0.64 per 12-turn session, a $39 flat tier pays for itself at about 61 sessions a month. Sixty-one sessions is three a working day. If you run fewer, per-token is cheaper and you should stay on it - honestly.

Three things that actually reduced the number

Not vibes - measured deltas on the prompt side, which is where 97% of the tokens are.

1. Trim tool results before they enter the transcript. A grep that returns 400 lines stays in context for every subsequent turn. Truncating to the 40 relevant lines cost me nothing in task success and cut the 1,200-token average tool result to about 500. Rerun the 40-turn series with that one change: 40 × 9000 + 500 × (40 × 39 / 2) = 360,000 + 390,000 = 750,000 prompt tokens against 1,296,000 - a 42% cut on the same task, from one truncation rule.
2. Start a fresh session per task, not per project. Four 10-turn sessions on the same work cost 4 × (10 × 9000 + 500 × 45) = 450,000 prompt tokens instead of 750,000, because the quadratic growth term is split into four shallower curves. You also get better tool selection out of a shorter transcript, which is a side effect I did not expect.
3. Cap the loop, don't cap the tokens. A max_turns guard at 25 refuses the pathological 80-turn session that produces nothing. Output token limits do not help here - the runaway is on the input side.

Why I meter requests now

Once the ratio is 97/3, the per-token invoice is charging you for a number you can only influence indirectly, through context hygiene. A request-metered gateway charges for the shape instead: one turn is one request. The cognitive load drops, and so does the variance - my worst week and my best week are within 15% of each other now, where the token bill used to swing 3×.

APIClaw runs on that model: a flat monthly tier metered in requests at https://apiclaw.biz/v1, with heavier models counting for more against the daily pool (Claude Sonnet class 2×, Opus and GPT-6 Sol class 3×, DeepSeek 1×). That weighting is the honest part of the design - it admits the 72:1 ratio exists - and the tier table is the thing to check against your own request count, not against a token estimate.

If you want to reproduce this: log usage per turn for one week, compute prompt_total / completion_total, and see whether your workload looks like mine. If the ratio is above 20:1, you are paying for re-reads and should optimise the transcript, not the prompt wording. The comparison page puts the token-metered and request-metered shapes side by side if you want the pricing arithmetic spelled out.

The one-number summary I took away from the week: my agent wrote 18,000 tokens of thinking per long session and read 1.3 million to do it. Everything I have changed since is aimed at the 1.3 million.