[BUG] Statusline context_window JSON contains cumulative tokens instead of current context usage

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/13653
2. https://github.com/anthropics/claude-code/issues/13765
3. https://github.com/anthropics/claude-code/issues/13766

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

I found an additional issue: context_window also excludes tool call results entirely.

Fresh session test (no auto-compact involved):

• /context Messages: 40.2k tokens (20.1%)
• context_window input+output: 12.8k tokens (6.4%)
• Gap: ~27k tokens from file reads via Read tool during /prime

Even with pure conversation after priming (no additional tool use), the gap remains constant - confirming tool
results from earlier aren't counted.

This contradicts API documentation (https://docs.anthropic.com/en/api/messages) which states:
"Tool result content provided back to the model counts toward input_tokens in the subsequent request"

So there appear to be TWO bugs:

1. Cumulative instead of current context (your report)
2. Tool results excluded entirely from the count (our finding)

Both make context_window unusable for context tracking in tool-heavy workflows.

When I saw "Added context window information to status line input" in the v2.0.65 changelog, I was genuinely excited. Finally, a way to surface the one metric that actually matters when working with LLMs: how much context you have left.

I spent a solid half hour implementing this in my custom status line tool, only to discover that the data provided has nothing to do with actual context window usage. The changelog effectively promised one thing and delivered something entirely different.

As a Max subscriber, I don't care about cumulative session tokens - that's a billing concern, not an operational one. What I care deeply about is knowing how much of my 200k context window is currently in use, so I can make informed decisions about when to compact, clear, or restructure my approach.

Anyone who has spent time working with LLMs knows that context management is fundamental. It's baffling that the implementation provides session totals under a field called context_window instead of, you know, context window data.

Please fix this - provide the actual current context usage that /context shows. The infrastructure is clearly there; it just needs to be exposed correctly.

When I saw "Added context window information to status line input" in the v2.0.65 changelog, I was genuinely excited. Finally, a way to surface the one metric that actually matters when working with LLMs: how much context you have left.

Same. Disappointed. I'm just going to have to remove it from my context bar until the usage works properly.

When I saw "Added context window information to status line input" in the v2.0.65 changelog, I was genuinely excited. Finally, a way to surface the one metric that actually matters when working with LLMs: how much context you have left.

I spent a solid half hour implementing this in my custom status line tool, only to discover that the data provided has nothing to do with actual context window usage. The changelog effectively promised one thing and delivered something entirely different.

Somebody at Anthropic assumed it should work that way too 😅: https://code.claude.com/docs/en/statusline#context-window-usage

looks like the update just out is intended to fix it

_• Added current_usage field to status line input, enabling accurate context window percentage calculations_

Updated on my statusline https://www.npmjs.com/package/contextbricks will see how it goes today

Looks like we're still not there eh(?)

CC version 2.0.72's update has a gap on my test at least. E.g. "50k/200k tokens (25%)" via /context, and ⚡︎15% on statusline 🫠

Adding a specific use case not yet mentioned: context-monitoring hooks.

I built a hook that blocks prompts at 90% to warn users before hitting the limit. The hook reads context from the statusline JSON. Because of this bug, it never fires - the gap between reported vs actual usage means users get Claude's "Context low" warning with no time to save their work.

New finding: Beyond the cumulative tokens issue, there's a ~15-20% gap that appears to be system prompt overhead (tool definitions, MCP servers, CLAUDE.md). This isn't tool results (as noted in earlier comment) - it's the invisible base context that's always present.

Workaround I'm using:

base = input_tokens + cache_creation + cache_read + output_tokens
overhead = context_window_size * 0.18  # Empirical estimate
actual_usage = base + overhead

⚠️ Note: This is not accurate, but it provides a reasonably good approximation between the reported context value and the actual state - much better than the raw data.

Feature request: Expose system_prompt_tokens or actual_context_percent so hook/automation developers can build reliable tooling without resorting to empirical guesswork.

Workaround: Correction Factor

For anyone else hitting this, here's a workaround I'm using in my statusline script:

# BUG WORKAROUND: Claude Code provides cumulative session tokens,
# not current context window usage
# Factor 0.68 based on observed: real 91% when cumulative showed 133%

input_tokens=$(echo "$input" | jq -r '.context_window.current_usage.input_tokens // 0')
output_tokens=$(echo "$input" | jq -r '.context_window.current_usage.output_tokens // 0')

# Cumulative total (what Claude Code incorrectly provides)
cumulative_tokens=$((input_tokens + output_tokens))

# Apply correction factor (0.68 = conservative estimate after compaction)
correction_factor=68
estimated_tokens=$((cumulative_tokens * correction_factor / 100))

context_pct=$((estimated_tokens * 100 / context_size))

Calibration: When Claude Code shows "Context low (9% remaining)" = 91% real usage, but statusline showed 266K (133% of 200K window). Factor: 182K/266K ≈ 0.68

Limitation: The factor varies depending on how much auto-compaction has occurred. This is an approximation until the bug is fixed.

I also prefix the token display with ~ to indicate it's an estimate.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Perhaps been fixed as of v2.1.30s. I'm on latest v2.1.38 as of today if any.

Any others that can second on their end?

I built a workaround for the bug which has been broken for a few weeks, I'll revert my workaround and pay attention in the next few days.

Edit: looks like it's fixed, tested on 2.1.38

Explaining the Remaining 15-20% Gap (Post-Fix)

The cumulative tokens issue was partially fixed in v2.1.30+, but multiple commenters here still report a 15-20% discrepancy. I've traced the root cause through cli.js — it's two distinct problems:

1. System overhead is excluded (~19%)

used_percentage counts per-conversation input tokens but excludes system overhead: system prompt, tool definitions, CLAUDE.md, MCP server configs. This is ~38K tokens (~19% of 200K). Your statusline shows 81% used; actual context occupancy is 100%.

2. Output tokens are excluded (~32%)

The statusline counts INPUT only. The internal warning/auto-compact counts INPUT + OUTPUT against an effective window of ~123K (200K minus auto-compact buffer minus output reserve). In code-generation-heavy sessions, output tokens alone can consume ~64K tokens that the statusline never shows.

Combined gap: up to 48 percentage points — explains every "shows X% but context limit reached" report in this thread.

Detailed analysis with source code evidence and proposed fix at #17959.

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.