# Rate Limit (/academy/rate-limit)



A **429** is not you breaking the internet. It is the [API](/academy/api) saying you asked too fast.

A **rate limit** caps how many requests you may fire in a window of time. Every vendor has one. It stops one client — or one runaway [agent](/academy/agent) — from eating the kitchen. The number lives in their docs. It is not a mystery.

**Why demo day hits it**

A human clicks. An agent in a loop can fire a hundred calls before you look up. The [CLI](/academy/cli) retrying a failed [deploy](/academy/deploy). A page that refetches on every keystroke. Same 429.

Fixes that actually work:

* Back off. Wait. Retry once. Good [SDKs](/academy/sdk) already do this.
* Ask for a list, not a row a hundred times. One trip beats a hundred.
* [Cache](/academy/cache) the answer you already have.

Sometimes the limit is the plan. Free tiers are slow on purpose. That is a checkout, not a [bug](/academy/bug).

**Build your own cap too**

If you expose an [endpoint](/academy/endpoint) on the public internet, put a limit on it. Judges mash refresh. Bots mash harder. A missing cap is how a weekend project becomes a surprise invoice.

Do not confuse this with [CORS](/academy/cors). CORS is the browser asking permission. A rate limit is the server saying "later." Your [frontend](/academy/frontend-backend) should show a calm "try again" — not a stack trace.

**What this unlocks**

A 429 is a pause, not a funeral.

Slow down, batch, cache. Spend the quota on the demo, not the loop.