Capped continuity mode after ChatGPT plan limits (Luna fallback)

What variant of Codex are you using?

All ChatGPT-authenticated Codex surfaces: App, CLI/TUI, IDE Extension, and Web.

What feature would you like to see?

When a user's shared ChatGPT/Codex plan allowance is genuinely exhausted, offer an explicit, no-incremental-charge Continuity mode backed by a small, separately capped GPT-5.6 Luna allowance until the primary allowance resets.

Suggested experience:

Primary Codex allowance exhausted. Continue in capped Luna Continuity mode until reset? - Continue on Luna - Wait for reset - Use credits / upgrade

Constraints:

• Make this a separate account-level entitlement with a hard monthly cap, not a refill granted each time a limit is hit.
• Do not silently change models. Show Luna, reasoning effort, remaining reserve, and the primary reset time persistently.
• Never spend credits, enable auto-refill, or create a charge without separate explicit consent.
• Preserve the thread, repository/worktree, permissions, completed tool results, and approval state.
• Compact into an inspectable hand-off before switching so a long prompt does not consume the reserve merely by re-reading history.
• Bound automatic replay: retry only if no assistant output or tool side effect was committed; otherwise resume from an explicit continuation boundary.
• Consider disabling multi-agent/ultra fan-out and background automations while the reserve is active.
• Keep all existing safety, policy, sandbox, approval, and organisation restrictions.
• Trigger only for verified plan exhaustion, never authentication, billing, policy, safety, abuse, or capacity failures.
• Restore the primary model only at a safe turn boundary, with clear notice.

This is intentionally not a request for unlimited Luna. It is a proposal for a small first-party bridge that helps finish or safely hand over the tail of an in-progress task.

Additional information

Why this is technically and economically plausible enough to test

Official OpenAI documentation describes GPT-5.6 Luna as the cost-sensitive, high-volume member of the GPT-5.6 family. It currently lists the same 1.05M context window and Codex-relevant tools as Sol, at published API rates of $0.20 per million input tokens and $1.20 per million output tokens. Sol is listed at $4 / $20.

For a deliberately simple cap of 1M uncached input tokens plus 0.2M output tokens:

| Model | Published-price proxy |
|---|---:|
| GPT-5.6 Sol | $8.00 |
| GPT-5.6 Terra | $4.40 |
| GPT-5.6 Luna | $0.44 |

That makes the Luna proxy 94.5% lower than Sol for this workload shape.

These are public API list prices, not OpenAI's internal COGS, ChatGPT subscription accounting, or cost per completed task. They exclude tool infrastructure, safety processing, support, capacity constraints, cache behaviour, and extra turns caused by lower capability. The production cap should use OpenAI's measured marginal cost rather than public price or raw token count.

I could not find official OpenAI documentation establishing that a first-party lower-cost fallback is currently provided after Codex subscription exhaustion; this issue asks for that product behaviour rather than assuming it exists.

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 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)

Avoid double-counting CAC: it belongs in A only where retaining this user actually avoids 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 | $0.44 cost | $1 cost | $2 cost |
|---:|---:|---:|---:|
| $20 | 3.14% break-even retention lift | 7.14% | 14.29% |
| $100 | 0.63% | 1.43% | 2.86% |
| $200 | 0.31% | 0.71% | 1.43% |

If the causal benefit is three additional paid months, those thresholds divide by three. If lower capability creates retries or the feature cannibalises credit purchases/upgrades, thresholds rise.

Adoption, referral, and goodwill may add value, but should be measured rather than inserted into LTV as an assumption.

Red-team: ways this could fail

1. No causal retention effect: users who hit a limit may wait anyway; the reserve then adds cost without saving churn.
2. Cannibalisation: free continuity could reduce credit purchases, reset use, or plan upgrades.
3. Adverse selection: the cost concentrates in the heaviest and potentially least profitable subscribers.
4. Cost per completed task: a much cheaper token can still be expensive if Luna needs more turns, retries, tool calls, or human correction.
5. Quality and safety: a silent capability downgrade could cause incorrect edits or overconfident decisions. Visibility and unchanged approval gates are essential.
6. Long-context burn: carrying a large thread into the reserve can consume it immediately; compaction and a bounded hand-off are required.
7. Capacity and abuse: subscription limits may protect peak capacity and abuse controls, not only margin. The reserve needs independent circuit breakers.
8. Quota gaming: a per-event reserve can be farmed by intentionally exhausting primary quota.
9. Plan clarity/fairness: users may read "continuity" as unlimited service or object to plan-specific caps.
10. Implementation cost: entitlements, metering, retries, hand-off, cross-client state, telemetry, support, and incident response can outweigh inference savings.

Proposed experiment and rejection criteria

Randomise at account level among customers who actually hit a verified plan limit, stratified by plan and prior usage:

• Control: current limit/credits/upgrade experience
• Variant A: capped Luna continuity
• Variant B: a smaller cap or lower reasoning effort
• Optional variant: continuity limited to the currently active task/thread

Use an equal measured-cost cap across variants. Pre-register:

• 30- and 90-day paid retention, downgrade, and cancellation
• incremental credit/reset/upgrade contribution
• measured inference, tool, safety, and support cost
• task completion before reset
• reverts, corrections, abandoned turns, escalations to a stronger model, and support contacts
• safety incidents, abuse concentration, and peak-capacity impact
• satisfaction and trust after a visible downgrade

Reject or narrow the feature unless incremental retained contribution exceeds serving cost, lost credit/upgrade contribution, and amortised implementation/support cost while quality, safety, abuse, and capacity guardrails remain acceptable. Uptake alone is not evidence of LTV improvement.

Acceptance criteria

• [ ] Activates only on a verified ChatGPT/Codex plan limit.
• [ ] Explicit opt-in; no silent model switch or incremental charge.
• [ ] Separate, hard account-level cap that cannot be farmed through repeated exhaustion.
• [ ] Compact, inspectable hand-off and bounded reread cost.
• [ ] No duplicate replay after committed tool side effects.
• [ ] Existing sandbox, approval, safety, and organisation controls remain in force.
• [ ] Visible model, effort, reserve, and reset state on every Codex surface.
• [ ] Safe restoration to the primary model at a turn boundary.
• [ ] Account-level experiment measures retention, cannibalisation, cost, quality, safety, and capacity.
• [ ] Automatic kill switch if economic or operational guardrails fail.

Related, but not duplicate

• #32341 requests failover to a separately authenticated third-party provider. This request asks OpenAI for a first-party included Luna reserve.
• #32218 requests automatic redemption of a user's banked reset. This request neither spends nor auto-redeems a reset.
• #25937 reports unintended continuation after a hard limit. This request asks for an explicit, metered, visible entitlement rather than a bypass.

Sources

• Current OpenAI model positioning, capabilities, and prices: https://developers.openai.com/api/docs/models
• GPT-5.6 Luna details: https://developers.openai.com/api/docs/models/gpt-5.6-luna
• GPT-5.6 Sol details: https://developers.openai.com/api/docs/models/gpt-5.6-sol

Sources checked 28 August 2026.