feat(web,mobile): snooze a thread until provider limits reset

[vitalyiegorov]

What Changed

When the provider instance behind a thread reports an exhausted usage window, the thread offers to snooze itself until the limits reset (one minute past the reset, so clock skew cannot wake it early). One behaviour, two entry points:

• Composer notice: "Usage limit reached · Limits reset 1:51 PM" with a one-tap Snooze until 1:52 PM. Dismissible per reset; the button disables while snooze is temporarily blocked (pending approval, queued turn start) but the reset time still shows.
• Snooze menus: the same wake time leads every thread snooze menu as Until limits reset while the limit is in force — the sidebar row popover, the row context menu, the chat-header menu, and the mobile row menu. Since feat: add custom snooze dates and durations #11800 those menus also end in Custom…; the limits preset still leads them while it is ahead, and expiring rows are skipped.

Snoozing is the existing thread snooze end to end: visibility-only, "Wake now" from the parked banner, nothing auto-resumes. Implements the proposal in #8920.

Client-only. #9507 already normalizes provider rate limits into ServerProvider.usageLimits and streams that snapshot to every client, so the reset is read straight off it:

• packages/shared/src/usageLimits.ts — exhaustedUntil(limits, now): the latest future reset among the account-wide windows at 100% (five_hour, seven_day, primary, secondary). Claude's model-scoped seven_day_<model> buckets limit one model, not the account, and are skipped.
• packages/client-runtime/src/state/threadSettled.ts — usageLimitSnoozePreset(resetsAt, now), the one preset both entry points render; resolveSnoozePresets prepends it when given limitsResetAt.
• Web: ChatView.tsx renders the notice from that preset; the sidebar popover, row menu, and header menu pass the thread's provider snapshot into the existing preset resolution. entities.ts gains a readThreadProviderSnapshot reader for the header menu.
• Mobile: the resolved provider instance each row already receives (fix(mobile): show the provider account badge on thread rows #9899) carries the provider's usage limits, and the row derives the reset from it for its snooze menu.
• docs/user/composer.md — one paragraph.

No contract, server, adapter, or migration change. Cursor, Grok, OpenCode and Antigravity publish no usage windows, so no offer there. Codex "workspace out of credits" exhausts no window, so no offer either. The bulk multi-select snooze omits the preset because selected threads can sit on different accounts, and the mobile thread screen has no snooze menu to extend.

Why

Hitting a limit mid-turn leaves a thread that looks like live work, and the reset time is the user's to remember. The Limits tab already shows the reset; this puts it on the thread that hit it, in the notice and in the menu the user already reaches for, with the one action that makes sense. It is the smallest change that turns the dead wait into a scheduled return without preempting the auto-resume discussion (#8401, #8577, #6796).

UI Changes

Captured against a Codex instance whose session window reports 100% used with a reset 3h20m out.

Composer notice — before, the limit is a plain line in the work log; after, the notice with the one-tap offer:

Sidebar row snooze menu — before and after, same thread, same moment:

Before	After

After tapping either, the thread parks with the existing banner and wake path:

No motion or timing changes, so no video.

Verification

• vp test run on usageLimits.test.ts, threadSnoozed.test.ts, Sidebar.snooze.test.ts, threadActionMenu.logic.test.ts, threadListV2.test.ts — 161 tests pass, including: latest reset wins across two exhausted windows; a model-scoped bucket at 100% yields nothing; 99% or a past reset yields nothing; the preset leads the menu only while the reset is ahead; the menu's wake time is the preset's; a mobile snooze:limits-reset selection resolves.
• Typecheck clean in packages/client-runtime, apps/web, apps/mobile; lint and format clean on the touched files.
• Integrated pass in the web client against a fake Codex app-server that reports the exhausted window (screenshots above).

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes (no motion added)

Earlier revisions

Until b6ca359 this PR carried its own reset time from the adapters through a typed limitResetsAt, a thread.session.rate-limit-set command, a session column and migration, and ingestion rules; #9507 landed the same normalization on the provider snapshot, so all of that was dropped. 868f239 folded the menu entry point in and trimmed the notice to the shared preset (no separate offer helper, toast, tooltip, or in-flight state).

---

Built by Claude Fable 5.1 in Claude Code.

🤖 Generated with Claude Code

Note

Add limits-reset snooze option to web and mobile thread menus

• Adds shared logic via exhaustedUntil and usageLimitSnoozePreset to find the latest future account-wide limit reset and generate a snooze preset waking 1 minute after the reset.
• Integrates the limits-reset option into web ChatView banners, SnoozePopoverButton, sidebar context menus, and useThreadActionMenu.
• Updates mobile ThreadListV2Row and resolveThreadListV2SnoozeMenuSelection to include and validate the limits-reset option.
• Adds a snoozePresetExpired check to discard stale snooze selections before submitting if the target time has passed.
• Behavioral Change: snoozeWakeDescription now rounds day intervals from local calendar-day starts instead of fixed millisecond buckets, fixing wake-date classification across DST day lengths.

^{Macroscope summarized 1b676c5.}

Summary by CodeRabbit

• New Features

  • Added usage-limit reset notices on web, including reset times and an option to snooze threads until limits reset.
  • Added an “Until limits reset” snooze option to web and mobile thread menus while provider limits are active.
  • Snooze labels now reflect reset dates and times, including resets on later days.
  • Invalid or expired reset times no longer produce a limits-reset snooze option.

• Documentation

  • Documented usage-limit notifications, snoozing behavior, availability conditions, and timing.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a new cross-platform workflow that detects provider usage exhaustion, presents a new automatic banner, and lets users persist a snooze until limits reset. It changes several production UI and state paths rather than only adding isolated helper logic or documentation.

No code changes detected at 842d940. Prior analysis still applies.

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

[cursor]

Stale Bugbot comment from a previous run.

[vitalyiegorov]

Rewritten on top of today's main as a single client-only commit (b6ca359). #9507 now publishes each provider's usage windows with reset times on the provider snapshot, so the contract field, thread.session.rate-limit-set command, migration, ingestion, and adapter changes from the earlier revision are gone; the notice reads the reset off that snapshot. The UI and copy are unchanged. 23 files / +1116 −19 became 6 files / +344 −2.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b6ca3590e95e431a5d16cea66cb1327b8e2ca731. Configure here.}

[vitalyiegorov]

Rebased onto main with #9899: the mobile rows now read the reset off the resolved provider instance (usageLimits on ThreadRowProviderInstance) instead of a second lookup in each screen, so the two list screens are no longer touched.

[juliusmarminge]

Superseded by merged #12687 (with #12686 / #12677) — snooze / resume limited threads until usage resets is on main.