[alt-kyle]

Summary

The statusline context bar shows a 200k limit for 1M-context sessions on current models.

Both scripts/statusline.py and scripts/statusline.sh work out the limit from the model display name, assuming 200k unless the name contains "1M". Current models report names like Opus 5.5, with no window size in them, so a 1M session renders as x/200k.

Claude Code already sends the real values on stdin:

"context_window": {
  "context_window_size": 1000000,
  "current_usage": {"input_tokens": 2, "cache_creation_input_tokens": 1237, "cache_read_input_tokens": 94289, "output_tokens": 609},
  "used_percentage": 10
}

Changes

• statusline.py: the stdin fast path read total_tokens / used_tokens, which Claude Code doesn't send, so it never ran. It now reads context_window_size for the limit, and input + cache-creation + cache-read tokens from current_usage for usage, falling back to used_percentage. The empty-bar fallback in main() also uses context_window_size.
• statusline.sh: adds the same stdin fast path before the session-file scan, and the empty-bar fallback uses context_window_size.
• The name-based guess stays as a fallback for older Claude Code versions that don't send context_window.

Testing

Ran both scripts with a real payload from a 1M Opus 5.5 session, a payload with no usage yet, and a payload with no context_window:

Payload	main (py / sh)	This branch (py / sh)
1M session, 95k used	0/200k / 0/200k	9.6% (95k/1M) / 9.5% (95k/1M)
1M session, no usage yet	0/200k / 0/200k	0/1M / 0/1M
No context_window (older Claude Code)	0/200k / 0/200k	0/200k / 0/200k

The 9.5% vs 9.6% difference comes from bc truncating instead of rounding, which predates this change.

I didn't touch CHANGELOG.md, since its entries are written under release version headings.

🤖 Generated with Claude Code