[jaikhuranna]

Problem

When Codex refuses a turn for a usage limit, the stop sometimes has no reset time. Clients then say "the provider did not report a reset time" and offer only a manual retry, even though Codex had already sent the reset.

Codex reports usage in whole percentages, so the last account/rateLimits/updated before a refusal can still read 99%. codexUsageLimitResetAt only counted windows at 100%. In one log, two threads hit the limit 2.4 s apart with the same resetsAt:

	last codex update before the refusal	failure.resetAt
thread A	primary: { usedPercent: 99, resetsAt: 1792287729 }, secondary 16%	null
thread B	primary: { usedPercent: 100, resetsAt: 1792287729 }	2026-10-18T01:42:09.000Z

Change

All changes are in codexUsageLimitResetAt. The adapter only passes it the current time.

 windows = codex windows
+  drop windows whose reset has already passed      // they renewed since they were observed
 if any window reads 100%
   use those windows
+else if exactly one window reads 99%
+  use it                                          // it must be the one that ran out
 else
   no reset                                        // unchanged
 reset = latest reset among the chosen windows

• Exactly one 99% window: if both the 5-hour and weekly windows read 99%, either could have run out, so the stop records no reset, as it does today. Main's existing late-update path then fills it once an update shows a window at 100%.
• A recorded reset never changes: the adapter still fills a missing reset once, at the stop or on a late update. Armed recovery is keyed by the reset time, so changing it later would drop a manually armed resume.
• Renewed windows: without this filter, the 99% rule could pick a window that has already renewed. The stop would then get a past reset that recovery rejects, and fill-once would keep it.

Scope and approval

Fixes the first case in #14169, which a maintainer triaged here.

This overlaps #18721 ("fix(server): Codex usage-limit stops keep their reset time"). That PR also adds a fallback to the published limits for sessions refused before any rate-limit update. Its branch currently conflicts with main. This PR is the narrower 99% fix on current main; if 18721 lands first, close this one. I posted an end-to-end reproduction of the 99% case on 18721 here.

Verification

Real client. An isolated dev server with showcase data, its Codex binary pointed at a wrapper around the real codex app-server. The wrapper answers turn/start with a 99% primary update (secondary 16%) and then a usageLimitExceeded failure: thread A's sequence. It drops the real account's rate-limit updates.

Before (main)	After (this PR)

The banner's reset (5:24:45 PM) matches the faked window's resetsAt to the second. The after shot was taken on an earlier revision of this commit, which takes the same path for this case. On the final commit that path is covered by the rounded-reset replay below.

Tests. vp test run apps/server/src/provider/codexUsageLimits.test.ts apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.test.ts: 195 passed.

• New adapter replay rows in "classifies Codex terminal failures":
  • rounded-reset: 99% update, then refusal; the stop gets the reset.
  • late-rounded-reset: refusal, then a 99% update; the stop gets the reset.
  • ambiguous-late-reset: both windows at 99%, so the stop has no reset; a 100% update then fills it.
• New unit cases: a single 99% window counts; a 100% window wins over a 99% one; two 99% windows give no reset; renewed windows are ignored.
• Mutations: restoring the 100%-only rule fails 4 tests (including both 99% replays); guessing when several windows read 99% fails 2.
• tsc-rs --noEmit in apps/server passes. vp lint on the touched files reports only two existing warnings on lines this PR doesn't touch.

Not covered: a refusal where one window reads 99% but a different window actually ran out after jumping 2% or more between updates. The rule would pick the 99% window's reset, which is the later one when that is the weekly window. This needs both windows near the limit at once, so it is rare.

Merge danger

Door: two-way. No stored data or contracts change, and reverting restores today's behavior.

Blast radius: small. It affects only Codex usage-limit stops: more of them get a reset time, so clients offer resume or snooze at reset instead of manual retry.

Model and harness: Claude Opus 5.5 (claude-opus-5-5) in Claude Code, run from T3 Code. Reviewed over four rounds by GPT-6.1 Sol (Codex) and Claude Opus 5.5.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at ebcc5ee

Macroscope's review found this PR approvable — This is a focused Codex usage-limit bug fix that preserves existing recovery behavior while filling in reset times only for an unambiguous active 99% window. It introduces no schema, deployment, default, security, or static-analysis changes, and the behavior is covered by targeted tests.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

Important

Review skipped

We couldn't safely recover the incremental review. No full review was started, and the last reviewed checkpoint was preserved. Retry later, or explicitly request a full review by commenting @coderabbitai full review.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: 795cfc9e-72de-4224-8dc6-e3744638287a

📥 Commits

Reviewing files that changed from the base of the PR and between 9c16146 and ebcc5ee.

📒 Files selected for processing: 4

• apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.test.ts
• apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts
• apps/server/src/provider/codexUsageLimits.test.ts
• apps/server/src/provider/codexUsageLimits.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

📝 Walkthrough

The usage-limit reset helper now considers the observation time and can infer a reset from a unique window at 99% or higher. The adapter supplies the current timestamp at reset-time calculation points. Tests cover reset inference and terminal events with late snapshots.

Changes: Codex usage-limit reset inference

Layer / File(s)	Summary
Reset inference rules apps/server/src/provider/codexUsageLimits.ts, apps/server/src/provider/codexUsageLimits.test.ts	The helper excludes windows whose reset time has passed. It uses exhausted windows first, or a single active window at 99% or higher when no window is exhausted. Tests cover ambiguous windows, invalid observation times, and reset selection.
Adapter reset-time handling apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts, apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.test.ts	The adapter passes the current ISO timestamp to reset-time inference for rate-limit updates and usage-limit terminal handling. Tests cover rounded, late, and ambiguous snapshots.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to ebcc5

The reset-time change is ready to merge after normal checks.

Security architecture risk: 🔵 Low · up to ebcc5

The change affects when stopped Codex threads can resume, but does not introduce a new endpoint or expand execution privileges. Existing recovery checks remain intact. Some scheduling uncertainty remains because the provider guarantee behind selecting a single 99% window is not established.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• observed — A rate-limit snapshot is shared by stopped turns within its owning provider session, so one inferred reset can populate missing metadata on multiple stopped threads. The state is not newly global, and downstream continuation checks retain per-thread, per-run and provider-instance identity.

Security Findings and Attack Paths

• inferred — The inspected change does not establish a new attacker-controlled path to execution. Provider-supplied percentages now influence recovery timing more broadly, but do not replace the existing usage-limit failure classification or continuation admission controls. An incorrect inferred timestamp is not, by itself, an authorization bypass.

Trust Boundaries and Controls

• observed — The existing snapshot merge rejects explicitly model-specific allowances rather than replacing the main Codex allowance. Applying inferred resets remains confined to usage-limit failures, and late updates skip failures that already contain a reset.

Resilience and Maintainability Implications

• inferred — The single-99% fallback assumes that no other window exhausted after its last lower reading. That provider guarantee is not established by the available source or tests. If the assumption fails, the recorded reset could cause an early retry or unnecessary delay, and fill-once behavior would preserve it. Existing identity checks and expired-reset rejection contain the demonstrated effect to recovery scheduling rather than expanded authority.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: preserving Codex stop reset times when the final usage update reports 99%.
Description check		The description includes complete Problem, Change, Scope and approval, and Verification sections. It explains the behavior, links the issue and approval, reports focused test results, documents limita…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Description check

Explanation

The description includes complete Problem, Change, Scope and approval, and Verification sections. It explains the behavior, links the issue and approval, reports focused test results, documents limitations, and describes scope and risk.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[juliusmarminge]

Thanks @jaikhuranna for the reproduction and focused fix. Closing this as a duplicate of #18721 by @voltcrash, now maintained by @juliusmarminge; its newer branch addresses the same 99% reset and the missing-snapshot case. The two approaches differ when both windows read 99%, so your conservative ambiguity handling is useful context for that PR.

[jaikhuranna]

Thanks @jaikhuranna for the reproduction and focused fix. Closing this as a duplicate of #18721 by @voltcrash, now maintained by @juliusmarminge; its newer branch addresses the same 99% reset and the missing-snapshot case. The two approaches differ when both windows read 99%, so your conservative ambiguity handling is useful context for that PR.

Thanks for the credit @juliusmarminge . I was thinking of another approach of getting reset times. Maybe we can get them from the providers themselves instead of the "usage limit reached" response. we can consistently get when it's resetting. just like how we show it in the usage limits tab. This would be more consistent than relying on their response which may change. What do you think?

Update: i'm checking if someone has already worked on it. I think this will make it consistent for all Providers instead of just codex in this case.