[Bug]: Orchestrator V2 Usage Reset Tracker Broken

[SpyC0der77]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Use Codex until the session usage window is exhausted (Usage → Limits shows Session at 0% left with a reset countdown such as ↻ 4h 12m).
2. Open or continue a Codex thread and send a prompt so the turn fails on the usage limit.
3. Look at the composer usage-limit recovery banner.
4. Open Usage → Limits for the same Codex account and compare the Session reset countdown.

Expected behavior

The composer banner should show the same reset time already visible on Usage → Limits (for example Resets <local datetime>), and enable Resume at reset / Snooze until reset when that time is still in the future.

Actual behavior

The composer banner shows:

Usage limit reached
Reset time unavailable; retry manually

Usage → Limits for the same Codex account still shows Session 0% left with a real countdown (e.g. ↻ 4h 12m), while Weekly still has remaining quota.

The stored limit error also omits any wait string:

Codex usage limit reached. Send the message again once the limit resets.

(with a known reset it would include something like The session limit resets in 4h 12m).

Impact

Major degradation or frequent failure

Version or commit

t3code/codex-turn-mapping @ 30f213185 (orchestrator v2)

Environment

• macOS 27.0 (Build 26A428) - T3 Code (Nightly) desktop app - Provider: Codex (session limit exhausted; GPT-6-Astra / Codex models) - Node v24.13.1, Bun 1.4.2

Logs or stack traces

Thread/session error at limit stop:


Codex usage limit reached. Send the message again once the limit resets.


Root cause sketch: Usage → Limits reads `provider.usageLimits.windows[].resetsAt` from the rate-limits probe; the composer banner only uses `thread.runtime.usageLimitResetAt` from the turn failure’s `resetAt` (Codex in-session `rateLimitSnapshot` via `codexUsageLimitResetAt`). Those paths are not joined, so a missing turn `resetAt` yields “unavailable” while Limits still has the countdown.

Screenshots, recordings, or supporting files

image.png
image.png

Workaround

Working on it, haven't found one that worked (using Cursor to find it)

[juliusmarminge]

Triage

Confirmed on t3code/codex-turn-mapping at 30f213185 (current tip of that branch). Not a duplicate, and main does not have this recovery path.

The composer banner and Usage → Limits read different snapshots, and nothing copies one into the other.

The banner in UsageLimitRecoveryBanner uses only thread.runtime.usageLimitResetAt. That value is the latest root error item's failure.resetAt (threadErrorSummary). Codex sets it from the in-session rateLimitSnapshot in CodexAdapterV2, which starts empty and is filled only by account/rateLimits/updated. codexUsageLimitResetAt returns null unless every window at usedPercent >= 100 has a resetsAt. A notification that only names rateLimitReachedType, a 100% window with no resetsAt, or a non-codex limitId (those are ignored, including model-specific buckets) leaves resetAt null. The banner then shows "Reset time unavailable; retry manually" and hides Resume at reset / Snooze until reset. A later notification can backfill the turn item, but only when that notification itself produces a non-null reset.

Usage → Limits is the status probe in CodexProvider: account/rateLimits/read, mapped by codexRateLimitsToLimits, preferring rateLimitsByLimitId.codex. That result is what draws the Session countdown. It is never written into the adapter's rateLimitSnapshot. A probe that already has Session resetsAt therefore does not repair a turn that stopped without one. Weekly quota still remaining does not change this. Only exhausted windows are considered, and the probe windows are not consulted at all.

One correction: the stored sentence "Codex usage limit reached. Send the message again once the limit resets." is codexUsageLimitMessage's no-snapshot fallback. The adapter does not call that helper. It stores Codex's turn.error.message. The missing "resets in 4h 12m" clause is because that formatter is not on the turn path. The broken part is resetAt, which is what the banner and the auto-resume worker both require.

Same usageLimitResetAt field drives the mobile recovery card. Workaround is to retry manually once the Limits countdown reaches zero.

[SpyC0der77]

Here is what Space Bunny Free did (if it helps at all, if not just ignore this): # The core constraint

Everything hinges on one line in the orchestrator. Before my change it read:

failure.resetAt !== command.limitRecovery.resetAt  // → reject

This is an exact string match between the reset recorded on the turn's failure and the reset the client sends back. It exists for a real reason: if a limit moved between the moment we showed the user "resets at 3pm" and the moment they clicked, scheduling recovery against the stale value would wake a thread into a limit that's still active.

The consequence is that the client can never invent a reset. Any value it derived from the Usage page would differ from the recorded one and be rejected. That's exactly what the original code did, and exactly why the button rendered but always errored. So the reset has to be written onto the failure itself, and the client just echoes back what the server tells it.

Two layers, because there are two kinds of broken thread

New failures get fixed at the adapter, where the failure is constructed. CodexAdapterV2.ts:1625:

const publishedUsageLimitResetAt = Effect.fnUntraced(function* () {
  if (!adapterOptions.getUsageLimits) return null;
  return usageLimitResetAtFromLimits(yield* adapterOptions.getUsageLimits);
});

This sits after codexUsageLimitResetAt in the fallback chain at all three reset sites. The existing chain was already event.failure.resetAt ?? codexUsageLimitResetAt(...); I appended one more ??. The helper is read off snapshot.getSnapshot — the same published Limits snapshot the Usage page renders.

One detail worth flagging: snapshot is declared after the adapter is constructed, so the read is Effect.suspended (CodexDriver.ts:191). The pre-existing onUsageLimits was an arrow function, so it evaluated lazily and the ordering was fine; a bare .pipe() would have evaluated eagerly and thrown used before declaration. The comment records why.

Already-failed threads can't be fixed there — the failure is persisted, and the event log is immutable. So the sweep backfills them: UsageLimitRecoveryWorker.ts asks the projection for limit-blocked threads whose failure named no reset (ProjectionStore.ts:5755), takes the reset from the provider's published snapshot, and dispatches it. The orchestrator then records it by emitting a turn-item.updated carrying the filled failure.

That's why this is an appended event rather than a mutated row — the adapter's late-fill already does exactly this, so there's precedent, and the projection replays it like any other event.

The one safety change, and why it's narrow

Orchestrator.ts:2450:

const resetAgrees    = failure?.resetAt === command.limitRecovery.resetAt;
const resetBackfills = failure?.resetAt == null && failureItem !== null;

Previously this was a single equality. Now a mismatch is acceptable in exactly one case: the failure recorded nothing at all.

The argument is that the check exists to invalidate a limit the user was shown. If no reset was ever recorded, nothing was shown, so there's nothing to invalidate. Every other guard still runs unchanged — it's still the latest failed run, still classified usage_limit, the reset must be in the future, thread not archived or settled, no pending runtime request. A failure that named a reset still demands an exact match, so a limit that moved under you still refuses.

I want to be explicit that this is the one place I loosened a safety check, and it's the reason the backfill persists the value rather than passing it through on every check: once recorded, it's the truth everything else compares against.

Why the fallback is conservative

usageLimitResetAtFromLimits (usageLimits.ts:505) only considers windows at usedPercent >= 100 that report a resetsAt, and picks the latest. So a resume is scheduled after every known exhausted window has reset. It over-waits rather than under-waits, and it declines to guess when no exhausted window names a reset. It also returns null on limits.unavailable, so a failed probe can't fabricate a recovery.

Two design choices I'd defend

I reverted the client fallback rather than fixing it. It was the wrong layer: no client-computed value can satisfy the invariant. Leaving it in would have meant shipping a button that always fails.

The SQL and in-memory projection paths are both implemented. ProjectionStore has layer (SQL, production) and layerMemory (tests), and getLimitRecoveryCandidates is duplicated across them. I mirrored that, using threadErrorSummary in the SQL path so both classify a thread identically — otherwise a thread could qualify for backfill in one path and not the other.

What I did not do

• codexUsageLimitMessage still omits the timing from its sentence, so the message won't name the reset even though the button now works. Cosmetic, but inconsistent.
• I didn't touch Claude, Grok, Cursor, or OpenCode. This is Codex-specific because Codex is the driver whose notification goes partial — the other adapters aren't affected by that particular gap.
• Nothing is verified in a real client. Every claim above is from tests and your event log.