Snooze a thread until provider limits reset

[vitalyiegorov]

When Claude or Codex hits a usage limit mid-turn, the thread just stops and leaves one muted line behind. It still sits in the inbox looking like live work, and the reset time is now yours to remember.

Today: a stalled thread and a timestamp you have to hold in your head.

Offer a one-tap snooze next to that line, prefilled with the reset time the provider already sends us. The thread drops into the snoozed shelf and comes back exactly when the limits do (one minute past reset, so clock skew can't wake it early). Nothing auto-resumes — snooze stays visibility-only, same as today. Claude and Codex only; Cursor, Grok and OpenCode don't report a usable reset time, so no offer there.

Snooze already accepts an arbitrary wake time. This just fills it in.

Proposed: the same notice, with a quiet inline action.

Sketch:

• packages/contracts/src/providerRuntime.ts:707 — account.rate-limits.updated carries rateLimits: Schema.Unknown and has no consumers. Give it a typed shape with resetsAt; both adapters already forward it (ClaudeAdapter.ts:3548, CodexAdapter.ts:1416), and both SDKs type a reset epoch — optional on Claude's side, so the offer only renders when it's present.
• Surface resetsAt on thread state in the read model.
• Render the offer near the limit notice, calling the existing snoozeThread(threadRef, resetsAt + 60s) (apps/web/src/hooks/useThreadActions.ts:657) behind canSnooze. No scheduler needed; wake is derived from snoozedUntil.

A typed resetsAt is also exactly what an auto-resume scheduler like #8577's would need to read, so none of this is throwaway if that lands later.

Prior art: #8401, #8577 and #6796 all propose auto-resume, and #6513 is the same complaint in bug-report form — four independent asks for this pain. Auto-resume is a bigger design question this doesn't need to resolve; this is the smallest piece that's useful on its own and doesn't preempt it.

Happy to send it as a small PR (contract, adapter typing, one web component) if you want it.

[vitalyiegorov]

Implementation is up as a small PR: #9012 — typed limitResetsAt on the existing rate-limit event, a narrow session command, and the composer notice with the one-tap snooze. Real before/after screenshots in the PR.

[vitalyiegorov]

Update on #9012: since #9507 landed, every client already receives each provider's usage windows with reset times on the provider snapshot, so the PR is now client-only (no contract, server, or migration change) and covers both places you reach for a snooze:

• the composer notice with the one-tap Snooze until HH:MM, and
• Until limits reset as the first row of every thread snooze menu (sidebar row popover, row menu, chat-header menu, mobile row menu) while the limit is in force.

Both are built from one shared preset, so they can never disagree on the wake time.

Sidebar snooze menu, before	after

[juliusmarminge]

Thanks for proposing the smaller snooze-until-reset step. The orchestrator V2 work has now merged in #2829.

V2 now offers snooze/resume at the provider's reported reset time for limited threads, with optional automatic resumption. This covers the reset-aware workflow described here.

Closing this as delivered. If a specific part is still missing in a build containing V2, please open a focused follow-up with the provider/version and the behavior you are seeing.