--- title: "Excess cache rehydration" description: "antiburn flags sessions that paid to rewrite the same context into the model's cache far more than once." url: "https://antiburn.ai/docs/findings/excess-cache-rehydration/" --- ## What it detects Providers cache the context a session builds up so later turns don't have to pay full price to resend it - but a cache write is itself billed, and once the cache lapses (an idle gap, a model switch, an expired window) the next turn has to pay to rebuild it. antiburn tracks, per session, how many paid tokens were genuinely new versus how many were the same context rewritten into the cache again, as an "overpay multiple": paid tokens divided by unique paid tokens. A finding fires once that multiple reaches antiburn's reviewed threshold for the session's model family - 2.35x for Claude, 2.0x for Codex (OpenAI) - based on reviewed production usage bands. If every paid token was a repeat, that's an automatic finding regardless of the exact multiple. A session with zero repeated tokens is never a finding, however large its total. ## Why it burns tokens Every repeated cache write or full-price context re-read is tokens spent putting context back in front of the model that were already there before - work the session pays for twice without getting anything new from it. ## How to fix it Avoid long idle gaps in the middle of a session, since that's the most common way a cache lapses mid-work. If you know you're about to step away for a while, compact before the break (or right after you come back) rather than letting the next turn rebuild the full, uncompacted context from scratch. Switching models partway through a session with a lot of accumulated context has the same effect, since the new model's cache starts cold. ## When it shows "not assessed" If your agent doesn't report cache-write or context re-read accounting at all, antiburn can't assess this - that's the case for a few of antiburn's supported agents today. For agents that do report it, a session with repeated context still shows not assessed if antiburn can't identify which model dominated the session, or if that model's family has no reviewed overpay threshold yet - Gemini sessions fall here today. Partial cache evidence also blocks a clean result even with no finding observed, since a missed record could be hiding more repeated context, or understating the paid total. See [hygiene score and findings](/docs/concepts/hygiene-score-and-findings/) for how this fits into your overall score.
Excess cache rehydration
antiburn flags sessions that paid to rewrite the same context into the model's cache far more than once.
What it detects
Providers cache the context a session builds up so later turns don’t have to pay full price to resend it - but a cache write is itself billed, and once the cache lapses (an idle gap, a model switch, an expired window) the next turn has to pay to rebuild it. antiburn tracks, per session, how many paid tokens were genuinely new versus how many were the same context rewritten into the cache again, as an “overpay multiple”: paid tokens divided by unique paid tokens.
A finding fires once that multiple reaches antiburn’s reviewed threshold for the session’s model family - 2.35x for Claude, 2.0x for Codex (OpenAI) - based on reviewed production usage bands. If every paid token was a repeat, that’s an automatic finding regardless of the exact multiple. A session with zero repeated tokens is never a finding, however large its total.
Why it burns tokens
Every repeated cache write or full-price context re-read is tokens spent putting context back in front of the model that were already there before - work the session pays for twice without getting anything new from it.
How to fix it
Avoid long idle gaps in the middle of a session, since that’s the most common way a cache lapses mid-work. If you know you’re about to step away for a while, compact before the break (or right after you come back) rather than letting the next turn rebuild the full, uncompacted context from scratch. Switching models partway through a session with a lot of accumulated context has the same effect, since the new model’s cache starts cold.
When it shows “not assessed”
If your agent doesn’t report cache-write or context re-read accounting at all, antiburn can’t assess this - that’s the case for a few of antiburn’s supported agents today.
For agents that do report it, a session with repeated context still shows not assessed if antiburn can’t identify which model dominated the session, or if that model’s family has no reviewed overpay threshold yet - Gemini sessions fall here today. Partial cache evidence also blocks a clean result even with no finding observed, since a missed record could be hiding more repeated context, or understating the paid total.
See hygiene score and findings for how this fits into your overall score.