[FEATURE] Rate-limit-aware deferred prompt scheduling for Claude Code

Status Open

Maintainer reply None cached

Activity 5 comments · opened May 16, 2026

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

Sometimes a user is working on a task in Claude Code, but their usage limit is reached before the task is finished. The limit may reset several hours later, for example early in the morning, when the user is not available to manually restart the task.

Currently, the user has to come back later and manually rerun the prompt. This interrupts longer development workflows, especially when Claude Code is being used for multi-step coding tasks like refactoring, debugging, testing, or continuing work across a project.

The core problem is not bypassing limits. The problem is that there is no safe way to defer a user-approved prompt until usage becomes available again.

Proposed Solution

I would like Claude Code to support a rate-limit-aware deferred prompt scheduling feature.

Example CLI UX:

claude schedule --when-available "Continue the previous task and run tests"

Possible in-session UX:

/schedule when-available Continue the current task after usage resets

The ideal experience:

User reaches a usage limit during a Claude Code workflow.
Claude Code asks whether the user wants to defer the current prompt/task.
User explicitly confirms scheduling.
Claude Code stores the task locally in the same workspace context.
The task runs only after usage becomes available again.
User can view, cancel, or edit scheduled tasks.

Important behavior:

This should not bypass usage limits.
It should respect all existing Claude usage/rate limits.
It should avoid aggressive polling.
It should use reset metadata if available, otherwise a conservative backoff.
It should require explicit user approval before scheduling.
It should limit the number of queued tasks.
It should clearly show that execution is deferred and not guaranteed.

Alternative Solutions

Current workaround:

Manually wait until the usage limit resets.
Come back later and rerun the prompt.
Keep notes outside Claude Code about what needs to continue.

This works, but it is easy to lose context or forget to restart the task, especially when the reset happens late at night or early in the morning.

Another workaround would be using external scripts or cron jobs, but that feels unsafe and unofficial. A built-in Claude Code feature would be better because it can respect product limits, workspace context, and user approval.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Example scenario:

I am using Claude Code to refactor a project.
Claude has already inspected files, understood the workspace, and started making changes.
Before the task is finished, I hit my usage limit.
The reset time is several hours later, such as 4:00 AM.
I do not want to wake up just to manually rerun the prompt.
I would like to approve a deferred task like:

claude schedule --when-available "Continue the refactor from the current context and run the test suite"

When usage is available again, Claude Code resumes the approved task in the same workspace.

This would help with long coding workflows while still respecting Claude's usage limits.

Additional Context

I am proposing this specifically as a limit-respecting workflow improvement, not as a way to bypass usage limits.

This could potentially be implemented as:

a core Claude Code command;
a local deferred task queue;
or a Claude Code plugin if core support is not appropriate.

The key requirement is that the user must explicitly approve the scheduled task, and Claude Code should respect existing usage/rate-limit behavior.

View original on GitHub ↗

5 Comments

github-actions[bot] · 3 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

kcarriedo · 3 months ago

The shape of this problem you're describing is interesting because it sits in the seam between two different concerns that look like one feature from the outside.

The first is the user-facing UX you sketched — "I have a half-finished task, my window is full, schedule it for the reset boundary so I don't have to babysit." That's a scheduler primitive, and it's straightforward to bolt on with local state.

The second is the harder one that shows up the moment people try to use deferred prompts seriously: what is the contract when the deferred task actually runs? The window between "user approved at T+0" and "task runs at T+5h" is where things break in practice:

The working tree has probably moved. The original prompt referenced "the current task" — but current was a pointer to in-session memory that doesn't exist at run-time.
The user-approved permission set was scoped to the originating session. When the deferred task wakes up, it's a new session with no continuity. Should it re-prompt for permissions? Auto-grant? Both options are wrong in different ways.
If the user goes on to do _other_ work in the meantime (in the same workspace, possibly with edits that conflict with what the deferred task was going to do), the deferred task's mental model is now stale before it ever starts.
If claude schedule --when-available is fired twice, what's the dedup contract? Idempotency key? FIFO queue? Cancel-on-conflict?

If the feature only supports the simple case (single deferred prompt, fresh workspace, no permissions ambiguity, no replay-of-stale-state) it's useful but narrow. If it tries to handle the harder cases, it ends up looking less like a scheduler flag and more like a small persistent task store with an idempotency key, a frozen workspace snapshot, and an explicit "this is what I was going to do, has the world changed enough that I should re-confirm?" gate at wake-time.

The CLI surface in the request is good as a starting point — the question worth nailing down before implementation is whether --when-available is just a sleep-until-quota primitive, or whether it commits to also being durable across claude restarts, machine reboots, and concurrent edits to the same workspace. Those are very different scopes and the second one is where the actual user value lives.

aayushhks · 3 months ago

Thanks, this is a good point. I agree the main concern is not just “run the prompt later,” but what state and permissions the task should have when it resumes.

Maybe the safer version of this feature is not automatic execution, but a deferred resume flow:

store the original prompt locally with workspace metadata;
detect whether the working tree or git commit changed before resuming;
show the user the deferred task at wake time;
ask the user to confirm, edit, or cancel;
go through the normal Claude Code permission flow again.

So instead of blindly running at the reset time, Claude Code would preserve the task and safely offer to resume it once usage is available.

That would solve the main problem without creating issues around stale context, permissions, or concurrent workspace changes.

ShoT-UPfps · 2 months ago

Codex will simply continue until the agent completes even when the 5 hour window is at 100%. Usage is still tracked against the 7-day window. Don't see why Anthropic can't meet OpenAI on this.

rohanprichard · 1 month ago

Until something like this ships natively, I built an open-source version of exactly this flow: a /queue slash command stores prompts locally, and a launchd job runs them through claude -p once your limits have reset, with utilization thresholds so the batch doesn't drain the fresh window (don't start above X% of the 5h window, stop at Y%, skip entirely if weekly is above Z%). Jobs that hit the cap get requeued rather than failed.

macOS only for now: https://github.com/rohanprichard/claude-overnight (MIT). Happy for any of this design to be cannibalized for the native feature — the threshold model in particular seems worth keeping, atleast from my personal usage.