Auto-compact doesn't trigger in this session — context usage jumps 0%→65%→94% across two single-turn messages

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment

• Claude Code version: 2.1.195
• Model: claude-sonnet-5
• Platform: Linux (Ubuntu, kernel 6.8.0-124-generic), x86_64
• Session type: persistent session via claude remote-control inside tmux, not a plain local CLI session

Description

For the past couple of days, in this specific long-running session, auto-compact is not triggering the way it does in other sessions I use regularly (same account, same setup, other sessions compact normally as they approach the limit). Instead, usage jumps in huge, disproportionate increments after single, ordinary messages — to the point the session becomes unusable before any compaction kicks in.

Concrete timeline (2026-07-14)

1. I sent one normal message. The assistant's turn involved less than 1 minute of thinking/work. Context usage went from ~0% to 65% in that single turn.
2. I then asked why usage had jumped so much. That reply also involved at most ~1 minute of thinking/work. Usage went from 65% to 94% in that single turn.
3. No auto-compact fired at any point during this — I had to run /compact manually afterward.

Two ordinary messages, each answered quickly, took the session from 0% to 94% of the context window. This does not match the actual amount of content generated or read in those turns, and auto-compact never intervened despite crossing whatever threshold normally triggers it in other sessions.

Supporting evidence: /context breakdown doesn't reconcile with its own total

Running /context before compacting (same session, same day):

Tokens: 922.1k / 200k (461%)

| Category | Tokens | Percentage |
|----------|--------|------------|
| System prompt | 8.9k | 4.5% |
| System tools | 12.4k | 6.2% |
| System tools (deferred) | 16.4k | 8.2% |
| Memory files | 4k | 2.0% |
| Skills | 1.5k | 0.7% |
| Messages | 173.2k | 86.6% |

Sum of the breakdown: 8.9 + 12.4 + 16.4 + 4 + 1.5 + 173.2 = 216.4k, only ~23.5% of the 922.1k reported as the total. The percentages in the table sum to ~108% (consistent with 216.4k/200k), while the top-line "461%" is consistent with 922.1k/200k — each number is internally consistent with a different base total, but the two don't agree with each other.

After running /compact manually, /context looked normal and consistent:

Tokens: 41.3k / 200k (21%) — breakdown summed correctly (system prompt 8.9k + system tools 11.5k + deferred 17.3k + memory 4k + skills 1.5k + messages 15.4k ≈ 58.1k... [note: still doesn't perfectly match 41.3k either, worth checking whether "Free space" is being subtracted correctly]).

Suspected connection

I can't verify this from the client side, but the two symptoms look related: if the total-token accounting that drives the "922.1k / 461%" number is inflated or double-counting something that the per-category breakdown doesn't see, that same inflated number could be what's making the session look like it's already over threshold sooner than it should be — while also being why auto-compact isn't triggering cleanly (maybe it's comparing against the wrong total, or firing on a stale/incorrect check).

Impact

This makes the session effectively unusable — two normal messages exhaust almost the entire context budget, requiring manual /compact. Other sessions on the same account do not show this behavior.

Steps to reproduce

Not reliably reproducible on demand. Occurred repeatedly over the last couple of days in this one long-running remote-control session. Happy to provide further /context snapshots or session logs if useful.

What Should Happen?

• Context usage should scale roughly with the actual content generated/read in a turn — a single ordinary message answered in under a minute should not jump usage by 65 percentage points, and a follow-up question shouldn't add another 29 points on top of that.
• Auto-compact should trigger automatically as the session approaches the context limit, the same way it does in my other sessions on the same account/setup. It should not require a manual /compact to recover a session that's already over 90% usage.
• The /context command's top-line total and its own per-category breakdown table should reconcile with each other — the breakdown should sum to (approximately) the reported total, since it's presented as that total's breakdown.

Error Messages/Logs

Steps to Reproduce

Not reliably reproducible on demand — I haven't found an isolated action that triggers it. It has occurred repeatedly over the last couple of days specifically in one long-running session (persistent claude remote-control session inside tmux), while other sessions on the same account/setup behave normally.

Closest reproduction pattern observed:

1. Have a long-running session that has NOT had auto-compact trigger recently
2. Send one ordinary message that requires a normal amount of tool use/thinking (in my case, under 1 minute).
3. Usage jumps by tens of percentage points disproportionate to the work done, and no auto-compact fires even though the reported percentage is already past where it triggers in other sessions.
4. Send a short follow-up message (e.g. asking why usage increased) — usage jumps again by a similar disproportionate amount.
5. Manually running /compact is the only thing that resets it back to a consistent, correctly-summing state.

I can share full /context outputs from before/after if that helps narrow down the trigger.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.195

Platform

Other

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

_No response_