Repository navigation
[Bug]: Context Window Calculation wrong for claude code #2034
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Steps to reproduce
Hi,
I've been running into this issue for a couple of days. The context window calculation was stuck on 5% after multiple turns for a day and then suddenly shot up to 100% even though the usage was only 15% (confirmed with claude code cli) -see attached images.
Expected behavior
Other threads with codex seems okay no issues.
Actual behavior
Active and Working context window calculator.
Impact
Blocks work completely
Version or commit
No response
Environment
MACOS Tahoe 26.4
Logs or stack traces
Screenshots, recordings, or supporting files
No response
Workaround
No response
Reacted by fireMarshall88, Julius, Mitchell Frisch, Robin Joseph, Tiago Ribeiro, Andrew M, Luax, Den and Kevin Hernandez
Activity
shresthkapoor7 commentedon Apr 16, 2026
facing the exact same issue, how did you open the chat in claude code terminal?
Sergiogd112 commentedon Apr 16, 2026
claude -rshould show the sessions.fireMarshall88 commentedon Apr 16, 2026
same for me
madebyjulz commentedon Apr 16, 2026
same here
mvanhorn commentedon Apr 19, 2026
Traced this to
apps/web/src/lib/contextWindow.tsderiveLatestContextWindowSnapshot. It walks activities newest->oldest and returns the firstcontext-window.updatedpayload whereusedTokens > 0, then computes percent asMath.min(100, (usedTokens / maxTokens) * 100).The 5% stuck -> 100% spike pattern while
claude code clireports 15% points at the Claude Code adapter emitting differentcontext-window.updatedpayloads than Codex: either a staleusedTokensbetween turns, or a post-compaction snapshot that sends a cumulativeusedTokenswithout a matchingmaxTokensbump.To pin it, it would help to see a console dump of the last 3-4
context-window.updatedactivities around the spike:That shows which field is off (usedTokens spiking, maxTokens missing, or a mismatch between
inputTokens + outputTokensandusedTokens). Without that, any fix here is guessing at which of those three paths the Claude Code adapter is hitting.cc @shresthkapoor7 @fireMarshall88 @madebyjulz (all reported the same symptom).
juliusmarminge commentedon Apr 19, 2026
we rely on Claude emitting
task_progressevents to get the compacted context window. Sometimes it doens't emit these, causing us to fallback to the accumulative token spend (not greate). Not sure if there's a better way?amitbet commentedon May 6, 2026
this bugged me as well - so I created a PR:
#2551
muslimdevhamid commentedon May 12, 2026
Facing the same issue.
mvanhorn commentedon May 15, 2026
Sorry for the slow reply, @juliusmarminge - missed the ping.
@amitbet's PR #2551 looks like the right answer. Normalizing at
ClaudeAdapter.ts(the BE emitter) is cleaner than what I was thinking (downstream handling incontextWindow.ts) - it treats the accumulated total as processed-token telemetry only when there's no context-accurate used-token field, which is exactly the fallback you described. Same fix, applied at the source.Might be worth a quick look from a maintainer; coderabbit and macroscope already flagged it as approvable.
juliusmarminge commentedon Jun 20, 2026
Claude usage accounting now separates active context usage from cumulative processed tokens and preserves the last context-accurate reading when only cumulative totals arrive. This removes the 5%-to-100% fallback behavior reported here.
This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.