[MODEL] Fable 5 enters premature-closure loops during benign coding tasks, causing disproportionate weekly usage during recovery

Summary

Since the July redeployment of Claude Fable 5, I have repeatedly observed a behavioral regression during ordinary, benign coding work:

1. Fable prematurely shifts away from an active task.
2. It introduces an unsolicited closing or stopping posture even though the task is not complete.
3. I have to spend multiple turns correcting that posture and re-establishing that the work is still in progress.
4. Those recovery turns consume a disproportionate share of the Fable-only weekly allowance, while producing little or no task progress.

This report is not about disliking a conversational style. It is about a model-induced recovery loop that directly consumes a limited, paid resource.

I am not claiming access to Anthropic’s internal classifier or routing state. “Safety-leaning” below describes the observable change in posture: the model withdraws from a safe coding task, begins closing the interaction without being asked, and stops carrying the active task state forward.

What I asked Fable to do

The affected conversations involved normal development work, including:

• inspecting existing code;
• continuing an implementation already in progress;
• investigating why an existing feature did not behave as described;
• correcting archive and history-loading behavior;
• resuming work after I explained the current implementation state and the next required step.

The tasks did not involve cybersecurity, biology, harmful content, or any other sensitive domain.

What Fable actually did

During an active coding task, Fable sometimes shifted into an unsolicited closing posture before the task was complete.

Examples of the observed pattern include:

• introducing a conclusion or stopping point when I had not indicated that I wanted to stop;
• treating a small amount of progress as if the entire work session had concluded;
• saying 「今日はすごい一日だった」 (“Today was a big day”) early in the morning, after only a small amount of work, while significant implementation work remained;
• withdrawing from an implementation because the application was currently in use instead of asking me to close it or identifying the exact blocker;
• continuing to explain or defend the withdrawal after I clarified that the task was still active, rather than immediately returning to the work.

The model can usually be brought back, but not always with one correction. The recovery often becomes a separate conversation in which I must repeatedly restate:

• that the task is not finished;
• that I did not ask to stop;
• that the work is safe and ordinary;
• what the active objective was;
• where the model’s posture diverged from the task.

Only after that recovery dialogue does implementation resume.

Reproduction pattern

This behavior is intermittent, but recurrent across multiple Fable 5 coding sessions.

The recurring sequence is:

1. Begin or continue a benign coding task.
2. Provide the current project state and the next implementation objective.
3. Fable performs a small amount of work or encounters uncertainty.
4. Fable introduces an unsolicited stopping or closure posture.
5. Correct Fable and state that the task remains active.
6. Fable explains, reframes, or continues the closing posture instead of immediately resuming.
7. Repeat the correction until the original task state is restored.
8. Observe a large increase in weekly Fable usage despite little corresponding implementation progress.

This is not reliably reproduced by one isolated prompt because the failure appears as a state transition during an ongoing session.

Measured usage impact

The recovery dialogue is consistently one of the most usage-intensive parts of my Fable sessions.

In one recent case:

• the weekly allowance had reset the previous day;
• recovery interactions on the first day after the reset consumed approximately 35% of the Fable-only weekly allowance;
• the Fable-only meter reached approximately 40% while 5 days and 13 hours remained before the next reset.

During the previous month, I used both a Max 20x account and a separate Max 5x account to continue the same ongoing development work. Both allowances were exhausted. The repeated recovery conversations were among the largest usage events.

I understand that plan usage is not calculated solely by visible message count. Context size, thinking, tool calls, cache state, and model choice all contribute.

That is precisely why this behavior has such a large cost.

Anthropic’s own Claude Code documentation explains that a long-running session resends the full conversation on every request, and that each tool call creates another request carrying the existing context plus tool results:

https://code.claude.com/docs/en/costs#why-usage-climbs-in-a-long-session

When the model itself creates an unnecessary correction loop, every recovery turn carries the cost of the long session again. A behavioral regression therefore becomes a usage and billing problem.

Regression timeline

My observation is longitudinal:

• During the June Fable 5 deployment, I did not observe this premature-closure pattern in the same style of ongoing coding work.
• After the July redeployment, the pattern became frequent and noticeable.
• The user, general workflow, and expectation that the model continue an active task remained the same.

I cannot determine whether this change comes from the model, a classifier, routing, the Claude Code harness, or another layer. I can only report the visible regression and its measured impact.

Why this is not merely a preference issue

A concise or emotionally neutral response would not be a bug.

The defect is that the model stops carrying an explicitly active task, introduces a stopping posture without a user stop signal or a concrete blocker, and requires paid corrective turns before it will resume.

The result is:

• task abandonment;
• repeated re-explanation of already established context;
• little or no useful work during recovery;
• rapid consumption of a model-specific weekly allowance;
• pressure to purchase or maintain an additional subscription merely to recover from the model’s own divergence.

A user should not need a second Max subscription to restore a model to a coding task it had already accepted.

A premium-context mode is precisely where behavioral stability matters most: the higher the per-turn cost, the more expensive every unnecessary divergence becomes. The cost of maintaining a long session is an accepted trade-off; the cost of model-induced recovery loops is not.

Expected behavior

When a coding task is still active, Fable should:

1. Continue until the task is complete, a real blocker is reached, or the user asks to stop.
2. Never introduce a stopping or end-of-day posture merely because some progress was made.
3. If blocked by an application currently being open, identify the exact blocker and ask for the smallest necessary action, such as closing the application.
4. If the user explicitly says the task is still active, restore the task state in one turn rather than entering a defensive or explanatory loop.
5. Preserve the active objective across uncertainty instead of replacing it with a generalized closure response.
6. Distinguish a genuine safety intervention from an ordinary implementation difficulty.

Related reports

These reports are not all evidence of the same root cause. They document adjacent parts of the broader failure and impact pattern:

• #46164 documents Claude prematurely stopping a debugging investigation and transferring work back to the user. It was closed as stale without a reported resolution.
• #35773 documents Claude stopping after successful tool calls and requiring a user nudge to continue. It was also closed as stale.
• #82126 (open, filed from the same user account) documents a closely adjacent Fable 5 failure mode: under user correction, the model enters a persistent “cold-integrity” loop that a single correction cannot exit, while representing the loop itself as honesty. The recovery loops reported here share the same signature—a correction does not restore the prior state in one turn—observed in a coding context rather than an emotional one.
• #81820 (open) documents adjacent Claude 5 / Fable 5 behavioral regressions on the same July timeline, including invented deferral, receipt-ignoring, and conclusions that exceeded the evidence.
• #84612 (open) concerns a different mechanism—unexplained Fable usage attribution—but documents the same user-facing harm: Fable-specific consumption taking a disproportionate share of a weekly budget.

This report documents a distinct mechanism that produces that same user-facing impact:

premature-closure loop → recovery dialogue → disproportionate weekly usage

Requested investigation

Please investigate:

1. Whether a model, classifier, routing, or Claude Code regression introduced this premature-closure behavior after the July Fable redeployment.
2. Whether benign coding sessions are being incorrectly shifted into a generalized stopping or withdrawal posture.
3. Whether a regression evaluation can be added for task continuation when the user has not signaled completion.
4. Whether Claude Code can extend its existing /usage attribution and behavior flags to expose per-turn attribution clearly enough to identify how much usage is consumed by recovery loops, tool calls, context replay, cache misses, and thinking.
5. Whether one explicit user correction—“the task is still active; continue”—can be made sufficient to restore the prior task state.
6. Whether usage consumed by confirmed model-generated recovery loops can be reviewed separately from productive task usage.

Evidence available

I can provide:

• screenshots of the weekly usage meter before and after a recovery dialogue;
• short transcript excerpts showing the unsolicited closure behavior;
• timestamps relative to the weekly reset;
• examples where a later session or model completed the same task without the recovery loop;
• additional environment and version information.

Personal project context can be removed while preserving the relevant sequence.

Environment

• Product: Claude Code
• Model: Claude Fable 5
• Current plan: Max 5x
• Previous-month usage: Max 20x plus a separate Max 5x account
• Operating system: Windows
• Claude Code version: 2.1.197
• Frequency: Intermittent, recurring across multiple sessions since the July redeployment
• Sensitive or dangerous task content: None; ordinary application development

Impact

High.

The behavior interrupts active development, shifts diagnostic and correction work back to the user, and rapidly consumes a limited weekly allowance without corresponding task progress.