feat(web,mobile): snooze a thread until provider limits reset - #9012
feat(web,mobile): snooze a thread until provider limits reset#9012vitalyiegorov wants to merge 5 commits into
Conversation
github-actions
Bot
added
vouch:unvouched
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
ApprovabilityVerdict: Not approved Macroscope's review found this PR not approvable — This cross-platform feature adds a usage-limit banner and provider-aware snooze behavior across shared runtime, web, and mobile production paths. An unresolved medium-severity issue can leave the web menu offering an expired reset option, so the resulting behavior merits human review. Not approved because:
Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
2e199ec to
8520eb7
Compare
5d2fbbc to
b6ca359
Compare
github-actions
Bot
added
vouch:trusted
vitalyiegorov
changed the title
|
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, |
There was a problem hiding this comment.
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 b6ca359. Configure here.
0e5e201 to
8e1cb7f
Compare
8e1cb7f to
868f239
Compare
vitalyiegorov
changed the title
3cc31db to
8d7f655
Compare
8d7f655 to
7d79b2f
Compare
Bugbot is paused — on-demand spend limit reachedBugbot uses usage-based billing for this team and has hit its on-demand spend limit. A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue. |
69e8587 to
c80dc21
Compare
When the provider instance behind a thread reports an exhausted usage window, the composer shows the reset time and offers to snooze the thread until a minute past it. Derived on the client from the provider snapshot that pingdotgg#9507 already publishes, so no contract, server, or migration change. Built with Claude Fable 5.1 in Claude Code.
The banner's "snooze until limits reset" now also leads every thread snooze menu while the limit is in force, built from the same preset so the two entry points can never disagree on the wake time.
The banner now builds its offer from the same preset the menus use, and loses its own toast, tooltip and in-flight state: the parked-thread banner that replaces it already offers Wake now.
A DST day is 23 or 25 hours long, so dividing elapsed time since midnight by a fixed day filed a wake just past midnight on the wrong day.
Ghost button, and the shared Tooltip primitive for the disabled reason, mirroring the resume-compaction action in the same stack.
c80dc21 to
860bf64
Compare
| [open, timestampFormat], | ||
| () => | ||
| open | ||
| ? resolveSnoozePresets(new Date(), timestampFormat, { |
There was a problem hiding this comment.
🟡 Medium components/Sidebar.tsx:447
The open snooze menu keeps showing limits-reset after limitsResetAt passes, and clicking it then calls onSnooze with a past snoozedUntil, resulting in an immediate/no-op wake instead of a valid snooze. useMemo only recomputes when open, timestampFormat, or usageLimits changes; add a time-based refresh or revalidate the preset at click time.
🤖 Copy this AI Prompt to have your agent fix this:
In file @apps/web/src/components/Sidebar.tsx around line 447:
The open snooze menu keeps showing `limits-reset` after `limitsResetAt` passes, and clicking it then calls `onSnooze` with a past `snoozedUntil`, resulting in an immediate/no-op wake instead of a valid snooze. `useMemo` only recomputes when `open`, `timestampFormat`, or `usageLimits` changes; add a time-based refresh or revalidate the preset at click time.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (16)
Included review availability: Your plan provides up to 10 included reviews per hour; 6 remain after this review. 📝 WalkthroughWalkthroughThe change adds usage-limit reset detection and a ChangesUsage-limit snooze
Estimated code review effort: 4 (Complex) | ~45 minutes Merge Risk: ⚪ Minimal · up to This change adds client-side usage-limit reset snoozing across web and mobile, with reset validation and focused tests. No merge-blocking risk remains. Sequence Diagram(s)sequenceDiagram
participant ChatView
participant ProviderUsageLimits
participant SnoozePresetResolver
participant ThreadAction
ChatView->>ProviderUsageLimits: calculate exhaustedUntil
ProviderUsageLimits-->>ChatView: return limitsResetAt
ChatView->>SnoozePresetResolver: resolve limits-reset preset
SnoozePresetResolver-->>ChatView: return wake time
ChatView->>ThreadAction: snooze thread until wake time
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 62.50% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 16 functions across 15 files. (1 skipped: 1 unsupported.)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
1 participant
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:
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.usageLimitsand 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-scopedseven_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;resolveSnoozePresetsprepends it when givenlimitsResetAt.ChatView.tsxrenders 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.tsgains areadThreadProviderSnapshotreader for the header 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:
After tapping either, the thread parks with the existing banner and wake path:
No motion or timing changes, so no video.
Verification
vp test runonusageLimits.test.ts,threadSnoozed.test.ts,Sidebar.snooze.test.ts,threadActionMenu.logic.test.ts,threadListV2.test.ts— 121 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 mobilesnooze:limits-resetselection resolves.packages/client-runtime,apps/web,apps/mobile; lint and format clean on the touched files.Checklist
Earlier revisions
Until b6ca359 this PR carried its own reset time from the adapters through a typed
limitResetsAt, athread.session.rate-limit-setcommand, 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 'snooze until provider limits reset' option on web and mobile
exhaustedUntilin usageLimits.ts to find the latest future reset among exhausted account-wide provider windows, ignoring model-scoped limitsusageLimitSnoozePresetand extendsresolveSnoozePresetsin threadSettled.ts to prepend a preset that wakes one minute after the reset, formatted as local time or weekday+timesnoozeWakeDescriptionin Sidebar.snooze.ts to use local calendar-day boundaries instead of fixed 24-hour buckets, correcting day classification across daylight-saving transitionssnoozeWakeDescriptionnow rounds day-difference between local start-of-day values rather than flooring elapsed time; wake labels near DST transitions may shift by one day compared to the old calculationMacroscope summarized 860bf64.
Summary by CodeRabbit
New Features
Documentation