[BUG] context_window.used_percentage includes cache_read_input_tokens, inflated after /clear
Resolved 💬 5 comments Opened Apr 2, 2026 by enzoferraripapa-arch Closed May 17, 2026
Description
context_window.used_percentage in the statusline JSON input includes cache_read_input_tokens in its calculation, causing the reported percentage to remain high after /clear.
Steps to Reproduce
- Have a long session (e.g., 30+ turns) reaching ~34% context usage
- Run
/clear - Send a few prompts (2-3 turns only)
- Check
context_windowin statusline JSON input
Expected Behavior
used_percentage should reflect the actual context consumed in the current conversation, dropping close to ~5% after /clear (system prompt + CLAUDE.md only).
Actual Behavior
used_percentage stays at 34% because cache_read_input_tokens (339,155) is included in the calculation despite being cached from the previous conversation context.
{
"context_window": {
"total_input_tokens": 114783,
"total_output_tokens": 327216,
"context_window_size": 1000000,
"current_usage": {
"input_tokens": 1,
"output_tokens": 81,
"cache_creation_input_tokens": 241,
"cache_read_input_tokens": 339155
},
"used_percentage": 34,
"remaining_percentage": 66
}
}
Note: input_tokens: 1 and cache_creation_input_tokens: 241 show almost zero new context, but used_percentage: 34 due to cache_read_input_tokens: 339155.
Impact
- Statusline scripts that rely on
used_percentagefor session management (checkpoints, auto-compaction warnings) fire prematurely after/clear - Workaround: self-calculate using
(input_tokens + output_tokens + cache_creation_input_tokens) / context_window_size, excludingcache_read_input_tokens
Environment
- Claude Code version: 2.1.89
- Model: Opus 4.6 (1M context)
- Platform: Windows 11
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗