Warn above the composer when the selected provider is already out of usage

[saphid]

Problem

When Usage → Limits already shows the selected provider at 0% left, the composer gives no sign of it. You learn only after sending, when the turn fails with "Usage limit reached". That costs a turn and the chance to pick another provider first. It matters most for work driven from mobile or left running.

On current main (a1d9d72), after one limited turn, Limits shows Codex at Session 0% left and Weekly 0% left. A fresh thread on the same provider still shows no warning, and Send is enabled:

Limits shows 0% left	Fresh thread: no warning, Send enabled

What already works on main, so this asks for none of it:

• A failed turn is clear: "Usage limit reached. Retry after …", a banner with the reset time, Resume at reset and Snooze until reset, and Limited in the sidebar.
• Queued messages stay held after a limit (fix(server): preserve queued messages after usage limits #13877). runtimeLayer.test.ts "handles a queued message after a usage_limit failure" passes on main.

So there is no bug here. This is new behavior, so I'm asking before opening a PR.

How I reproduced it (stub): no account was exhausted, so I ran the real Codex CLI 0.160.0 and T3's Codex adapter against a local fake upstream that returns 429 usage_limit_reached. One stub artifact: API-key auth can't read Codex limits before the first turn, so Limits fills in only after the first failure. With a signed-in ChatGPT account, the probe would show 0% before any send.

Smallest proposal

• A warning, never a block. The composer shows a warning when the selected provider's latest usage snapshot has a window at 100% that hasn't reset and applies to the selected model. Send, Enter, and the queue behave exactly as today. Snapshots can be stale, so the user decides.
• Text: "Usage limit used up. Codex has used its weekly limit (resets in 4d 5h). Pick another provider, or messages may fail until it resets." It says "may" because paid overage, like Claude extra usage or Codex credits, can keep a spent window serving.
• No duplicate banners. The warning is hidden while the thread already shows the "Usage limit reached" recovery banner.
• Clears itself. It disappears at reset (minute clock) or as soon as you pick a provider or model with headroom.
• Only where it applies. Usage windows gain optional modelScope, exceptModelScope, scopeLabel, and blocksSends fields:
  • Claude's per-model weekly (Fable) warns only for that model.
  • OpenCode Go warns only for opencode/* models.
  • Codex's main allowance does not warn for Spark, which has its own allowance.
  • Cursor's "Cursor Models" pool never warns on its own, because Grok and Composer fall back to "Other Models". A spent "Other Models" pool warns and names itself, because Claude, GPT, and Gemini have no fallback.
  • Servers mark snapshots scopedWindows, and clients ignore snapshots without it, so an older server never causes a wrong warning.
• Surfaces: web and desktop (composer banner stack, new and existing threads) and mobile (thread composer and New task).

Out of scope: blocking sends or holding queued work (what #12740 did), switching providers automatically (#15846, #6923), always-visible meters (#11891, #13241), and Claude low-priority mode (#13780).

After (candidate): warning on a fresh thread, Send still enabled. The screenshot shows earlier wording, since softened to "has used its … limit" and "may fail".

Acceptance criteria

1. A spent, unreset window that applies to the selection shows the warning on web (new and existing threads) and on mobile (thread and New task). Send stays enabled.
2. The warning goes away at reset, or right away after switching to a provider or model with headroom.
3. A thread already stopped by the limit shows only its recovery banner.
4. A spent Claude Fable weekly warns for Fable but not Sonnet. A spent Cursor Models pool does not warn, but a spent Other Models pool does. A snapshot from an older server does not warn.

Verification plan

• Shared unit tests for the selection rules: scope matching, stale resets, informational meters, and older snapshots.
• Server fixture tests for scope metadata, including runtime updates that keep a probed row's scope.
• Before and after browser captures against the stub above.
• Mobile: typecheck and tests, plus a simulator pass if you'd like one.

Decision needed

Is a non-blocking composer warning, with no send or queue gating, a direction you'd accept? If so, I'll open the PR from the ready branch saphid:feat/composer-usage-limit-warning.

Related: #12740 (closed; it blocked sends, and this proposal does not).

_{Drafted with Claude Opus 5.5 in Claude Code. Browser captures by GPT-6 Astra (Codex). Code reviewed by GPT-6.1 Sol (Codex).}