dash: extract_llm replay credit has no cap #550

Summary

The dashboard gives extract_llm $52.07 of replay credit with no cap. After PR #546, extract_llm is now the largest part of the headline "net from compaction" ($67.51 on the snapshot). We need a rule that limits how long a removal can earn credit.

Related: #549, #546.

What we found

• extract_llm saved $45.41 in the component view and $52.07 of replay credit on the snapshot. Almost all of it is replay: credit earned again on each later turn that re-sends the shortened transcript.
• PR fix(dash): cap summarize credit at its span and price the first removal as a read #546 caps summarize replay credit. The cap is the span from summarize's trigger (0.90 of the window) to where the client compacts on its own (1.00). After the client compacts, both worlds carry a summarized transcript, so the credit stops.
• extract_llm has no trigger fraction, so that span does not apply to it. Today its replay credit runs on every turn that still carries the removal, with no end.

Why it matters

The headline compares what you paid with a world without context-guru. In that world, Claude Code compacts on its own when the context reaches about 1.00 of the window. The compaction also removes the tool outputs that extract_llm shortened. So credit for turns after that point is credit for a saving that would have happened anyway.

There is also a second effect. extract_llm makes the context smaller, so it can move the client's compaction later. Turns that the client would have compacted away in the world without context-guru can still earn credit.

Proposal

Decide on a cap rule for extract_llm replay credit. Options:

1. End the credit at the counterfactual client compaction. The counterfactual is the world without context-guru. Add back what was removed. When that size reaches the client ceiling, stop the credit. This is the same rule as summarize, without the trigger fraction.
2. End the credit at a real client compaction. Credit stops when the client actually compacts. This is simple, but it can over-count, because the removals push the real compaction later.
3. Leave it as it is and label the figure as a ceiling on the dashboard.

Open questions

• Which option do we use? Option 1 uses the same rule as fix(dash): cap summarize credit at its span and price the first removal as a read #546 and does not depend on the removals.
• Should the other offloaders (searchfold, dedup, …) use the same rule? They have the same replay shape, but their sums are small (~$9.5).

Technical notes

• The summarize cap lives in the SummarizeLedger added in fix(dash): cap summarize credit at its span and price the first removal as a read #546, built on spanFor in dash/compactepisode.go. A general version would key the ledger on the component and use a ceiling only (no fill fraction).
• Per-request credit: request_components.saved_usd, priced in Event.Price (dash/event.go).