[FEATURE] Remote control: surface ‘wait for reset’ or ‘upgrade’ when usage limit hits mid-session

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When controlling Claude Code remotely (mobile / web / from another machine while a longer task is in flight), hitting the per-window usage limit produces an opaque failure — the session stalls without indicating why, when access returns, or what the user can do about it. On mobile this is especially disorienting because the user can’t easily inspect logs or reroute to a different machine.
Requested behavior:

1. Detect the cap proactively — when the next response is likely to exceed remaining quota, warn before issuing the call.
2. Surface a clear, actionable banner on the limit-hit event with three options:

• Wait — show a countdown to the next reset window; offer to auto-resume when it elapses (or surface /schedule as a one-tap option).
• Upgrade — deep-link into the plan-upgrade flow with the current usage stats prefilled.
• Switch model / scope — fall back to a smaller/cheaper model or a reduced-context mode so work doesn’t fully halt.

1. Persist the in-flight task state so when the user returns post-reset (or post-upgrade), the conversation resumes exactly where it left off — not a fresh session.
2. On the desktop CLI, keep parity: the same banner + options should appear, not just a terse error string.

Why it matters: Pro and Max users running long-running agents from mobile lose work and trust when the cap fires silently. The cap itself is fine; the opacity around it is the bug.

Proposed Solution

When controlling Claude Code remotely (mobile / web / from another machine while a longer task is in flight), hitting the per-window usage limit produces an opaque failure — the session stalls without indicating why, when access returns, or what the user can do about it. On mobile this is especially disorienting because the user can’t easily inspect logs or reroute to a different machine.
Requested behavior:

1. Detect the cap proactively — when the next response is likely to exceed remaining quota, warn before issuing the call.
2. Surface a clear, actionable banner on the limit-hit event with three options:

• Wait — show a countdown to the next reset window; offer to auto-resume when it elapses (or surface /schedule as a one-tap option).
• Upgrade — deep-link into the plan-upgrade flow with the current usage stats prefilled.
• Switch model / scope — fall back to a smaller/cheaper model or a reduced-context mode so work doesn’t fully halt.

1. Persist the in-flight task state so when the user returns post-reset (or post-upgrade), the conversation resumes exactly where it left off — not a fresh session.
2. On the desktop CLI, keep parity: the same banner + options should appear, not just a terse error string.

Why it matters: Pro and Max users running long-running agents from mobile lose work and trust when the cap fires silently. The cap itself is fine; the opacity around it is the bug.

Alternative Solutions

When controlling Claude Code remotely (mobile / web / from another machine while a longer task is in flight), hitting the per-window usage limit produces an opaque failure — the session stalls without indicating why, when access returns, or what the user can do about it. On mobile this is especially disorienting because the user can’t easily inspect logs or reroute to a different machine.
Requested behavior:

1. Detect the cap proactively — when the next response is likely to exceed remaining quota, warn before issuing the call.
2. Surface a clear, actionable banner on the limit-hit event with three options:

• Wait — show a countdown to the next reset window; offer to auto-resume when it elapses (or surface /schedule as a one-tap option).
• Upgrade — deep-link into the plan-upgrade flow with the current usage stats prefilled.
• Switch model / scope — fall back to a smaller/cheaper model or a reduced-context mode so work doesn’t fully halt.

1. Persist the in-flight task state so when the user returns post-reset (or post-upgrade), the conversation resumes exactly where it left off — not a fresh session.
2. On the desktop CLI, keep parity: the same banner + options should appear, not just a terse error string.

Why it matters: Pro and Max users running long-running agents from mobile lose work and trust when the cap fires silently. The cap itself is fine; the opacity around it is the bug.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_