[Desktop] Manual switch to GPT-5.6 Luna after usage exhaustion shows an active model, but every prompt remains blocked

Summary

Codex Desktop accepts a manual model switch to GPT-5.6 Luna after the shared Codex/Work usage allowance is exhausted and displays messaging that says:

You're now using Luna, a faster model for simpler tasks.

However, the immediately following prompt is rejected with:

You've hit your usage limit. Add credits to continue, or try again at .

This is not an automatic fallback report. The user manually selected Luna. The defect is that the product presents Luna as the active usable model even though the account has no execution allowance for the next message.

Steps to reproduce

1. Use Codex Desktop until the shared Codex/Work usage allowance is exhausted.
2. Open the model picker.
3. Manually select GPT-5.6 Luna.
4. Observe that the model selector changes to Luna and the UI displays You're now using Luna, a faster model for simpler tasks.
5. Send a minimal continuation prompt in the same task.
6. Observe that the request is immediately blocked by the usage-limit gate.

Expected behavior

The UI should distinguish model selection from available execution entitlement.

If Luna cannot run because the shared allowance is exhausted, Codex should do one of the following:

• disable the selection;
• label it selected, but unavailable until reset or credits are added;
• or allow selection but replace the success-style message with an explicit blocked-state notice.

If a separate Luna Reserve allowance is actually available, the product should show that exact allowance and the next request should execute against it.

The product should not say You're now using Luna in a way that implies work can continue when no Luna request can be admitted.

Actual behavior

• Luna appears selected and active.
• A success-style informational message states that Luna is now being used.
• The next prompt cannot execute at all because the shared usage allowance is exhausted.

Impact

This creates a false recovery affordance at the worst point in a long-running local coding task. The user may believe switching to the faster/lower-cost model will let the current task finish, only to discover that the composer remains hard-blocked.

The current UI conflates:

model selected

with:

model has an available usage bucket and can execute

Those are materially different states and should be presented separately.

Privacy

No private project names, repository paths, task content, account identifiers, or local implementation details are included. A redacted screenshot of the contradictory UI state is retained privately.

Related reports

• #40939 — CLI cannot use Luna Reserve after standard usage is exhausted
• #41520 — Luna/reserve shown but unavailable
• #41220 — abnormal usage and effective-usable-work tracker

This report is distinct because it concerns the Desktop model picker and end-user messaging after a manual Luna selection, whether or not the account has Luna Reserve.

Start by reproducing the exhausted-allowance flow through the Desktop model picker and the usage-limit gate, verifying whether a Luna Reserve allowance exists. Compare the behavior with related reports #40939, #41520, and #41220. Done means the UI distinguishes model selection from execution availability and no longer presents an unusable Luna selection as active recovery.