Vendors set some caps, such as hourly run limits and counts of active schedules, but they protect capacity more than your systems. Add your own: a narrow scope, a maximum number of actions per run, a spending or usage ceiling, and an alert when behavior changes.
Caps the vendors document
Read on 19 October 2026:
| Product | Documented limit |
|---|---|
| Claude Code routines | Scheduled runs, including one-off runs: 100 per hour per account. Run now, API fires and re-running a one-off: 30 per hour per routine. API fires: 100 per hour per account. GitHub events have their own hourly caps, and events beyond the limit are dropped. No overage on these hourly limits. |
| Claude Code routines, minimum interval | One hour |
| Claude Code session tasks | Up to 50 per session, recurring ones expire after 7 days |
| Gemini scheduled actions | Up to 10 active schedules at a time |
Routines also draw down subscription usage like interactive sessions. The page says that when a routine hits the subscription limit, organizations with usage credits turned on can keep running on metered overage, and without credits additional runs are rejected until the window resets. Whether you want a runaway to continue on overage is a decision to make deliberately.
What these caps do and do not do
They bound how many runs start. They do not bound what one run does. A single run with a broad connector list can create many tickets, send many messages or open many pull requests in one go. An hourly cap of 100 is a lot of potential actions.
OWASP notes that rate limiting will not prevent excessive agency but can limit the damage. Treat it as a second line behind permissions.
Limits to add yourself
- Action budget per run. State in the prompt a maximum, such as "create at most five tickets, then stop and report."
- Narrow write scope. Fewer tools means fewer runaway outcomes.
- Rate limits downstream. Chat and ticketing systems can throttle a single account. Use the lowest limits that still allow the job.
- Usage ceiling. Decide whether overage is on for the organization, and who is told when usage spikes.
- Duplicate protection. Search for an existing item before creating one, so a stuck loop does not fill a board.
- Circuit breaker. If a run fails twice, pause the task and notify the owner. Some products let a task edit its own schedule, which cuts both ways, so decide whether that is allowed.
Signs of a runaway
- Runs completing far more often than scheduled
- Many near identical outputs
- A surge in tickets, messages or branches from one account
- Usage rising without a change in workload
- Runs that never finish and block the next ones
The Desktop page notes a run is skipped if the previous one is still in progress, so a stuck task shows up as skips in the history.
Cost note
Do not budget from token prices in blog posts. Look at your own usage page and set alerts. For background on why loops cost more than expected, see why agent bills balloon.
Worked example: the loop that filled a board
A team has a routine that reads alerts and files a ticket for each new one. The prompt does not say how to avoid duplicates and sets no maximum. One night a monitoring system flaps and sends the same alert payload many times through an API trigger. Each fire starts a run. Each run files a ticket. The per routine limit of 30 fires per hour caps the damage, but thirty near identical tickets still appear before dawn, each one notifying the on call engineer.
Look at which limits helped. The vendor cap stopped the flood after thirty runs in the hour, which is better than none. But it did not understand duplicates, and it did not know that the alerts were the same.
Now apply the extra limits. The prompt gains a search step: look for an open ticket with the same alert identifier first, and comment on it instead of creating a new one. It gains an action budget: create at most three tickets per run. The ticketing connector is narrowed to one project. The monitoring system gets a flap suppression setting so it stops repeating itself. An alert fires if more than five tickets are created in an hour by this account.
The next flap produces one ticket and a series of comments. The cap that matters is the one you wrote, not the one the vendor shipped.
Three kinds of limits
| Kind | Example | Who sets it |
|---|---|---|
| Capacity | Hourly run caps, schedule counts | The vendor |
| Authority | Connector scope, sandbox, branch rules | You |
| Behavior | Action budget, duplicate search, stop conditions | You, in the prompt and in downstream systems |
Capacity limits keep the service healthy. Authority limits decide what is possible. Behavior limits shape what usually happens. Rely on authority first, because behavior depends on the model following instructions.
Reading usage like a metric
Check your usage page weekly during the first month of any new task. Note the usage per run and the number of runs. If the product shows per task usage, record it. A task whose usage rises with no change in workload deserves a look. Set an internal threshold, for example twice the typical weekly usage for that task, that triggers a review. Do not invent thresholds from other people's numbers. Use your own baseline.
Stop conditions to write into prompts
- A maximum number of items to process per run.
- A rule to stop and report after two consecutive tool errors.
- A rule never to retry a write action without checking whether it already happened.
- A time budget: stop after a stated number of steps.
- A rule to report when a limit was reached, so you can see it.
Quota and overage decisions
The routines page says that organizations with usage credits turned on can keep running on metered overage after hitting the subscription limit. That keeps a useful task alive and can also keep a runaway alive. Decide who may turn overage on, and agree an alert so a spike reaches a human before it becomes a surprise.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how repeated checks behave over time, and think about the baseline you would need to notice a task running more often than expected.
Quick check
Does a cap of 100 runs per hour limit what a run can do?
No. It limits how many runs start. Limit what each run can do through scope and an action budget.
Who should be alerted on a spike?
The task owner and whoever manages usage for the organization, with a documented way to pause.
What is the first limit to add to a new task?
A cap on actions per run and a duplicate check before any write. Those two stop most runaway outcomes.
Sources
- Automate work with routines (Claude Code docs)
- Run prompts on a schedule (Claude Code docs)
- Schedule recurring tasks in Claude Code Desktop
- Scheduled actions in Gemini Apps (Google Help)
- OWASP LLM06 Excessive Agency
Last reviewed: 19 October 2026.
