What Is Rate Limiting for AI Coding Tools?

Quick answer
Coding tools limit requests per minute, tokens per minute, and concurrent sessions, often in rolling windows rather than per calendar day.
A rolling window means the limit recovers gradually as old usage ages out, so waiting a few minutes can restore capacity.
Hitting a limit usually means one long session or a loop, not a plan that is too small.
Plan limits and API rate limits are different: the subscription governs the tool, the API governs the key.
Build retry with backoff and a clear stop condition, so a limit produces a pause rather than a failed task.

What do AI coding tools actually limit?

Three resources: requests per unit time, tokens per unit time, and concurrent sessions. Some plans also cap total usage in a window. The exact numbers and windows differ by provider and plan, and they change, so check the current documentation rather than relying on a remembered figure.

The practical difference from a normal API is the token component. A single agent turn can consume thousands of tokens, so a session that feels like a few requests can exhaust a token budget quickly, especially when context is large.

Why did I hit the limit on one task?

Because cost scales with context, and a long session re-sends it every turn. One big file read, one verbose test run, and thirty turns can add up to more than a whole day of small edits. The limit is reporting the shape of the workload, not just the volume.

Loops are the other cause. An agent retrying a failing command consumes tokens without producing progress, and the limit arrives while nothing useful is happening. The rate limit is often the first visible symptom of a problem you would rather find earlier.

How do you handle a limit in automation?

Retry with exponential backoff and jitter, and cap the number of retries. A rate limit is a temporary condition; a permanent failure is a different error and should not be retried. Distinguish them by status code or error type, not by message text.

In CI, make the limit visible instead of failing the job silently. A job that paused for capacity should report that, so the queue owner knows the pipeline is waiting rather than broken.

429 or usage_limit -> wait (2^n seconds + jitter, cap 60s), retry <= 5
then: persist checkpoint, release the worker, requeue with a delay
do not: retry a 400, or retry a limit with no delay

How do you avoid hitting it?

Reduce context per turn: read slices, filter tool output, and start a new session per task. Route mechanical work to a smaller model. Split long tasks into steps that fit the budget instead of one continuous session.

For team usage, treat the limit as a shared resource. One person running four parallel agents can exhaust a shared allowance and block everyone else. Concurrency limits are a fairness control, not just a cost control.

Where this bites vibecoders
A generated retry wrapper treats every error the same, so a rate limit becomes five immediate retries that all fail and a task that looks broken. Classify the error, back off, and save the checkpoint before waiting.

Where AI coding assistants get this wrong

Retrying a rate limit immediately and repeatedly.
Treating a plan limit as an API rate limit.
Assuming the window resets at midnight.
Running parallel agents with no concurrency cap.
Losing the checkpoint because the wait happened in-process.
Reading a rate-limit error as a code bug.

Checklist

Know which limit you hit: requests, tokens, or concurrency.
Classify the error before retrying.
Back off with jitter and a retry cap.
Persist state before waiting.
Cap parallel agent sessions per team.
Reduce context per turn to stay under the limit.

FAQ

Is a rate limit the same as a quota?

Related but distinct. A rate limit governs how fast you can consume, a quota governs how much in a period. Providers often apply both, which is why waiting sometimes helps and sometimes does not: a rate limit recovers, an exhausted quota does not.

Does a higher plan remove the problem?

It raises the ceiling, not the shape of the curve. A workflow that consumes a large context every turn will hit a higher limit too. Fixing the context habits is cheaper than upgrading, and it also reduces latency.

Can I avoid limits by using the API directly?

You get different limits, and a bill instead of a subscription. The API has its own per-minute token limits, and a heavy agent workload can hit them too. The trade is predictability of cost against predictability of capacity.

What should I tell the agent when it is throttled?

Nothing, because the throttle happens in the harness, not in the conversation. Handle it in the client: wait, retry, or stop and report. Injecting “you are rate limited” into the context wastes tokens you do not have.