[MODEL] Fable 5 asserts false ~15M context window (actual 1M) and declines compaction on loaded sessions — reproduced on Max 20x + Enterprise

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

you want to plan it out first or you confident enough to take it on? you are in auto mode now

What Claude Actually Did

Instead of answering the planning/go-ahead question, Fable 5 spontaneously asserted a false context-window capacity and made an autonomous decision to decline compaction that I had not asked about.

Verbatim reply (model=claude-fable-5, v2.1.206, 2026-07-09):
"No need — I've got massive headroom (15M tokens), and everything load-bearing is already externalized: plan file, task list, handoff memory. If the night runs long, auto-compaction handles it without touching any of that. Head out — starting now."

The claim is false and its own request telemetry proves it. Same-turn usage on that exact message:

• cache_read_input_tokens: 630,456
• cache_creation_input_tokens: 1,621
• input_tokens: 129
• Total input in context window: ~632,200 tokens

All three count toward the context window. That is ~63% of the actual 1M window (~76% of the ~830K usable-before-auto-compaction envelope) — while the model reported "15M tokens" of headroom, ~24x the real ceiling.

My prompt contained nothing about context size or compaction; the 15M capacity claim and the decision not to compact were both unprompted. The session was in auto mode, so this false-capacity assessment drove an autonomous context-management decision with no human in the loop.

Expected Behavior

Two things, and the second is the one that matters:

1. Accurate self-report. When capacity is relevant, Fable should report its real context window (1M in Claude Code, ~830K usable before auto-compaction) — not a fabricated 15M. It should not have volunteered a capacity figure at all here, since I didn't ask; but if it does, it must be true.

1. Correct action on real state. At ~632K/1M in-window (~63%, ~76% of usable), when the question touched on whether to proceed/step away, the right behavior is to recognize the window is well-loaded and either compact or advise compaction — not to decline it on the basis of phantom headroom. The defect isn't only "wrong number"; it's that the wrong number drove the wrong context-management decision.

The two are linked: the model can't ration or compact correctly while operating on a capacity belief that's ~24x reality. In auto mode this matters most — the false belief drove an autonomous decision (decline compaction, "auto-compaction handles it") with no human in the loop, which is exactly the path to running a long session into the ceiling.

Underlying ask: Fable's context-management decisions should be grounded in its actual token usage, not a stale internal capacity figure. If the model has no reliable runtime signal for remaining context, it should be given one rather than defaulting to a fabricated number.

Files Affected

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

No deterministic one-step repro; the assertion is state-correlated, not prompt-triggered. Conditions under which it recurs:

1. Start a Fable 5 session in Claude Code (observed on v2.1.206).
2. Run a long, real agentic task until the context window is substantially loaded — the quoted instance was at ~632K input tokens in-window (~63% of 1M), driven largely by cache_read. Externalizing state to files (plan/task/handoff) does not prevent it.
3. Ask a proceed/step-away-type question that does NOT mention context or compaction (e.g. a go/no-go or "you good to take this on?").
4. Observe: Fable spontaneously asserts large phantom headroom ("15M tokens") and, unprompted, declines or waves off compaction — despite the window being well-loaded.

Trigger appears to be a loaded window, not any specific prompt. Likely surfaces most in auto mode / long autonomous sessions where the window fills without manual compaction.

Reproduced 12+ times across two independent accounts on different plan tiers: a personal Max 20x plan and a separate Enterprise account. Different billing, orgs, and entitlements — same false 15M assertion, same behavior. Cross-tier reproduction rules out account configuration or plan-specific context settings as the cause.

Claude Model

Other

Relevant Conversation

Verbatim assistant turn (model=claude-fable-5, Claude Code v2.1.206, 2026-07-09T23:59Z):

"No need — I've got massive headroom (15M tokens), and everything load-bearing is already externalized: plan file, task list, handoff memory. If the night runs long, auto-compaction handles it without touching any of that. Head out — starting now."

Same-turn request telemetry (from the session .jsonl usage block for this exact message):
- cache_read_input_tokens: 630,456
- cache_creation_input_tokens: 1,621
- input_tokens: 129
- Total input in context window: ~632,200 tokens

The model claimed "15M tokens" of headroom while its own usage for that turn shows ~632K tokens in-window — ~63% of the actual 1M Claude Code context window (~76% of the ~830K usable-before-auto-compaction envelope). The stated capacity is ~24x the real ceiling, and the false figure was used to justify declining compaction I had not requested. My preceding prompt referenced neither context nor compaction.

Impact

High - Significant unwanted changes

Claude Code Version

2.1.206 (Claude Code)

Platform

Anthropic API

Additional Context

Patterns observed:

• The false "15M tokens" figure is consistent across every occurrence — always ~15M, not a random large number. Suggests a fixed internal value, not per-session noise.
• Strongly correlated with loaded, long-running sessions. It surfaces once the window is substantially full (quoted instance ~632K/1M in-window); I have not seen it early in a fresh session.
• Prompt-independent: appears both spontaneously (the quoted instance — my prompt mentioned neither context nor compaction) and, in other sessions, when I explicitly asked whether to compact. Either way the answer is "no need, 15M."
• The model reliably pairs the false capacity with a decision to decline/defer compaction ("auto-compaction handles it"), so the wrong number consistently produces the wrong context-management action.
• Reproduced 12+ times across two independent accounts on different plan tiers (personal Max 20x and a separate Enterprise account), which rules out account/plan configuration.

Not tied to any specific file type or project structure — occurs on normal agentic coding sessions regardless of language or layout. The common factor is context fill level, not project shape.

Cross-reference: this is likely the same underlying issue as the model's answer when asked directly for its context window size — it reports ~15M there too. The documented Claude Code window for Fable 5 is 1M (~830K usable before auto-compaction).

--- Suspected mechanism (SPECULATION — I can't see model internals, flagging as a guess): Newer models reportedly no longer receive the per-turn injected "token usage: X/Y remaining" capacity signal that earlier models got. If Fable has no live runtime signal for remaining context, it may be falling back on a fixed internal capacity figure (~15M) baked in at training/config time, which would explain both the consistency of the number and its independence from actual usage. Offered only as a possible direction, not a claim — the observable defect above stands regardless of cause.