Statusline payload reports context_window_size: 200000 on 1M-context session (claude-fable-5) — used_percentage pegs at 100%
Summary
On a 1M-context session (model selected via the /model picker, which correctly labels it "1M context"), the statusline stdin payload reports context_window_size: 200000 and used_percentage pegs at 100, even as the session's actual input tokens sail past 200k with no autocompact and no context-limit error — i.e. the harness's real limit is clearly 1,000,000, but the payload's denominator is stuck at the 200k default.
This looks like the same shape as #39702 / #61734 (both closed, reported against claude-sonnet-4-6), now reproducing with claude-fable-5 on a current build.
Environment
- Claude Code v2.1.206, Linux (headless server)
- Max plan
- Model: Fable 5 selected via
/modelpicker (picker shows 1M context) - Statusline: custom
statusLinecommand consuming the documented stdin JSON
Observed
Payload context_window object mid-session (~160k tokens):
{
"total_input_tokens": 160781,
"total_output_tokens": 2,
"context_window_size": 200000,
"current_usage": {
"input_tokens": 486,
"output_tokens": 2,
"cache_creation_input_tokens": 281,
"cache_read_input_tokens": 160014
},
"used_percentage": 80,
"remaining_percentage": 20
}
Later in the same environment, a session was observed at total_input_tokens: 330659 with the payload still reporting context_window_size: 200000 and used_percentage: 100 — the session continued normally (no autocompact, no context-limit error), consistent with a real 1M limit.
Expected
context_window_size: 1000000 (and used_percentage computed against it) when the session is running with the extended context window, per the statusline docs, which state the field should be "1000000 for models with extended context".
Impact
- Any statusline consuming
used_percentage/context_window_sizeshows ~100% for the majority of a 1M session, making the meter useless exactly when long-context budgeting matters most. - Users reasonably conclude autocompact is broken ("100% used and it never compacts") when compaction is in fact correctly waiting on the real 1M limit — #63015 may partly be this root cause where a 1M model is in play.
Workaround
Statusline scripts can fall back to total_input_tokens (which is accurate) and, once it exceeds the reported context_window_size, infer the 1M window and recompute the percentage locally.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗