Sooner or later a request comes back refused because you've made too many too quickly. This is a rate limit, it's normal, and the right response is different from the response to an error.

What they are

Ceilings on how much you can use in a window, by requests and by tokens. They rise as your account matures through usage tiers, and they're per model, so heavy use of one doesn't necessarily throttle another.

They exist to keep capacity available for everyone, and they're a capacity control rather than a spending control. Don't confuse the two: a rate limit stops you going fast, a spend cap stops you going broke. You need both and they're different mechanisms.

What to do

Back off and retry. The response usually tells you how long to wait, and when it does, honour it rather than picking your own interval.

retry-properly.txt
Add proper rate limit handling to my model calls: <paste>

- Retry on 429 and on server errors. Never retry a 400 — that's my bug
  and retrying it forever gets me throttled harder.
- Exponential backoff with jitter. Explain what the jitter is for.
- Honour the retry-after value when the response gives one.
- A hard ceiling on attempts so a broken request can't loop.
- Log every retry so I can see if I'm hitting limits constantly.

Then tell me what the user sees while this is happening.

The jitter matters more than it sounds. Without it, everything that got limited at once retries at once, and you rebuild the spike you were backing off from.

Never retry a 400

A 400 means your request is malformed. It will be malformed on the next attempt too. Retrying invalid requests in a loop is how a small bug turns into a throttled account.

Retry the things that might work next time: rate limits, timeouts, server errors. Fail fast on the things that never will.

Designing so you hit them less

Batch work that can wait, at half the price and outside your interactive limits. Cache aggressively, since cached reads consume fewer input tokens against your allowance. Spread scheduled jobs out instead of firing everything at midnight.

If you're vibe coding rather than building

You'll meet rate limits occasionally in a coding tool, usually as a pause. Nothing to fix. Wait a moment and carry on.

Constant rate limiting isn't a limit problem, it's a design problem. Something is making far more calls than the work requires.