### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? Using the Claude Desktop app (GUI) with a Claude Code connection. The context-usage meter in the bottom-right of the Desktop app reads ~3%, but the underl

[BUG] conversation auto-compacts repeatedly while context meter shows ~3%

Status Fixed / completed

Reported on v2.1.173

Maintainer reply None cached

Activity 4 comments · opened Jun 20, 2026 · closed Jun 20, 2026

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?

Using the Claude Desktop app (GUI) with a Claude Code connection. The context-usage
meter in the bottom-right of the Desktop app reads ~3%, but the underlying Claude
Code session is actually near/over its context limit and auto-compacting correctly
and repeatedly. The meter is drastically under-reporting real token usage.

Evidence from the Code debug log (~/.claude/debug/<session>.txt): autocompact runs
against effectiveWindow=180000, threshold=167000, and fired 20+ times when tokens
crossed the threshold -- e.g. tokens=173352, 170520, 183253, 223842 -- across
2026-06-04 through 2026-06-19. So compaction is behaving normally; the DISPLAY is
wrong. The user sees ~3% while the session is really at ~90-124% of a 180K window.

Net effect: the conversation legitimately fills and compacts (replacing transcript
with a lossy summary), but the meter never reflects it, so it looks like
"compacting at 3%."

Environment:

Claude Code 2.1.173 (/usr/local/bin/claude)
Front-end: Claude Desktop app (GUI), Linux 6.17.0-14-generic (Ubuntu)
effectiveWindow=180000, autocompact threshold=167000

What Should Happen?

The Desktop app's bottom-right context meter should reflect the SAME token count
the Claude Code layer uses (tokens vs. effectiveWindow=180000). When the session is
near the 167000 threshold, the meter should read ~90%+, not ~3%. The meter and the
compactor must share one source of truth so the user can see when a compaction is
about to happen. (The auto-compaction itself appears correct -- only the meter
reading is wrong.)

Error Messages/Logs

No error is surfaced in the UI. The compaction is silent; the only visible symptom
is the meter showing ~3% while compactions occur.

From ~/.claude/debug/<session-id>.txt (Claude Code DEBUG log), representative lines:
  autocompact: tokens=2961   threshold=167000 effectiveWindow=180000   (normal check)
  autocompact: tokens=173352 threshold=167000 effectiveWindow=180000   (over threshold)
  autocompact: tokens=223842 threshold=167000 effectiveWindow=180000   (well over window)
  autocompact: tokens=183253 threshold=167000 effectiveWindow=180000
20+ threshold crossings logged between 2026-06-04 and 2026-06-19.

Config (~/.claude.json): tengu_auto_mode_config.model = "claude-opus-4-6[1m]"
(NOTE: model string says [1m], but the Code layer's effectiveWindow is 180000, not
1,000,000 -- a possible secondary inconsistency worth checking.)

The ~3% meter reading is the user's observation from the Desktop app UI; the token
numbers above are from the on-disk Code debug log.

Steps to Reproduce

Steps to reproduce:

Use the Claude Desktop app (GUI) on Linux with a Claude Code connection

(Claude Code 2.1.173). Auto-mode model: claude-opus-4-6[1m].

Hold a long, work-heavy conversation (file reads, tool output, large pasted

logs) -- enough that real token usage climbs toward the Code layer's
effectiveWindow=180000 / threshold=167000.

Watch the context-usage meter in the bottom-right of the Desktop app.
Observe: the meter stays very low (~3%) and never climbs, while the session

actually compacts/summarizes repeatedly (the assistant begins turns from a
"continuing from a previous conversation" summary and loses recent context).

Confirm the mismatch in the Claude Code debug log:

tail -f ~/.claude/debug/<current-session-id>.txt

(or follow the "latest" symlink in ~/.claude/debug/)

grep for: autocompact: tokens=
See lines like tokens=173352 threshold=167000 effectiveWindow=180000

i.e. real usage at ~90-124% of the window, while the UI meter shows ~3%.

Expected: meter tracks real token usage (should read ~90%+ near the 167000
threshold).
Actual: meter shows ~3% regardless; compactions fire silently in the background.

Frequency: every time the conversation gets long; the meter never reflects true
usage. 20+ real threshold-crossing compactions were logged between 2026-06-04 and
2026-06-19 in a single project's debug log while the meter stayed low.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.175

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] · 3 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

junaidtitan · 3 months ago

Your debug log is the clearest diagnosis I've seen of this split: the compactor reads one token counter (tokens in the debug output) and the Desktop app's meter reads a different source, and the two have come apart.

The compaction behavior is actually correct — those threshold crossings (173k, 183k, 223k against a 167k threshold) are real, and the summaries are happening as designed. The bug is purely display: whatever counter the Desktop context meter polls is reporting something like "messages in the sidebar" or "API call count" rather than the same token stream the compactor watches. The effectiveWindow=180000 vs. the model string [1m] discrepancy you noted is a separate but related inconsistency — the compactor is using 180k as its effective window while the model is technically the 1M variant.

While Anthropic fixes the meter's data source, cozempic current --diagnose (installed via pip install cozempic) gives you a terminal readout that's independent of the UI — it reads the JSONL directly and reports the actual token breakdown by category. Not a real-time counter, but useful for a ground-truth snapshot between sessions.

The second thing worth considering: since this session is compacting 20+ times, each compaction is lossy (replaces history with a summary). Frequent compactions are often a sign the JSONL is accumulating blob-type content (large tool outputs, Read results persisted verbatim) that fills the window fast. cozempic treat current --execute before a session prunes that category of bloat, which can reduce how often compaction fires — though it won't fix the meter display, which is an Anthropic-side fix.

astralalt77 · 3 months ago

Missed duplicates

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.