Cohere API 429 Too Many Requests: Why It Fires and How to Clear It (2026)

A 429 is the only error in the 4xx range that is not a complaint about your request. The JSON was valid, the key was accepted, the model existed — and the service declined to run it because of how much you had already asked for. That makes it the one error where reading the payload gets you nowhere and reading the response headers gets you everything.

It is also the error most often confused with a Cohere outage. A 429 means the service is up and working precisely as designed; it is enforcing an allowance. If you are here because requests started failing, the first job is to establish which of the two you are looking at, because the response to a throttle and the response to an incident have almost nothing in common.

30-second triage: read the x-ratelimit-remaining-* headers on the failing response, not your dashboard. If remaining is at or near zero, this is your allowance and nothing about Cohere is broken. If the headers look healthy and calls still fail, check live Cohere status — you may be reading a 429 emitted by your own gateway rather than by api.cohere.com.

429 is not 503, and the fix is the opposite

These two get filed together as “capacity errors” and then treated with the same retry policy, which is how teams end up applying a fix that cannot work. The distinction is about whose consumption caused it, and it determines everything downstream.

	429 Too Many Requests	503 Service Unavailable
Cause	Your account exceeded a written allowance	The fleet had no capacity for anyone
Does slowing down help?	Yes — immediately and reliably	Often not at all
Does paying more help?	Yes — limits are an account property	No — billing does not create hardware
Failing over to another provider	Works, but you are exporting your own pacing bug	The correct response
Shows on a status page?	Never — the service is healthy	Usually, if it is widespread

The row that costs the most money is the fourth one. Failing over to a second provider on 429 feels like resilience and is frequently the opposite: you have taken a load pattern that one provider already told you was too aggressive and pointed it at a provider that has not told you yet. Failover belongs on 5xx. A 429 belongs in a queue. The full treatment of the 5xx side is in the Cohere 503 guide.

📡

Recommended

Tell a Throttle From an Outage in Seconds

External checks against your AI endpoints run from outside your infrastructure, so you can see immediately whether the failure is your allowance or the provider's fleet — instead of debating it while requests fail.

Try Better Stack Free →

Read the headers, not the dashboard

A rate-limit dashboard aggregates. A 429 does not. The response that refused you carries headers scoped to the exact allowance, model and window that produced the refusal, and that is the only evidence that is actually about your error. Cohere returns x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset, scoped to the endpoint being called, and the gap between what those say and what a dashboard chart implies is where most of the confusion in this category lives.

curl -i -s -D /dev/stderr -o /dev/null \
  https://api.cohere.com/v2/chat \
  -H "Authorization: Bearer $COHERE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"command-r-plus","messages":[{"role":"user","content":"ping"}],"max_tokens":1}' \
  2>&1 | grep -i "ratelimit\|retry-after\|^HTTP"

Capture those headers on every response, not only on failures. The value of the remaining counters is that they let you see the allowance being consumed before it is exhausted; harvesting them only from 429s means you have instrumented the moment it is already too late to act. A gauge of remaining-headroom over time turns this entire class of incident into something you watch approaching rather than something that arrives.

The Cohere trap: trial keys and per-endpoint limits, not one account-wide number

Cohere issues trial keys and production keys from the same dashboard, and they look identical in an environment variable. The trial key is capped at a rate low enough to be useless in production and carries a monthly ceiling on top of it, so the classic Cohere incident is a service that worked perfectly in development, was deployed without anyone re-reading which key got copied, and began returning 429s the moment real traffic arrived. Before you touch your retry policy, confirm which key type is in the running environment — it is a one-minute check that resolves a startling share of these.

The second trap is specific to how Cohere is usually used. Chat, embed and rerank are separately metered endpoints, and a retrieval pipeline hits all three in one logical operation. Embedding is the leg that throttles first, because a single user query can fan out into a batch of document embeddings, and the 429 then surfaces in your logs at whatever layer wraps the pipeline — which is very often labelled with the chat model. Log the endpoint alongside the status code, or you will spend an afternoon tuning limits on the one call that was never the problem.

Batching is the lever that matters here and it is genuinely large. The embed endpoint accepts many texts per request, so a loop that embeds documents one at a time is spending its requests-per-minute allowance at the worst possible exchange rate. Consolidating into batched calls frequently removes the 429 outright without any quota change, and it is worth doing before you open a support ticket — the limit was rarely the binding constraint.

Fix the pacing before you fix the retries

Retrying a 429 harder is the reflex and it is the wrong order of operations. A retry loop against a throttle converts one refused request into several refused requests, which consumes the very allowance you are waiting to recover. The sequence that actually works starts upstream of the retry, and each step removes load rather than rescheduling it:

Cap concurrency at the client. A single semaphore sized to your published allowance is worth more than any backoff policy, because it prevents the 429 rather than reacting to it. Most teams discover their real concurrency is set by whatever their worker pool happened to default to.
Queue instead of failing. Work nobody is watching — enrichment, backfills, scheduled summaries — should accept a delay rather than an error. Draining a queue at a fixed rate makes your consumption a constant instead of a spike.
Honour Retry-After exactly. When it is present it is the only number in the exchange that reflects what the service knows. Waiting less is not clever; it guarantees the next attempt is refused too.
Back off with full jitter. Randomise across the whole window rather than adding a wobble. Deterministic backoff synchronises your own fleet into waves that recreate the burst that caused the throttle.
Separate interactive from batch traffic. Different keys, different queues, different priorities. Otherwise a nightly job decides your users’ error rate, and it will.

Once pacing is in place, the retry policy has far less work to do. Size it as a budget expressed as a ratio of retries to successes, so it collapses on its own when almost everything is failing — the detail covered in the Cohere retry budget guide.

When raising the limit is the right answer

Pacing has a floor. If your steady-state demand genuinely exceeds the allowance, queueing only converts an error rate into a latency figure and eventually a backlog that never drains. Three signals say the constraint is the quota rather than your behaviour: the remaining-headroom gauge sits near zero across the whole day rather than at peaks; your concurrency cap is already at the published limit; and the queue depth trends upward over a week instead of oscillating.

When those hold, raise the ceiling rather than tuning further. What to ask for and how to evidence it is in the Cohere quota increase guide, and the published baselines you are arguing against are in the Cohere rate limits reference. Bring the header data with you — a request backed by a remaining-headroom timeseries is a different conversation from one backed by an assertion.

Frequently Asked Questions

What does a 429 from the Cohere API actually mean?

It means the request itself was fine and the service refused it because of how much you had already asked for inside a measured window. Nothing in the payload needs to change for the identical call to succeed a moment later, which puts it in a different category from every other 4xx: a 400 or a 401 will keep failing until you edit something, and a 429 will keep succeeding once you slow down. Read it as a scheduling constraint, not a defect. The corollary matters too — a 429 is proof the service is healthy and enforcing policy, so it should never be counted as Cohere downtime in your own availability numbers.

Is a 429 the same as Cohere being down?

No, and treating them the same produces the wrong response in both directions. A 429 says the service is up and deliberately declining your excess; a 5xx says the service could not serve the request at all. The clean test is what happens when you reduce load: cut concurrency and 429s stop almost immediately, while a genuine outage carries on regardless of how politely you ask. Split the two in your metrics and your alerting, because they need opposite responses — 429s want a queue and slower pacing, outages want failover to a second provider. A dashboard that lumps all failures into one error-rate line makes this distinction impossible to see at exactly the moment it matters.

Why is my Cohere chat call fine but my RAG pipeline still returns 429?

Because Cohere meters chat, embed and rerank as separate endpoints, and a retrieval pipeline touches all three inside what your code treats as one operation. Embedding is nearly always the leg that trips first: one user query fans out into a batch of document embeddings, so the embed endpoint sees an order of magnitude more calls than chat does. The 429 then appears in your logs attributed to whatever wrapper spans the pipeline — frequently tagged with the chat model — which sends people to tune the wrong limit. Log the endpoint name next to the status code, then batch your embed calls rather than looping one text at a time; consolidation alone resolves most of these without any quota change. And check whether the key in the deployed environment is a trial key, which carries a far lower cap than the production key it is usually mistaken for.

How should I retry a 429 without making it worse?

With a policy rather than a loop, and only after you have capped concurrency. Honour a Retry-After header exactly when one is present, and otherwise back off exponentially with full jitter so a fleet of clients does not resynchronise and re-burst the instant the window resets. Cap attempts against a deadline rather than a fixed count, so a request nobody is waiting for is abandoned instead of retried. Express the allowance as a retry budget — a ratio of retries to successes — which collapses automatically when most calls are failing, the case where naive retries do the most damage. And never retry a 429 in a tight loop with a fixed short delay: that is not a retry policy, it is a second source of the load that caused the problem.

Will upgrading my Cohere plan stop the 429s?

Usually yes, because unlike a 503 a 429 is genuinely an account property — the allowance is written down and attached to you. That makes upgrading a legitimate fix rather than a superstition. It is the right fix when your remaining-headroom gauge sits near zero across the whole day rather than at peaks, your client concurrency is already capped at the published limit, and your queue depth trends upward across a week. It is the wrong fix when the 429s are bursty and cluster around a specific job, because a higher ceiling simply raises the level at which the same unpaced burst trips it, and you will be back with a bigger bill and the same error.

Should I fail over to another provider when I get a 429?

Rarely, and it is the most expensive habit in this category. A 429 means one provider has already told you your load pattern is too aggressive for the allowance you hold; routing that same pattern to a second provider exports the problem rather than solving it, and you will trip the new provider's limits too, only later and with a warm cache of false confidence in between. Failover is the correct response to 5xx, where the fault genuinely is on the provider side. For a 429 the correct responses are a client-side concurrency cap, a queue for work nobody is watching, and a quota increase if steady-state demand truly exceeds the ceiling. The one legitimate exception is a deliberate multi-provider architecture where you are load-balancing across allowances by design rather than reacting to an error.

Related Cohere Guides

Stop Guessing Whether It Is You or Cohere

API Status Check watches Cohere and the rest of your stack from outside your infrastructure, so a throttle never gets debugged as an outage — and a real outage never gets dismissed as a throttle.

Start Your Free Trial →

Cohere API 429 Too Many Requests

Live Cohere status right now