[FEATURE] Capped continuity allowance after plan limits (Sonnet low / Haiku)

Preflight Checklist

• [x] I searched existing enhancement requests. The closest issues are listed below; none asks for a first-party, separately capped allowance that activates only after a shared subscription hard stop.
• [x] This is a single feature request.

Problem Statement

When a Claude subscription's shared session or weekly allowance is exhausted, Claude Code blocks further requests until reset. Anthropic's current error reference says those two limits are shared across models, so choosing Haiku does not restore access. Model-specific Opus or Sonnet limits are different: a user may continue on a model outside the exhausted family.

A hard stop can strand an in-progress engineering task after the user and Claude have already paid the cognitive and token cost of establishing context. Waiting, buying usage credits, or switching to an API key remain valid options, but none provides a small included bridge for finishing a mechanical tail such as running tests, correcting one failure, documenting state, or preparing a safe hand-off.

The product hypothesis is deliberately narrower than "more free usage":

A small, first-party continuity allowance, available at no incremental charge only after a genuine shared plan limit, may preserve more customer contribution and trust than it costs to serve.

This is a hypothesis to test, not a claim that lower per-token price automatically makes the feature profitable.

Proposed Solution

At a genuine shared session or weekly hard stop, offer an explicit choice such as:

Primary allowance exhausted. Continue in capped Continuity mode until reset? - Sonnet at low effort, where the account supports it - Haiku - Wait for reset - Use usage credits

Suggested constraints:

• Make the continuity reserve a separate, account-level entitlement with a hard monthly cap. Do not replenish it per limit event, because that invites quota gaming.
• Do not silently downgrade. Show the active model, effort, remaining reserve, normal reset time, and an always-visible Continuity mode indicator.
• Never consume usage credits, enable auto-refill, or create a charge without a separate explicit action.
• Preserve the thread, repository/worktree, tool permissions, and completed tool results.
• Before switching, create a compact, inspectable hand-off. This matters because current Sonnet has a 1M-token context window while Haiku has 200K; a session that cannot be represented safely inside the target model's context should not be downgraded automatically.
• Permit Sonnet low as one experiment arm. Haiku currently has no effort control, so it should be presented simply as Haiku rather than "Haiku low".
• Bound automatic replay: retry the interrupted turn only if no assistant output or tool side effect was committed. Otherwise resume from an explicit continuation boundary.
• Consider disabling expensive fan-out, teammates, background work, and ultracode while the reserve is active.
• Keep all existing safety, policy, sandbox, approval, and organisation model restrictions unchanged.
• Apply the reserve only to plan exhaustion, never to authentication, billing, policy, safety-classifier, abuse, or capacity errors.

Alternative Solutions

• Wait/auto-continue at reset: useful, but it does not preserve the user's current attention or finish the safe tail of a task.
• Usage credits or plan upgrade: should remain available, but charging is a different proposition from a small included continuity benefit.
• API-key fallback: moves billing and credentials to another path and is not a first-party subscription allowance.
• Warnings and usage indicators: reduce surprise but do not provide continuity.
• Broadly free Haiku: much harder to bound economically. This request activates only after a verified shared hard stop and remains separately capped.

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

1. A subscribed user is halfway through a multi-file change.
2. The shared session limit is genuinely exhausted after edits have been made but before tests and a hand-off are complete.
3. Claude Code offers Continuity mode.
4. The user chooses Sonnet at low effort or Haiku.
5. Claude Code compacts the task state into an inspectable hand-off and checks that it fits the target model.
6. The lower-cost model runs the scoped verification, fixes a small failure if authorised, and records what remains.
7. The normal model becomes available again at reset. Claude Code asks before switching back if a turn is active.

Additional Context

Published-price proxy

Anthropic's current model overview lists these API prices per million input/output tokens:

• Fable 5: $10 / $50
• Opus 5: $5 / $25
• Sonnet 5: $2 / $10
• Haiku 4.5: $1 / $5

For a deliberately simple cap of 1M uncached input tokens plus 0.2M output tokens, the API-list-price proxy is:

| Model | Published-price proxy |
|---|---:|
| Fable | $20.00 |
| Opus | $10.00 |
| Sonnet | $4.00 |
| Haiku | $2.00 |

This is not Anthropic's internal COGS, subscription quota accounting, or cost per completed task. It excludes cache effects, tool infrastructure, support, safety processing, and the possibility that a weaker model needs more turns. It is only a transparent way to size an experiment. The cap should ultimately be set in Anthropic's measured marginal cost, not raw tokens or public API list price.

Unit-economics model

Per continuity-using customer-month, define:

• C: measured incremental serving cost of the reserve
• R: monthly subscription revenue
• g: pre-feature contribution margin
• ΔL: incremental paid months caused by the feature
• p: causal probability that Continuity mode produces that retention outcome
• A: genuinely avoidable support or reacquisition cost
• K: cannibalised usage-credit/upgrade contribution plus amortised engineering and support cost

Then:

Expected net value = p × (R × g × ΔL + A) − C − K

and:

Break-even p = (C + K) / (R × g × ΔL + A)

Do not add CAC to retained LTV automatically: that double-counts value unless a cancellation would really have required paid reacquisition or replacement.

Illustrative sensitivity, using a 70% contribution margin, one incremental paid month, no credit for avoided CAC/support, and temporarily ignoring cannibalisation/implementation cost:

| Illustrative monthly revenue | Haiku proxy ($2) | Sonnet proxy ($4) |
|---:|---:|---:|
| $20 | 14.29% break-even retention lift | 28.57% |
| $100 | 2.86% | 5.71% |
| $200 | 1.43% | 2.86% |

If the causal benefit is three additional paid months, those thresholds divide by three. Conversely, credit cannibalisation, extra turns, or support cost raises them. This table shows why Haiku or a smaller Sonnet-low tranche may make sense on lower-priced plans while a larger allowance might be viable on higher-value plans.

New-user adoption and word-of-mouth may add value, but should be measured separately through referral and checkout conversion rather than assumed.

Red-team: ways this could lose money or harm users

1. No causal churn effect: limit-hitting users may simply wait, making the reserve pure cost.
2. Cannibalisation: included continuity may reduce usage-credit purchases or upgrades more than it preserves retention.
3. Adverse selection: the heaviest, least profitable users will consume the reserve most often; averages can hide a costly tail.
4. More turns per task: Haiku's lower token price may be offset by retries, backtracking, re-reading, or human correction. Cost per completed task matters more than cost per token.
5. Quality and safety: a quiet capability downgrade could introduce incorrect edits or unsafe confidence. The switch must be visible and existing approval gates must remain.
6. Context mismatch and cold state: Haiku's smaller context window can make direct continuation impossible; forced compaction may omit a crucial constraint.
7. Capacity is not only a pricing problem: plan limits may protect peak capacity, abuse controls, or reliability. A reserve needs its own capacity and abuse circuit breakers.
8. Quota gaming: a reserve granted per incident can be farmed by exhausting a premium model intentionally.
9. Plan confusion and fairness: users may mistake the reserve for unlimited service or regard different caps across plans as arbitrary.
10. Implementation surface: entitlement, metering, retries, context hand-off, every client surface, and support operations all add cost.

Proposed experiment and rejection criteria

Randomise at account level among users who actually hit a shared hard stop, stratified by plan and prior usage:

• Control: current wait / credits / upgrade experience
• Variant A: capped Haiku continuity
• Variant B: a smaller, equal-expected-cost Sonnet-low continuity tranche
• Optional variant: user chooses between the two within one cost cap

Pre-register:

• 30- and 90-day paid retention and downgrade/cancellation rates
• incremental usage-credit and upgrade contribution
• measured marginal inference/tool/support cost
• task completion before reset
• reverts, corrections, abandoned turns, support contacts, and safety incidents
• capacity impact and abuse concentration by percentile
• user trust/satisfaction after a visible downgrade

Reject or narrow the feature if incremental retained contribution does not exceed serving cost, lost credit/upgrade contribution, and amortised implementation/support cost; or if quality, safety, support, abuse, or capacity guardrails regress materially. Do not infer LTV impact from uptake alone.

Acceptance Criteria

• [ ] Activates only after a verified shared plan limit.
• [ ] Explicit, reversible opt-in with no silent downgrade or charge.
• [ ] Separate, hard account-level cap that cannot be replenished by repeatedly hitting limits.
• [ ] Safe, inspectable context hand-off that refuses an unsafe fit.
• [ ] No duplicate replay after committed tool side effects.
• [ ] Existing permissions, safety controls, and organisation policy remain in force.
• [ ] Visible model, effort, reserve, and reset state.
• [ ] Account-level experiment can measure retention, cannibalisation, cost, quality, safety, and capacity.
• [ ] Automatic kill switch if economic or operational guardrails fail.

Related, but not duplicate

• #29611 requested broadly cheaper/free Haiku for orchestration and was closed as out of scope. This request is limited to first-party continuity after a verified hard stop.
• #72497 concerns prompt suggestions near a limit, not post-limit task continuation.
• #86580 documents the productivity cost of session interruptions; this issue proposes a bounded mechanism and a falsifiable business test.

Sources

• Claude Code usage-limit behaviour: https://code.claude.com/docs/en/errors
• Claude Code model and effort configuration: https://code.claude.com/docs/en/model-config
• Current Claude model capabilities and published prices: https://platform.claude.com/docs/en/models/overview

Sources checked 28 August 2026.