feat: resume threads after usage limits reset

[Kron00]

I don't expect this to get merged. It's a working idea you guys can take further if any of it is useful.

Problem

When a provider usage limit stops a long-running thread, users have to remember to reopen it after their subscription resets. Threads that were already doing useful work can sit unfinished even while T3 is still running on their computer.

Fix

• classify native usage-limit errors from Codex, Claude, Cursor, Grok, and OpenCode
• add a "Resume when available" action with a visible scheduled state and cancellation
• persist the schedule so server restarts and reconnects do not lose it
• resume the same thread with a hidden continuation prompt when the reset time arrives
• use provider reset timestamps when available, then back off retries when the provider does not supply one
• cancel safely on settlement, deletion, archival, or newer work, and revalidate timers before starting a provider turn

This PR is desktop/web only. Mobile is unchanged.

Verification

• 704 focused tests across 25 files after updating from the current base branch
• focused Grok adapter and xAI extension rate-limit tests
• vp run --filter @t3tools/contracts typecheck
• vp run --filter @t3tools/client-runtime typecheck
• vp run --filter t3 typecheck
• vp run --filter @t3tools/web typecheck
• targeted lint for changed provider adapters
• git diff --check
• tested the real Codex, Claude, Cursor, Grok, and OpenCode harness error formats against controlled local rate-limit responders
• recorded a desktop end-to-end pass where an existing Grok thread scheduled, fired, and resumed automatically
• repeated the live Grok pass after review fixes and observed the next paced retry when Grok remained limited

Visual evidence

Limit reached	Resume scheduled

Desktop end-to-end recording

Generated with GPT-5.6 Sol in T3 Code through the Codex harness.

---

Note

Medium Risk
Touches core orchestration, provider turn dispatch, and new durable projection fields; incorrect timer or cancel logic could retry turns at the wrong time or leave stale resume state after lifecycle changes.

Overview
Adds durable automatic resume when provider turns stop on usage limits: new orchestration commands/events (schedule, attempt, retry, cancel), projection columns (usage_limit_resume_json, session last_error_class/retry_at), and the threadUsageLimitResume server capability.

ProviderCommandReactor schedules timers from resume events, restores them on startup (with repair for in-flight attempts), retries failed dispatches with backoff, and on attempt fires a hidden Continue from where you left off. turn without a new user message. Failures re-classify usage limits, pace retries via nextUsageLimitRetryAt, and cancel when work is superseded or the thread is settled/archived/deleted.

Decider enforces invariants (usage-limit session required, future resumeAt) and emits companion cancel/interrupt events on settle, delete, archive, manual turn, and interrupt. ProviderRuntimeIngestion persists typed usage_limit/retryAt on runtime errors, reschedules or cancels in-flight resume, and avoids carrying stale error metadata on unrelated session errors.

Snapshot queries and migration 044 expose resume state to clients; tests cover reactor recovery, OpenCode trailing-error ordering, and decider/projector lifecycles. Mock ACP agent gains configurable prompt failure message.

^{Reviewed by Cursor Bugbot for commit b6a9d16. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add automatic thread resume after usage limits reset

• Introduces contracts for OrchestrationRuntimeErrorClass, ThreadUsageLimitResume, and related commands/events in orchestration.ts.
• Server orchestrator classifies usage-limit errors from providers, tracks lastErrorClass and retryAt, and schedules/cancels durable timers to automatically resume threads.
• Web UI and client runtime track resume state and expose user actions to schedule or cancel auto-resume.
• Risk: Database migration 044_UsageLimitResume in 044_UsageLimitResume.ts adds new columns to projection_threads and projection_thread_sessions.

^{Macroscope summarized b6a9d16.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 658c7c3a-f1ed-4e41-b96e-9aa91ef5b044

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

---

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

[macroscopeapp]

Reviewed the web UI changes (ChatView.tsx, chat/ThreadErrorBanner.tsx). The banner itself composes the shared Alert/Button primitives correctly (size="xs" + variant="outline" matches the parked-thread banner action). Three findings on the new usage-limit resume surface in ChatView.tsx.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding on the usage-limit banner: the dismiss affordance is rendered but cannot hide the banner for a usage-limit error with no pending resume.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One minor copy inconsistency in the new banner action; everything else (primitive reuse, size="xs"/variant="outline" in AlertAction, timestamp formatting via snoozeWakeDescription, thread-scoped environment routing for the new commands) matches existing patterns.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding in the reactor's startup reconciliation of pending usage-limit resumes. Details inline.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new usage-limit resume services against the Effect service conventions. One finding: the shared usage-limit dispatch retry is unbounded and does not isolate persistent failures.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new usage-limit resume banner wiring in ChatView.tsx. The earlier notes on the pending label, the dismissal mask, and the timestamp format look resolved.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a default-enabled capability and a broad server/client workflow that persists usage-limit state, schedules retries across restarts, and automatically starts provider turns. Its cross-cutting orchestration, provider, persistence, and lifecycle side effects require human review.

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

[macroscopeapp]

Reviewed the changed web UI (ChatView.tsx, chat/ThreadErrorBanner.tsx, chat/usageLimitResumePresentation.ts) against the shared component system and the repo's environment/capability conventions.

The banner work itself now lines up with the primitives: ThreadErrorBanner keeps Alert/AlertAction ownership, the new action uses Button size="xs" variant="outline" (same geometry as the existing icon-xs dismiss control, so the h-lh / min-h-7 sm:min-h-6 first-line alignment contract still holds), the composer status banner matches its peer ComposerBannerStackItems, and the scheduled time is formatted through snoozeWakeDescription(..., timestampFormat) rather than a raw Intl call.

One finding: the new environment-scoped resume actions are offered without a server capability gate, unlike every other server-backed thread action in this file. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high 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 df9fdff. Configure here.}

[rix1337]

Not commenting on the implementation details here, but I’d consider this a high-priority feature from a product perspective.

Automatic resume after usage limits reset is becoming an expected capability in long-running coding agents. Claude Code has recently added similar behavior, and other agent/harness tools are moving in the same direction.

For unattended or long-running work, requiring the user to remember to manually resume a task hours later is a significant reliability gap.

[Kron00]

I don't expect this to get merged. It's a working idea you guys can take further if any of it is useful.

Problem

When a provider usage limit stops a long-running thread, users have to remember to reopen it after their subscription resets. Threads that were already doing useful work can sit unfinished even while T3 is still running on their computer.

Fix

• classify native usage-limit errors from Codex, Claude, Cursor, Grok, and OpenCode
• add a "Resume when available" action with a visible scheduled state and cancellation
• persist the schedule so server restarts and reconnects do not lose it
• resume the same thread with a hidden continuation prompt when the reset time arrives
• use provider reset timestamps when available, then back off retries when the provider does not supply one
• cancel safely on settlement, deletion, archival, or newer work, and revalidate timers before starting a provider turn

This PR is desktop/web only. Mobile is unchanged.

Verification

• 704 focused tests across 25 files after updating from the current base branch
• focused Grok adapter and xAI extension rate-limit tests
• vp run --filter @t3tools/contracts typecheck
• vp run --filter @t3tools/client-runtime typecheck
• vp run --filter t3 typecheck
• vp run --filter @t3tools/web typecheck
• targeted lint for changed provider adapters
• git diff --check
• tested the real Codex, Claude, Cursor, Grok, and OpenCode harness error formats against controlled local rate-limit responders
• recorded a desktop end-to-end pass where an existing Grok thread scheduled, fired, and resumed automatically
• repeated the live Grok pass after review fixes and observed the next paced retry when Grok remained limited

Visual evidence

Limit reached	Resume scheduled

Desktop end-to-end recording

Generated with GPT-5.6 Sol in T3 Code through the Codex harness.

---

Note

Medium Risk
Touches core orchestration, provider turn dispatch, and new durable projection fields; incorrect timer or cancel logic could retry turns at the wrong time or leave stale resume state after lifecycle changes.

Overview
Adds durable automatic resume when provider turns stop on usage limits: new orchestration commands/events (schedule, attempt, retry, cancel), projection columns (usage_limit_resume_json, session last_error_class/retry_at), and the threadUsageLimitResume server capability.

ProviderCommandReactor schedules timers from resume events, restores them on startup (with repair for in-flight attempts), retries failed dispatches with backoff, and on attempt fires a hidden Continue from where you left off. turn without a new user message. Failures re-classify usage limits, pace retries via nextUsageLimitRetryAt, and cancel when work is superseded or the thread is settled/archived/deleted.

Decider enforces invariants (usage-limit session required, future resumeAt) and emits companion cancel/interrupt events on settle, delete, archive, manual turn, and interrupt. ProviderRuntimeIngestion persists typed usage_limit/retryAt on runtime errors, reschedules or cancels in-flight resume, and avoids carrying stale error metadata on unrelated session errors.

Snapshot queries and migration 044 expose resume state to clients; tests cover reactor recovery, OpenCode trailing-error ordering, and decider/projector lifecycles. Mock ACP agent gains configurable prompt failure message.

^{Reviewed by Cursor Bugbot for commit b6a9d16. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add automatic thread resume after usage limits reset

• Introduces contracts for OrchestrationRuntimeErrorClass, ThreadUsageLimitResume, and related commands/events in orchestration.ts.
• Server orchestrator classifies usage-limit errors from providers, tracks lastErrorClass and retryAt, and schedules/cancels durable timers to automatically resume threads.
• Web UI and client runtime track resume state and expose user actions to schedule or cancel auto-resume.
• Risk: Database migration 044_UsageLimitResume in 044_UsageLimitResume.ts adds new columns to projection_threads and projection_thread_sessions.

^{Macroscope summarized b6a9d16.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 658c7c3a-f1ed-4e41-b96e-9aa91ef5b044

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

---

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

[macroscopeapp]

Reviewed the web UI changes (ChatView.tsx, chat/ThreadErrorBanner.tsx). The banner itself composes the shared Alert/Button primitives correctly (size="xs" + variant="outline" matches the parked-thread banner action). Three findings on the new usage-limit resume surface in ChatView.tsx.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding on the usage-limit banner: the dismiss affordance is rendered but cannot hide the banner for a usage-limit error with no pending resume.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One minor copy inconsistency in the new banner action; everything else (primitive reuse, size="xs"/variant="outline" in AlertAction, timestamp formatting via snoozeWakeDescription, thread-scoped environment routing for the new commands) matches existing patterns.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding in the reactor's startup reconciliation of pending usage-limit resumes. Details inline.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new usage-limit resume services against the Effect service conventions. One finding: the shared usage-limit dispatch retry is unbounded and does not isolate persistent failures.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new usage-limit resume banner wiring in ChatView.tsx. The earlier notes on the pending label, the dismissal mask, and the timestamp format look resolved.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a default-enabled capability and a broad server/client workflow that persists usage-limit state, schedules retries across restarts, and automatically starts provider turns. Its cross-cutting orchestration, provider, persistence, and lifecycle side effects require human review.

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

[macroscopeapp]

Reviewed the changed web UI (ChatView.tsx, chat/ThreadErrorBanner.tsx, chat/usageLimitResumePresentation.ts) against the shared component system and the repo's environment/capability conventions.

The banner work itself now lines up with the primitives: ThreadErrorBanner keeps Alert/AlertAction ownership, the new action uses Button size="xs" variant="outline" (same geometry as the existing icon-xs dismiss control, so the h-lh / min-h-7 sm:min-h-6 first-line alignment contract still holds), the composer status banner matches its peer ComposerBannerStackItems, and the scheduled time is formatted through snoozeWakeDescription(..., timestampFormat) rather than a raw Intl call.

One finding: the new environment-scoped resume actions are offered without a server capability gate, unlike every other server-backed thread action in this file. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high 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 df9fdff. Configure here.}

[rix1337]

Not commenting on the implementation details here, but I’d consider this a high-priority feature from a product perspective.

Automatic resume after usage limits reset is becoming an expected capability in long-running coding agents. Claude Code has recently added similar behavior, and other agent/harness tools are moving in the same direction.

For unattended or long-running work, requiring the user to remember to manually resume a task hours later is a significant reliability gap.

[Kron00]

I don't expect this to get merged. It's a working idea you guys can take further if any of it is useful.

Problem

When a provider usage limit stops a long-running thread, users have to remember to reopen it after their subscription resets. Threads that were already doing useful work can sit unfinished even while T3 is still running on their computer.

Fix

• classify native usage-limit errors from Codex, Claude, Cursor, Grok, and OpenCode
• add a "Resume when available" action with a visible scheduled state and cancellation
• persist the schedule so server restarts and reconnects do not lose it
• resume the same thread with a hidden continuation prompt when the reset time arrives
• use provider reset timestamps when available, then back off retries when the provider does not supply one
• cancel safely on settlement, deletion, archival, or newer work, and revalidate timers before starting a provider turn

This PR is desktop/web only. Mobile is unchanged.

Verification

• 704 focused tests across 25 files after updating from the current base branch
• focused Grok adapter and xAI extension rate-limit tests
• vp run --filter @t3tools/contracts typecheck
• vp run --filter @t3tools/client-runtime typecheck
• vp run --filter t3 typecheck
• vp run --filter @t3tools/web typecheck
• targeted lint for changed provider adapters
• git diff --check
• tested the real Codex, Claude, Cursor, Grok, and OpenCode harness error formats against controlled local rate-limit responders
• recorded a desktop end-to-end pass where an existing Grok thread scheduled, fired, and resumed automatically
• repeated the live Grok pass after review fixes and observed the next paced retry when Grok remained limited

Visual evidence

Limit reached	Resume scheduled

Desktop end-to-end recording

Generated with GPT-5.6 Sol in T3 Code through the Codex harness.

---

Note

Medium Risk
Touches core orchestration, provider turn dispatch, and new durable projection fields; incorrect timer or cancel logic could retry turns at the wrong time or leave stale resume state after lifecycle changes.

Overview
Adds durable automatic resume when provider turns stop on usage limits: new orchestration commands/events (schedule, attempt, retry, cancel), projection columns (usage_limit_resume_json, session last_error_class/retry_at), and the threadUsageLimitResume server capability.

ProviderCommandReactor schedules timers from resume events, restores them on startup (with repair for in-flight attempts), retries failed dispatches with backoff, and on attempt fires a hidden Continue from where you left off. turn without a new user message. Failures re-classify usage limits, pace retries via nextUsageLimitRetryAt, and cancel when work is superseded or the thread is settled/archived/deleted.

Decider enforces invariants (usage-limit session required, future resumeAt) and emits companion cancel/interrupt events on settle, delete, archive, manual turn, and interrupt. ProviderRuntimeIngestion persists typed usage_limit/retryAt on runtime errors, reschedules or cancels in-flight resume, and avoids carrying stale error metadata on unrelated session errors.

Snapshot queries and migration 044 expose resume state to clients; tests cover reactor recovery, OpenCode trailing-error ordering, and decider/projector lifecycles. Mock ACP agent gains configurable prompt failure message.

^{Reviewed by Cursor Bugbot for commit b6a9d16. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add automatic thread resume after usage limits reset

• Introduces contracts for OrchestrationRuntimeErrorClass, ThreadUsageLimitResume, and related commands/events in orchestration.ts.
• Server orchestrator classifies usage-limit errors from providers, tracks lastErrorClass and retryAt, and schedules/cancels durable timers to automatically resume threads.
• Web UI and client runtime track resume state and expose user actions to schedule or cancel auto-resume.
• Risk: Database migration 044_UsageLimitResume in 044_UsageLimitResume.ts adds new columns to projection_threads and projection_thread_sessions.

^{Macroscope summarized b6a9d16.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 658c7c3a-f1ed-4e41-b96e-9aa91ef5b044

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

---

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

[macroscopeapp]

Reviewed the web UI changes (ChatView.tsx, chat/ThreadErrorBanner.tsx). The banner itself composes the shared Alert/Button primitives correctly (size="xs" + variant="outline" matches the parked-thread banner action). Three findings on the new usage-limit resume surface in ChatView.tsx.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding on the usage-limit banner: the dismiss affordance is rendered but cannot hide the banner for a usage-limit error with no pending resume.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One minor copy inconsistency in the new banner action; everything else (primitive reuse, size="xs"/variant="outline" in AlertAction, timestamp formatting via snoozeWakeDescription, thread-scoped environment routing for the new commands) matches existing patterns.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding in the reactor's startup reconciliation of pending usage-limit resumes. Details inline.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new usage-limit resume services against the Effect service conventions. One finding: the shared usage-limit dispatch retry is unbounded and does not isolate persistent failures.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new usage-limit resume banner wiring in ChatView.tsx. The earlier notes on the pending label, the dismissal mask, and the timestamp format look resolved.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a default-enabled capability and a broad server/client workflow that persists usage-limit state, schedules retries across restarts, and automatically starts provider turns. Its cross-cutting orchestration, provider, persistence, and lifecycle side effects require human review.

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

[macroscopeapp]

Reviewed the changed web UI (ChatView.tsx, chat/ThreadErrorBanner.tsx, chat/usageLimitResumePresentation.ts) against the shared component system and the repo's environment/capability conventions.

The banner work itself now lines up with the primitives: ThreadErrorBanner keeps Alert/AlertAction ownership, the new action uses Button size="xs" variant="outline" (same geometry as the existing icon-xs dismiss control, so the h-lh / min-h-7 sm:min-h-6 first-line alignment contract still holds), the composer status banner matches its peer ComposerBannerStackItems, and the scheduled time is formatted through snoozeWakeDescription(..., timestampFormat) rather than a raw Intl call.

One finding: the new environment-scoped resume actions are offered without a server capability gate, unlike every other server-backed thread action in this file. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high 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 df9fdff. Configure here.}

[rix1337]

Not commenting on the implementation details here, but I’d consider this a high-priority feature from a product perspective.

Automatic resume after usage limits reset is becoming an expected capability in long-running coding agents. Claude Code has recently added similar behavior, and other agent/harness tools are moving in the same direction.

For unattended or long-running work, requiring the user to remember to manually resume a task hours later is a significant reliability gap.

[Kron00]

I don't expect this to get merged. It's a working idea you guys can take further if any of it is useful.

Problem

When a provider usage limit stops a long-running thread, users have to remember to reopen it after their subscription resets. Threads that were already doing useful work can sit unfinished even while T3 is still running on their computer.

Fix

• classify native usage-limit errors from Codex, Claude, Cursor, Grok, and OpenCode
• add a "Resume when available" action with a visible scheduled state and cancellation
• persist the schedule so server restarts and reconnects do not lose it
• resume the same thread with a hidden continuation prompt when the reset time arrives
• use provider reset timestamps when available, then back off retries when the provider does not supply one
• cancel safely on settlement, deletion, archival, or newer work, and revalidate timers before starting a provider turn

This PR is desktop/web only. Mobile is unchanged.

Verification

• 704 focused tests across 25 files after updating from the current base branch
• focused Grok adapter and xAI extension rate-limit tests
• vp run --filter @t3tools/contracts typecheck
• vp run --filter @t3tools/client-runtime typecheck
• vp run --filter t3 typecheck
• vp run --filter @t3tools/web typecheck
• targeted lint for changed provider adapters
• git diff --check
• tested the real Codex, Claude, Cursor, Grok, and OpenCode harness error formats against controlled local rate-limit responders
• recorded a desktop end-to-end pass where an existing Grok thread scheduled, fired, and resumed automatically
• repeated the live Grok pass after review fixes and observed the next paced retry when Grok remained limited

Visual evidence

Limit reached	Resume scheduled

Desktop end-to-end recording

Generated with GPT-5.6 Sol in T3 Code through the Codex harness.

---

Note

Medium Risk
Touches core orchestration, provider turn dispatch, and new durable projection fields; incorrect timer or cancel logic could retry turns at the wrong time or leave stale resume state after lifecycle changes.

Overview
Adds durable automatic resume when provider turns stop on usage limits: new orchestration commands/events (schedule, attempt, retry, cancel), projection columns (usage_limit_resume_json, session last_error_class/retry_at), and the threadUsageLimitResume server capability.

ProviderCommandReactor schedules timers from resume events, restores them on startup (with repair for in-flight attempts), retries failed dispatches with backoff, and on attempt fires a hidden Continue from where you left off. turn without a new user message. Failures re-classify usage limits, pace retries via nextUsageLimitRetryAt, and cancel when work is superseded or the thread is settled/archived/deleted.

Decider enforces invariants (usage-limit session required, future resumeAt) and emits companion cancel/interrupt events on settle, delete, archive, manual turn, and interrupt. ProviderRuntimeIngestion persists typed usage_limit/retryAt on runtime errors, reschedules or cancels in-flight resume, and avoids carrying stale error metadata on unrelated session errors.

Snapshot queries and migration 044 expose resume state to clients; tests cover reactor recovery, OpenCode trailing-error ordering, and decider/projector lifecycles. Mock ACP agent gains configurable prompt failure message.

^{Reviewed by Cursor Bugbot for commit b6a9d16. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add automatic thread resume after usage limits reset

• Introduces contracts for OrchestrationRuntimeErrorClass, ThreadUsageLimitResume, and related commands/events in orchestration.ts.
• Server orchestrator classifies usage-limit errors from providers, tracks lastErrorClass and retryAt, and schedules/cancels durable timers to automatically resume threads.
• Web UI and client runtime track resume state and expose user actions to schedule or cancel auto-resume.
• Risk: Database migration 044_UsageLimitResume in 044_UsageLimitResume.ts adds new columns to projection_threads and projection_thread_sessions.

^{Macroscope summarized b6a9d16.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 658c7c3a-f1ed-4e41-b96e-9aa91ef5b044

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

---

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

[macroscopeapp]

Reviewed the web UI changes (ChatView.tsx, chat/ThreadErrorBanner.tsx). The banner itself composes the shared Alert/Button primitives correctly (size="xs" + variant="outline" matches the parked-thread banner action). Three findings on the new usage-limit resume surface in ChatView.tsx.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding on the usage-limit banner: the dismiss affordance is rendered but cannot hide the banner for a usage-limit error with no pending resume.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One minor copy inconsistency in the new banner action; everything else (primitive reuse, size="xs"/variant="outline" in AlertAction, timestamp formatting via snoozeWakeDescription, thread-scoped environment routing for the new commands) matches existing patterns.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding in the reactor's startup reconciliation of pending usage-limit resumes. Details inline.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new usage-limit resume services against the Effect service conventions. One finding: the shared usage-limit dispatch retry is unbounded and does not isolate persistent failures.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new usage-limit resume banner wiring in ChatView.tsx. The earlier notes on the pending label, the dismissal mask, and the timestamp format look resolved.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a default-enabled capability and a broad server/client workflow that persists usage-limit state, schedules retries across restarts, and automatically starts provider turns. Its cross-cutting orchestration, provider, persistence, and lifecycle side effects require human review.

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

[macroscopeapp]

Reviewed the changed web UI (ChatView.tsx, chat/ThreadErrorBanner.tsx, chat/usageLimitResumePresentation.ts) against the shared component system and the repo's environment/capability conventions.

The banner work itself now lines up with the primitives: ThreadErrorBanner keeps Alert/AlertAction ownership, the new action uses Button size="xs" variant="outline" (same geometry as the existing icon-xs dismiss control, so the h-lh / min-h-7 sm:min-h-6 first-line alignment contract still holds), the composer status banner matches its peer ComposerBannerStackItems, and the scheduled time is formatted through snoozeWakeDescription(..., timestampFormat) rather than a raw Intl call.

One finding: the new environment-scoped resume actions are offered without a server capability gate, unlike every other server-backed thread action in this file. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high 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 df9fdff. Configure here.}

[rix1337]

Not commenting on the implementation details here, but I’d consider this a high-priority feature from a product perspective.

Automatic resume after usage limits reset is becoming an expected capability in long-running coding agents. Claude Code has recently added similar behavior, and other agent/harness tools are moving in the same direction.

For unattended or long-running work, requiring the user to remember to manually resume a task hours later is a significant reliability gap.

[Kron00]

I don't expect this to get merged. It's a working idea you guys can take further if any of it is useful.

Problem

When a provider usage limit stops a long-running thread, users have to remember to reopen it after their subscription resets. Threads that were already doing useful work can sit unfinished even while T3 is still running on their computer.

Fix

• classify native usage-limit errors from Codex, Claude, Cursor, Grok, and OpenCode
• add a "Resume when available" action with a visible scheduled state and cancellation
• persist the schedule so server restarts and reconnects do not lose it
• resume the same thread with a hidden continuation prompt when the reset time arrives
• use provider reset timestamps when available, then back off retries when the provider does not supply one
• cancel safely on settlement, deletion, archival, or newer work, and revalidate timers before starting a provider turn

This PR is desktop/web only. Mobile is unchanged.

Verification

• 704 focused tests across 25 files after updating from the current base branch
• focused Grok adapter and xAI extension rate-limit tests
• vp run --filter @t3tools/contracts typecheck
• vp run --filter @t3tools/client-runtime typecheck
• vp run --filter t3 typecheck
• vp run --filter @t3tools/web typecheck
• targeted lint for changed provider adapters
• git diff --check
• tested the real Codex, Claude, Cursor, Grok, and OpenCode harness error formats against controlled local rate-limit responders
• recorded a desktop end-to-end pass where an existing Grok thread scheduled, fired, and resumed automatically
• repeated the live Grok pass after review fixes and observed the next paced retry when Grok remained limited

Visual evidence

Limit reached	Resume scheduled

Desktop end-to-end recording

Generated with GPT-5.6 Sol in T3 Code through the Codex harness.

---

Note

Medium Risk
Touches core orchestration, provider turn dispatch, and new durable projection fields; incorrect timer or cancel logic could retry turns at the wrong time or leave stale resume state after lifecycle changes.

Overview
Adds durable automatic resume when provider turns stop on usage limits: new orchestration commands/events (schedule, attempt, retry, cancel), projection columns (usage_limit_resume_json, session last_error_class/retry_at), and the threadUsageLimitResume server capability.

ProviderCommandReactor schedules timers from resume events, restores them on startup (with repair for in-flight attempts), retries failed dispatches with backoff, and on attempt fires a hidden Continue from where you left off. turn without a new user message. Failures re-classify usage limits, pace retries via nextUsageLimitRetryAt, and cancel when work is superseded or the thread is settled/archived/deleted.

Decider enforces invariants (usage-limit session required, future resumeAt) and emits companion cancel/interrupt events on settle, delete, archive, manual turn, and interrupt. ProviderRuntimeIngestion persists typed usage_limit/retryAt on runtime errors, reschedules or cancels in-flight resume, and avoids carrying stale error metadata on unrelated session errors.

Snapshot queries and migration 044 expose resume state to clients; tests cover reactor recovery, OpenCode trailing-error ordering, and decider/projector lifecycles. Mock ACP agent gains configurable prompt failure message.

^{Reviewed by Cursor Bugbot for commit b6a9d16. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add automatic thread resume after usage limits reset

• Introduces contracts for OrchestrationRuntimeErrorClass, ThreadUsageLimitResume, and related commands/events in orchestration.ts.
• Server orchestrator classifies usage-limit errors from providers, tracks lastErrorClass and retryAt, and schedules/cancels durable timers to automatically resume threads.
• Web UI and client runtime track resume state and expose user actions to schedule or cancel auto-resume.
• Risk: Database migration 044_UsageLimitResume in 044_UsageLimitResume.ts adds new columns to projection_threads and projection_thread_sessions.

^{Macroscope summarized b6a9d16.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 658c7c3a-f1ed-4e41-b96e-9aa91ef5b044

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

---

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

[macroscopeapp]

Reviewed the web UI changes (ChatView.tsx, chat/ThreadErrorBanner.tsx). The banner itself composes the shared Alert/Button primitives correctly (size="xs" + variant="outline" matches the parked-thread banner action). Three findings on the new usage-limit resume surface in ChatView.tsx.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding on the usage-limit banner: the dismiss affordance is rendered but cannot hide the banner for a usage-limit error with no pending resume.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One minor copy inconsistency in the new banner action; everything else (primitive reuse, size="xs"/variant="outline" in AlertAction, timestamp formatting via snoozeWakeDescription, thread-scoped environment routing for the new commands) matches existing patterns.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding in the reactor's startup reconciliation of pending usage-limit resumes. Details inline.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new usage-limit resume services against the Effect service conventions. One finding: the shared usage-limit dispatch retry is unbounded and does not isolate persistent failures.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new usage-limit resume banner wiring in ChatView.tsx. The earlier notes on the pending label, the dismissal mask, and the timestamp format look resolved.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a default-enabled capability and a broad server/client workflow that persists usage-limit state, schedules retries across restarts, and automatically starts provider turns. Its cross-cutting orchestration, provider, persistence, and lifecycle side effects require human review.

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

[macroscopeapp]

Reviewed the changed web UI (ChatView.tsx, chat/ThreadErrorBanner.tsx, chat/usageLimitResumePresentation.ts) against the shared component system and the repo's environment/capability conventions.

The banner work itself now lines up with the primitives: ThreadErrorBanner keeps Alert/AlertAction ownership, the new action uses Button size="xs" variant="outline" (same geometry as the existing icon-xs dismiss control, so the h-lh / min-h-7 sm:min-h-6 first-line alignment contract still holds), the composer status banner matches its peer ComposerBannerStackItems, and the scheduled time is formatted through snoozeWakeDescription(..., timestampFormat) rather than a raw Intl call.

One finding: the new environment-scoped resume actions are offered without a server capability gate, unlike every other server-backed thread action in this file. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high 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 df9fdff. Configure here.}

[rix1337]

Not commenting on the implementation details here, but I’d consider this a high-priority feature from a product perspective.

Automatic resume after usage limits reset is becoming an expected capability in long-running coding agents. Claude Code has recently added similar behavior, and other agent/harness tools are moving in the same direction.

For unattended or long-running work, requiring the user to remember to manually resume a task hours later is a significant reliability gap.

[Kron00]

I don't expect this to get merged. It's a working idea you guys can take further if any of it is useful.

Problem

When a provider usage limit stops a long-running thread, users have to remember to reopen it after their subscription resets. Threads that were already doing useful work can sit unfinished even while T3 is still running on their computer.

Fix

• classify native usage-limit errors from Codex, Claude, Cursor, Grok, and OpenCode
• add a "Resume when available" action with a visible scheduled state and cancellation
• persist the schedule so server restarts and reconnects do not lose it
• resume the same thread with a hidden continuation prompt when the reset time arrives
• use provider reset timestamps when available, then back off retries when the provider does not supply one
• cancel safely on settlement, deletion, archival, or newer work, and revalidate timers before starting a provider turn

This PR is desktop/web only. Mobile is unchanged.

Verification

• 704 focused tests across 25 files after updating from the current base branch
• focused Grok adapter and xAI extension rate-limit tests
• vp run --filter @t3tools/contracts typecheck
• vp run --filter @t3tools/client-runtime typecheck
• vp run --filter t3 typecheck
• vp run --filter @t3tools/web typecheck
• targeted lint for changed provider adapters
• git diff --check
• tested the real Codex, Claude, Cursor, Grok, and OpenCode harness error formats against controlled local rate-limit responders
• recorded a desktop end-to-end pass where an existing Grok thread scheduled, fired, and resumed automatically
• repeated the live Grok pass after review fixes and observed the next paced retry when Grok remained limited

Visual evidence

Limit reached	Resume scheduled

Desktop end-to-end recording

Generated with GPT-5.6 Sol in T3 Code through the Codex harness.

---

Note

Medium Risk
Touches core orchestration, provider turn dispatch, and new durable projection fields; incorrect timer or cancel logic could retry turns at the wrong time or leave stale resume state after lifecycle changes.

Overview
Adds durable automatic resume when provider turns stop on usage limits: new orchestration commands/events (schedule, attempt, retry, cancel), projection columns (usage_limit_resume_json, session last_error_class/retry_at), and the threadUsageLimitResume server capability.

ProviderCommandReactor schedules timers from resume events, restores them on startup (with repair for in-flight attempts), retries failed dispatches with backoff, and on attempt fires a hidden Continue from where you left off. turn without a new user message. Failures re-classify usage limits, pace retries via nextUsageLimitRetryAt, and cancel when work is superseded or the thread is settled/archived/deleted.

Decider enforces invariants (usage-limit session required, future resumeAt) and emits companion cancel/interrupt events on settle, delete, archive, manual turn, and interrupt. ProviderRuntimeIngestion persists typed usage_limit/retryAt on runtime errors, reschedules or cancels in-flight resume, and avoids carrying stale error metadata on unrelated session errors.

Snapshot queries and migration 044 expose resume state to clients; tests cover reactor recovery, OpenCode trailing-error ordering, and decider/projector lifecycles. Mock ACP agent gains configurable prompt failure message.

^{Reviewed by Cursor Bugbot for commit b6a9d16. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add automatic thread resume after usage limits reset

• Introduces contracts for OrchestrationRuntimeErrorClass, ThreadUsageLimitResume, and related commands/events in orchestration.ts.
• Server orchestrator classifies usage-limit errors from providers, tracks lastErrorClass and retryAt, and schedules/cancels durable timers to automatically resume threads.
• Web UI and client runtime track resume state and expose user actions to schedule or cancel auto-resume.
• Risk: Database migration 044_UsageLimitResume in 044_UsageLimitResume.ts adds new columns to projection_threads and projection_thread_sessions.

^{Macroscope summarized b6a9d16.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 658c7c3a-f1ed-4e41-b96e-9aa91ef5b044

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

---

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

[macroscopeapp]

Reviewed the web UI changes (ChatView.tsx, chat/ThreadErrorBanner.tsx). The banner itself composes the shared Alert/Button primitives correctly (size="xs" + variant="outline" matches the parked-thread banner action). Three findings on the new usage-limit resume surface in ChatView.tsx.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding on the usage-limit banner: the dismiss affordance is rendered but cannot hide the banner for a usage-limit error with no pending resume.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One minor copy inconsistency in the new banner action; everything else (primitive reuse, size="xs"/variant="outline" in AlertAction, timestamp formatting via snoozeWakeDescription, thread-scoped environment routing for the new commands) matches existing patterns.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding in the reactor's startup reconciliation of pending usage-limit resumes. Details inline.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new usage-limit resume services against the Effect service conventions. One finding: the shared usage-limit dispatch retry is unbounded and does not isolate persistent failures.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new usage-limit resume banner wiring in ChatView.tsx. The earlier notes on the pending label, the dismissal mask, and the timestamp format look resolved.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a default-enabled capability and a broad server/client workflow that persists usage-limit state, schedules retries across restarts, and automatically starts provider turns. Its cross-cutting orchestration, provider, persistence, and lifecycle side effects require human review.

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

[macroscopeapp]

Reviewed the changed web UI (ChatView.tsx, chat/ThreadErrorBanner.tsx, chat/usageLimitResumePresentation.ts) against the shared component system and the repo's environment/capability conventions.

The banner work itself now lines up with the primitives: ThreadErrorBanner keeps Alert/AlertAction ownership, the new action uses Button size="xs" variant="outline" (same geometry as the existing icon-xs dismiss control, so the h-lh / min-h-7 sm:min-h-6 first-line alignment contract still holds), the composer status banner matches its peer ComposerBannerStackItems, and the scheduled time is formatted through snoozeWakeDescription(..., timestampFormat) rather than a raw Intl call.

One finding: the new environment-scoped resume actions are offered without a server capability gate, unlike every other server-backed thread action in this file. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high 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 df9fdff. Configure here.}

[rix1337]

Not commenting on the implementation details here, but I’d consider this a high-priority feature from a product perspective.

Automatic resume after usage limits reset is becoming an expected capability in long-running coding agents. Claude Code has recently added similar behavior, and other agent/harness tools are moving in the same direction.

For unattended or long-running work, requiring the user to remember to manually resume a task hours later is a significant reliability gap.

[Kron00]

I don't expect this to get merged. It's a working idea you guys can take further if any of it is useful.

Problem

When a provider usage limit stops a long-running thread, users have to remember to reopen it after their subscription resets. Threads that were already doing useful work can sit unfinished even while T3 is still running on their computer.

Fix

• classify native usage-limit errors from Codex, Claude, Cursor, Grok, and OpenCode
• add a "Resume when available" action with a visible scheduled state and cancellation
• persist the schedule so server restarts and reconnects do not lose it
• resume the same thread with a hidden continuation prompt when the reset time arrives
• use provider reset timestamps when available, then back off retries when the provider does not supply one
• cancel safely on settlement, deletion, archival, or newer work, and revalidate timers before starting a provider turn

This PR is desktop/web only. Mobile is unchanged.

Verification

• 704 focused tests across 25 files after updating from the current base branch
• focused Grok adapter and xAI extension rate-limit tests
• vp run --filter @t3tools/contracts typecheck
• vp run --filter @t3tools/client-runtime typecheck
• vp run --filter t3 typecheck
• vp run --filter @t3tools/web typecheck
• targeted lint for changed provider adapters
• git diff --check
• tested the real Codex, Claude, Cursor, Grok, and OpenCode harness error formats against controlled local rate-limit responders
• recorded a desktop end-to-end pass where an existing Grok thread scheduled, fired, and resumed automatically
• repeated the live Grok pass after review fixes and observed the next paced retry when Grok remained limited

Visual evidence

Limit reached	Resume scheduled

Desktop end-to-end recording

Generated with GPT-5.6 Sol in T3 Code through the Codex harness.

---

Note

Medium Risk
Touches core orchestration, provider turn dispatch, and new durable projection fields; incorrect timer or cancel logic could retry turns at the wrong time or leave stale resume state after lifecycle changes.

Overview
Adds durable automatic resume when provider turns stop on usage limits: new orchestration commands/events (schedule, attempt, retry, cancel), projection columns (usage_limit_resume_json, session last_error_class/retry_at), and the threadUsageLimitResume server capability.

ProviderCommandReactor schedules timers from resume events, restores them on startup (with repair for in-flight attempts), retries failed dispatches with backoff, and on attempt fires a hidden Continue from where you left off. turn without a new user message. Failures re-classify usage limits, pace retries via nextUsageLimitRetryAt, and cancel when work is superseded or the thread is settled/archived/deleted.

Decider enforces invariants (usage-limit session required, future resumeAt) and emits companion cancel/interrupt events on settle, delete, archive, manual turn, and interrupt. ProviderRuntimeIngestion persists typed usage_limit/retryAt on runtime errors, reschedules or cancels in-flight resume, and avoids carrying stale error metadata on unrelated session errors.

Snapshot queries and migration 044 expose resume state to clients; tests cover reactor recovery, OpenCode trailing-error ordering, and decider/projector lifecycles. Mock ACP agent gains configurable prompt failure message.

^{Reviewed by Cursor Bugbot for commit b6a9d16. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add automatic thread resume after usage limits reset

• Introduces contracts for OrchestrationRuntimeErrorClass, ThreadUsageLimitResume, and related commands/events in orchestration.ts.
• Server orchestrator classifies usage-limit errors from providers, tracks lastErrorClass and retryAt, and schedules/cancels durable timers to automatically resume threads.
• Web UI and client runtime track resume state and expose user actions to schedule or cancel auto-resume.
• Risk: Database migration 044_UsageLimitResume in 044_UsageLimitResume.ts adds new columns to projection_threads and projection_thread_sessions.

^{Macroscope summarized b6a9d16.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 658c7c3a-f1ed-4e41-b96e-9aa91ef5b044

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

---

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

[macroscopeapp]

Reviewed the web UI changes (ChatView.tsx, chat/ThreadErrorBanner.tsx). The banner itself composes the shared Alert/Button primitives correctly (size="xs" + variant="outline" matches the parked-thread banner action). Three findings on the new usage-limit resume surface in ChatView.tsx.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding on the usage-limit banner: the dismiss affordance is rendered but cannot hide the banner for a usage-limit error with no pending resume.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One minor copy inconsistency in the new banner action; everything else (primitive reuse, size="xs"/variant="outline" in AlertAction, timestamp formatting via snoozeWakeDescription, thread-scoped environment routing for the new commands) matches existing patterns.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding in the reactor's startup reconciliation of pending usage-limit resumes. Details inline.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new usage-limit resume services against the Effect service conventions. One finding: the shared usage-limit dispatch retry is unbounded and does not isolate persistent failures.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new usage-limit resume banner wiring in ChatView.tsx. The earlier notes on the pending label, the dismissal mask, and the timestamp format look resolved.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a default-enabled capability and a broad server/client workflow that persists usage-limit state, schedules retries across restarts, and automatically starts provider turns. Its cross-cutting orchestration, provider, persistence, and lifecycle side effects require human review.

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

[macroscopeapp]

Reviewed the changed web UI (ChatView.tsx, chat/ThreadErrorBanner.tsx, chat/usageLimitResumePresentation.ts) against the shared component system and the repo's environment/capability conventions.

The banner work itself now lines up with the primitives: ThreadErrorBanner keeps Alert/AlertAction ownership, the new action uses Button size="xs" variant="outline" (same geometry as the existing icon-xs dismiss control, so the h-lh / min-h-7 sm:min-h-6 first-line alignment contract still holds), the composer status banner matches its peer ComposerBannerStackItems, and the scheduled time is formatted through snoozeWakeDescription(..., timestampFormat) rather than a raw Intl call.

One finding: the new environment-scoped resume actions are offered without a server capability gate, unlike every other server-backed thread action in this file. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high 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 df9fdff. Configure here.}

[rix1337]

Not commenting on the implementation details here, but I’d consider this a high-priority feature from a product perspective.

Automatic resume after usage limits reset is becoming an expected capability in long-running coding agents. Claude Code has recently added similar behavior, and other agent/harness tools are moving in the same direction.

For unattended or long-running work, requiring the user to remember to manually resume a task hours later is a significant reliability gap.

[Kron00]

I don't expect this to get merged. It's a working idea you guys can take further if any of it is useful.

Problem

When a provider usage limit stops a long-running thread, users have to remember to reopen it after their subscription resets. Threads that were already doing useful work can sit unfinished even while T3 is still running on their computer.

Fix

• classify native usage-limit errors from Codex, Claude, Cursor, Grok, and OpenCode
• add a "Resume when available" action with a visible scheduled state and cancellation
• persist the schedule so server restarts and reconnects do not lose it
• resume the same thread with a hidden continuation prompt when the reset time arrives
• use provider reset timestamps when available, then back off retries when the provider does not supply one
• cancel safely on settlement, deletion, archival, or newer work, and revalidate timers before starting a provider turn

This PR is desktop/web only. Mobile is unchanged.

Verification

• 704 focused tests across 25 files after updating from the current base branch
• focused Grok adapter and xAI extension rate-limit tests
• vp run --filter @t3tools/contracts typecheck
• vp run --filter @t3tools/client-runtime typecheck
• vp run --filter t3 typecheck
• vp run --filter @t3tools/web typecheck
• targeted lint for changed provider adapters
• git diff --check
• tested the real Codex, Claude, Cursor, Grok, and OpenCode harness error formats against controlled local rate-limit responders
• recorded a desktop end-to-end pass where an existing Grok thread scheduled, fired, and resumed automatically
• repeated the live Grok pass after review fixes and observed the next paced retry when Grok remained limited

Visual evidence

Limit reached	Resume scheduled

Desktop end-to-end recording

Generated with GPT-5.6 Sol in T3 Code through the Codex harness.

---

Note

Medium Risk
Touches core orchestration, provider turn dispatch, and new durable projection fields; incorrect timer or cancel logic could retry turns at the wrong time or leave stale resume state after lifecycle changes.

Overview
Adds durable automatic resume when provider turns stop on usage limits: new orchestration commands/events (schedule, attempt, retry, cancel), projection columns (usage_limit_resume_json, session last_error_class/retry_at), and the threadUsageLimitResume server capability.

ProviderCommandReactor schedules timers from resume events, restores them on startup (with repair for in-flight attempts), retries failed dispatches with backoff, and on attempt fires a hidden Continue from where you left off. turn without a new user message. Failures re-classify usage limits, pace retries via nextUsageLimitRetryAt, and cancel when work is superseded or the thread is settled/archived/deleted.

Decider enforces invariants (usage-limit session required, future resumeAt) and emits companion cancel/interrupt events on settle, delete, archive, manual turn, and interrupt. ProviderRuntimeIngestion persists typed usage_limit/retryAt on runtime errors, reschedules or cancels in-flight resume, and avoids carrying stale error metadata on unrelated session errors.

Snapshot queries and migration 044 expose resume state to clients; tests cover reactor recovery, OpenCode trailing-error ordering, and decider/projector lifecycles. Mock ACP agent gains configurable prompt failure message.

^{Reviewed by Cursor Bugbot for commit b6a9d16. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add automatic thread resume after usage limits reset

• Introduces contracts for OrchestrationRuntimeErrorClass, ThreadUsageLimitResume, and related commands/events in orchestration.ts.
• Server orchestrator classifies usage-limit errors from providers, tracks lastErrorClass and retryAt, and schedules/cancels durable timers to automatically resume threads.
• Web UI and client runtime track resume state and expose user actions to schedule or cancel auto-resume.
• Risk: Database migration 044_UsageLimitResume in 044_UsageLimitResume.ts adds new columns to projection_threads and projection_thread_sessions.

^{Macroscope summarized b6a9d16.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 658c7c3a-f1ed-4e41-b96e-9aa91ef5b044

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

---

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

[macroscopeapp]

Reviewed the web UI changes (ChatView.tsx, chat/ThreadErrorBanner.tsx). The banner itself composes the shared Alert/Button primitives correctly (size="xs" + variant="outline" matches the parked-thread banner action). Three findings on the new usage-limit resume surface in ChatView.tsx.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding on the usage-limit banner: the dismiss affordance is rendered but cannot hide the banner for a usage-limit error with no pending resume.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One minor copy inconsistency in the new banner action; everything else (primitive reuse, size="xs"/variant="outline" in AlertAction, timestamp formatting via snoozeWakeDescription, thread-scoped environment routing for the new commands) matches existing patterns.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding in the reactor's startup reconciliation of pending usage-limit resumes. Details inline.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new usage-limit resume services against the Effect service conventions. One finding: the shared usage-limit dispatch retry is unbounded and does not isolate persistent failures.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new usage-limit resume banner wiring in ChatView.tsx. The earlier notes on the pending label, the dismissal mask, and the timestamp format look resolved.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a default-enabled capability and a broad server/client workflow that persists usage-limit state, schedules retries across restarts, and automatically starts provider turns. Its cross-cutting orchestration, provider, persistence, and lifecycle side effects require human review.

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

[macroscopeapp]

Reviewed the changed web UI (ChatView.tsx, chat/ThreadErrorBanner.tsx, chat/usageLimitResumePresentation.ts) against the shared component system and the repo's environment/capability conventions.

The banner work itself now lines up with the primitives: ThreadErrorBanner keeps Alert/AlertAction ownership, the new action uses Button size="xs" variant="outline" (same geometry as the existing icon-xs dismiss control, so the h-lh / min-h-7 sm:min-h-6 first-line alignment contract still holds), the composer status banner matches its peer ComposerBannerStackItems, and the scheduled time is formatted through snoozeWakeDescription(..., timestampFormat) rather than a raw Intl call.

One finding: the new environment-scoped resume actions are offered without a server capability gate, unlike every other server-backed thread action in this file. Details inline.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high 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 df9fdff. Configure here.}

[rix1337]

Not commenting on the implementation details here, but I’d consider this a high-priority feature from a product perspective.

Automatic resume after usage limits reset is becoming an expected capability in long-running coding agents. Claude Code has recently added similar behavior, and other agent/harness tools are moving in the same direction.

For unattended or long-running work, requiring the user to remember to manually resume a task hours later is a significant reliability gap.