[FEATURE] Rate-limit-aware deferred prompt scheduling for Claude Code
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.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗