Auto-compaction: two compounding cost bugs — stale precompute keeps ~200k tokens verbatim, and that prefix is repeatedly cache-created instead of cache-read

Workaround + configuration switches (and version history)

While investigating, I mapped which settings/env vars actually affect this. Summarizing in case it's useful for triage and for others hitting the cost.

Clean mitigation for Issue 1: disable the precompute, keep threshold auto-compaction

// ~/.claude/settings.json
{ "precomputeCompactionEnabled": false }

This disables the background precompute (so no stale pre-summarized version is ever consumed) without disabling threshold-triggered auto-compaction — at the threshold it just runs a fresh live summarization instead.

The wiring (2.1.186 bundle): the precompute is armed only through one master gate (I8n() in the deobfuscated bundle):

function I8n() {
  if (!ZR()) return false;                          // auto-compact enabled?
  if (!Yz()) return false;                          // reactive allowed?
  if (v4()) return false;                           // kill-switch
  if (!it("tengu_sepia_moth", false)) return false; // statsig gate, default OFF
  return rc("precomputeCompactionEnabled", true).value; // <- the setting (default true)
}

The consume-vs-fresh branch falls back cleanly when no precompute exists:

let { summarize } = precomputed
  ? { summarize: () => M8n({ ...precomputed:true }) }   // CONSUME
  : { summarize: () => gSo(...) };                       // FRESH live summarize (same generator the precompute uses)

And the threshold trigger (WKp / XSo) does not reference I8n() — it decides purely on token level + ZR()/Yz()/v4(). So turning the setting off changes the reactive path from consume → fresh; it does not stop auto-compaction.

Note: precomputeCompactionEnabled defaults to true, so the precompute behavior is on unless explicitly disabled. There is also the internal statsig gate tengu_sepia_moth (default false) inside I8n(); statsig gates have no user-facing env/file override in this build, so the setting is the only user control.

Env vars that do NOT do what their names suggest (checked, ruled out)

• CLAUDE_CODE_COLD_COMPACT=1 — only disables prompt-cache-prefix sharing on the manual Npt/mal path (let S = !cold && it("tengu_compact_cache_prefix", true)). It does not stop the reactive path from consuming a precompute. Wrong lever.
• DISABLE_AUTO_COMPACT=1 — inside ZR(); disables all auto-compaction (and transitively the precompute). Too broad.
• CLAUDE_CODE_DISABLE_PRECOMPACT_SKIP — despite the name, unrelated to summarization precompute; it controls whether large transcript JSONL files are read in full vs. only the post-boundary buffer. Ignore for this.
• CLAUDE_CODE_AUTO_COMPACT_WINDOW — pure threshold tuning (when compaction triggers); no effect on consume-vs-fresh.

Version history of the setting

• precomputeCompactionEnabled (the user-facing key) was introduced in 2.1.181 (default true). Absent in 2.1.145 / 2.1.154 / 2.1.177.
• The precompute machinery itself (precomputed compact: / reactive-compact / tengu_sepia_moth) predates the setting — already present in 2.1.145, and absent in 2.1.88 (where compaction was synchronous/live-only). So precompute landed somewhere in the 2.1.89–2.1.145 range, but the user-facing toggle only arrived at 2.1.181.

Caveat on scope

precomputeCompactionEnabled: false addresses Issue 1 (stale precompute → ~200k verbatim) and removes the recurring background-precompute cache-creation. It does not by itself fix Issue 2 — the cache-breakpoint-on-the-volatile-last-message placement can still cause a fresh threshold summarization (which runs right after a main-thread turn) to re-create the body instead of reading it. The breakpoint-alignment fix is still worth making.

Follow-up: the cache-sharing fix for Issue 2 already exists in the code, gated behind a default-off flag — and there's no user workaround

Tracing the breakpoint placer in 2.1.186, the alignment fix for Issue 2 is already implemented; it's just disabled by default.

The message cache-breakpoint placer VIm writes one body breakpoint on the last (volatile) message by default, but also contains a stable-boundary pin keyed to a forkPointUuid (l4n(...) = last stable assistant turn) — which both the main turn and the compaction fork already pass:

function VIm(e, t, n, r = false, o) {   // o = forkPointUuid
  let i = s(e.length - 1);
  if (r) i = s(i - 1);                   // skipCacheWrite retreats one
  let a = new Set(); if (i >= 0) a.add(i);
  if (qmt()) {                           // <- gated, default OFF
    if (o) { /* pin a breakpoint at the stable fork-point uuid */ }
  }
  ...
}
function qmt() { return ZP() && it("tengu_basalt_spur", false); }  // default false; ZP() also requires first-party auth

With qmt() true, both the main turn and the source=compact fork pin a breakpoint at the same stable boundary, so the ~196k body is cache-created once on the main turn and cache-read by compaction. This single flag would fix Issue 2 for both compaction paths (the background precompute build and the live threshold summarization both flow through the same eIn → v1d → CI(skipCacheWrite:true) → VIm).

Two points that make this worth prioritizing:

1. There is no user-side workaround. I checked every lever — routing/source (CLAUDE_CODE_AUTO_COMPACT_WINDOW), skipCacheWrite, TTL/scope betas, all compaction modes. Every full-compaction builder converges on skipCacheWrite:true + an appended TEXT-ONLY turn + no forkPointUuid consumed (because qmt() is off), so the body is always re-created. tengu_basalt_spur is statsig-only with no env/settings override. So enabling the flag is the only way to fix this for affected users.
2. ZP() gates it on first-party auth, so even where the flag is on, non-first-party auth modes won't get the pin. If the intent is to fix this broadly, the ZP() guard likely needs relaxing too.

Suggested action: enable tengu_basalt_spur (and the Ssl()/tengu_basalt_scarp sub-case) for the relevant cohorts, and consider whether the ZP() first-party guard should be dropped so the cache-read path applies across auth modes.

Great decomposition into two separate bugs. They compound but they have different fix surfaces.

On bug #1 (stale precompute, 200k verbatim tokens): the core problem is that the consume path has no staleness guard — when the 47-minute-old summary is consumed, it only summarizes up to its original anchor, and everything since becomes verbatim preserve. The session ends up larger after compaction than it would have been without it.

cozempic addresses this specific footprint: cozempic treat current -rx aggressive --execute prunes those 250 verbatim messages (the ones from the 47-minute gap) directly from the JSONL — stale tool-result records, repeated file-reads, accumulated output blobs. It doesn't know about precompute anchors; it just strips every category of bloat regardless of compaction history. On a 238k-token bloated session I'd expect 40–65% reduction from aggressive, which would get you under where a fresh precompute would have landed.

On bug #2 (cache-create instead of cache-read): this one cozempic can't touch — it's about where CC places the cache_control breakpoint in the outbound request, not about the JSONL content. The body's volatile tail keeps moving the anchor forward, preventing the background precompute from reusing the cache the main thread created. That's an architectural CC fix.

If you want to verify the actual token count independently of what CC reports (useful for diagnosing whether the precompute anchor is where you expect it): cozempic current --diagnose reads the JSONL and prints a category-by-category breakdown.

I can reproduce a very similar cost pattern.

During a /compact-related request, Claude Code created a large prompt cache segment that did not appear to be reused proportionally by later turns.

Observed row from my usage trace:

| Field | Value |
| --- | --- |
| Model | claude-opus-4-8 |
| Input | 2.0K |
| Output | 6.5K |
| Cache Read | 13.3K |
| Cache Create | 182.2K |
| Cost | $1.3187 |
| TTFT | 4699ms |
| Duration | 78556ms |
| Timestamp | 2026-06-29 08:37:35 |

Subsequent requests only read much smaller cache ranges:

• 13.3K
• 31.3K
• 48.6K
• 52.8K
• 54.8K
• 55.3K
• 56.8K

This looks consistent with the issue described here: the compact/precompute path writes a large cache segment, but the following requests do not reuse that segment at the expected scale.

From the user perspective, /compact is expected to reduce context pressure. In this trace, it instead became one of the most expensive requests in the session.

Screenshot attached: the 182.2K Cache Create row is highlighted.

<img width="1882" height="534" alt="Image" src="https://github.com/user-attachments/assets/a95d1b15-1515-4039-a394-347b22b4b92f" />

@young1lin Your usage table is a clean trace of the same pattern. The 182.2K cache-create write after compact, followed by reads that top out at 56.8K, means the large precompute segment was written but the cache-read anchor for subsequent turns is set to a different breakpoint — the turns are reading from a point that predates the bulk of the precompute write. That incremental growth (13.3K → 31.3K → ... → 56.8K) is the session building fresh context from that anchor rather than reusing the 182K write.

@jens-f's workaround above () is the right call for Issue 1 — disables the stale-write path so compact runs live at the threshold instead. Your data helps confirm the bug isn't edge-case specific.

ngl that stale precompute kept ~200k tokens verbatim and then got cache created at the expensive write rate instead of cache read explains why ur costs spike. fyi wozcode cut my token spend ~50% with better caching, might help https://wozcode.com