Repeated auto-compaction within minutes (not hours/days) at far-below-ceiling context size, on a long-running session

Summary

A long-running Claude Code session (6+ weeks, same conversation, extended/1M-context) that had a stable, predictable auto-compaction cadence for its entire life suddenly compacted three times within a 12-minute window, with the 2nd and 3rd compactions firing at a small fraction of the token count that had always triggered compaction before. This coincided with a sharp, unexplained spike in account usage/billing that we cannot otherwise account for by user activity.

Environment

• Claude Code v2.1.198
• Model: Opus 4.8 (session banner) / claude-sonnet-5 (per-message usage logs)
• Claude Max20 subscription (session usage + pay-as-you-go extra-usage credits)
• Extended context window in use (session reached ~928K tokens before the first compaction; end-of-session UI offered /model sonnet[1m])

Normal historical behavior (same session, verified from local transcript JSONL)

Over 6 weeks (2026-05-28 → 2026-07-06), this session auto-compacted 10 times. Each time, usage.cache_read_input_tokens on the immediately-preceding assistant message had climbed to ~900K–937K (near the real ceiling) before compaction fired, and afterward it took 1–8 days (most recent interval: 2.6 days / 2,163 messages) of normal use to climb back to a similar level before the next legitimate compaction.

The anomaly (2026-07-09)

Within one session, in a 12-minute span:

| Time (UTC) | Event | cache_read_input_tokens just before |
|---|---|---|
| ~12:20 | (normal growth) | ~928,419 (near real ceiling) |
| 12:23:15 | Compaction #1 (legitimate) | — |
| 12:25:51 | Full cache rewrite (0 cache_read → 166,418 cache_creation) | 0 |
| 12:27:49 | Compaction #2 | ~155,860 |
| 12:35:33 | Compaction #3 | ~134,000 |

Compactions #2 and #3 fired at roughly 15–17% of the token count that had reliably triggered every prior compaction in this same session. It's as if the effective/apparent context ceiling collapsed to a much smaller value immediately after the first (legitimate) compaction, causing normal-sized activity to repeatedly look "full."

Each compaction forces a full-price cache rewrite (no cache-read discount) for the current context — so instead of paying that cost once every few days, it was paid three times in 12 minutes.

Billing correlation

This session's account exhausted its weekly Max20 session-usage allowance in 4 days (previously always lasted the full week), and burned €50 of pay-as-you-go extra-usage credits within roughly 2 hours on this single interactive instance — an amount of spend that doesn't correspond to a plausible amount of actual new work/tokens generated by a single person typing interactively. A directly comparable colleague setup (same tooling, actually more concurrent background instances) saw no comparable spike in the same period, which rules out shared infrastructure/tooling as the cause on our end.

Confound to disclose

Partway through the same investigation, we also pointed this session's ANTHROPIC_BASE_URL/ANTHROPIC_AUTH_TOKEN at OpenRouter as a stopgap. The transcript's message.model field flips from claude-sonnet-5 to anthropic/claude-sonnet-5-20260630 (OpenRouter's own alias for real Anthropic Sonnet, not the intended third-party model) at the same moment the compaction-cadence anomaly appears. However, the anomalous extra-usage burn was already underway on native Anthropic billing before this switch, and OpenRouter's pricing for this route is identical, so we don't believe the routing change is the root cause — more likely both symptoms share a common upstream trigger, and the routing switch is a coincidental/aggravating factor at most.

Ask

• Is there a known failure mode where, after a session's first genuine near-ceiling auto-compact, the tracked "effective window size" can shrink or get reset incorrectly, causing spurious repeat compactions well below the real ceiling?
• We only have local transcript logs (usage.input_tokens/cache_read_input_tokens/cache_creation_input_tokens per message), not authoritative billed-request data. Requesting engineering visibility into the actual request log for this account/session for the timestamps above, since local logs can't confirm what was actually billed.

Happy to share the raw transcript JSONL (redacted of any conversation content, usage fields only) if useful — filing this issue for the reproducible technical symptom; a separate billing dispute is being filed through account support for the financial side.