[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

  1. Have a long session (e.g., 30+ turns) reaching ~34% context usage
  2. Run /clear
  3. Send a few prompts (2-3 turns only)
  4. Check context_window in 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_percentage for 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, excluding cache_read_input_tokens

Environment

  • Claude Code version: 2.1.89
  • Model: Opus 4.6 (1M context)
  • Platform: Windows 11

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗