Agent Loop Burn

This is the quota problem, one level down

The complaints are loud and mostly aimed at vendors:

> "> 70% of tokens wasted" > "called every fucking tool, started up 4 mcps" > "two prompts torched my entire 5h session" > "Freezes on 'Asking Questions' During Long Runs"

Some of that is pricing, and pricing is not something a library fixes. But a large share of a burned session is work the agent did that produced nothing — and that half lives entirely inside your own loop, where you can see it:

• the same file read six times, unchanged between reads
• the same search re-run with identical arguments
• an edit, its reversal, then the same edit again
• a run of turns that asked questions and touched nothing

Each consumes context going in and output coming out, and each is detectable from a trace you already have.

  analyseBurn(trace);
  // { totalTokens: 45_300, wastedTokens: 30_000, wasteRatio: 0.662,
  //   topRecommendation: "cache observations within a session: big.ts cost 30000 tokens to re-learn" }

The subtlety that makes it a product and not a GROUP BY

A repeat is only waste if nothing changed in between. Re-reading a file you just edited is correct and necessary. So mutations are tracked between observations, and a re-read that follows a write to the same target is never counted.

Get that wrong in the obvious direction and the tool reports careful agents as wasteful — which is how it ends up switched off.

This is where a test found a real bug in the shipping code, not a missing test. The duplicate-call pass originally grouped by (name, args) across the whole trace and only skipped targets already flagged as redundant observations. So read → write → read was reported as a duplicate: the two reads share arguments, and the write never put the target into the redundant set. It only surfaced with a write producing identical content — exactly what agent-edit-scope exists to detect, so not a hypothetical shape at all. The grouping key now carries a per-target epoch that advances on every mutation.

The first occurrence is never waste

Reading a file once is the job. Counting every member of a duplicate group inflates the ratio and makes the report useless as evidence — and a waste ratio above 1.0 discredits everything else on the page. A test asserts wastedTokens <= totalTokens.

What it finds

| kind | meaning | |---|---| | redundant_observation | same target observed again, nothing changed it, same result | | duplicate_call | identical name + args, within the same mutation epoch | | oscillation | a target changed back and forth — the agent undoing its own work | | question_loop | consecutive turns that asked and did nothing |

Check before you spend

  wouldRepeat({ kind: "observe", name: "read", target: "a.ts", args }, trace);
  // { repeat: true, ofStep: 4, detail: "identical to step 4, and nothing has changed a.ts since" }

A session that consults this on every call cannot produce the redundant-observation findings at all. That is the cheaper half of the problem and the one worth wiring in first.

What it cannot see

Semantic redundancy. Two greps with different patterns returning the same lines look like two different pieces of work here, and one of them was wasted. This finds the mechanical repeats — the majority, not the whole. A tool claiming to find semantic waste would be guessing, and guessing wrong here means telling an agent not to do work it needed to do.

| not included | why | |---|---| | Capturing traces | you supply the trace; every harness has one | | Billing / rates | true-token-ledger | | Ordering requests for cache hits | prompt-cache-aware-batcher | | Stopping a run | iteration-stop-conditions, spend-ceiling-limiter |