Kimi K3 rate limit: three 429 causes and one lookalike

A 429 from Kimi K3 has three official causes, plus one failure that looks the same. When the response carries an error.type, read it before you change anything; when it does not, start with the HTTP status. The type names the layer, and the layers have different fixes.

Disclosure: Wallaby Token sells API access to Kimi K3. The production incident below is ours; the error taxonomy is quoted from Moonshot's documentation, accessed 28 October 2026.

Three 429s and one lookalike

What the body says	What it means	What actually fixes it
`engine_overloaded_error`	The serving node is at capacity, often at peak hour.	Wait for `Retry-After`, reduce concurrency, retry with exponential backoff. Topping up does not help.
`rate_limit_reached_error`	Your organization hit a concurrency, RPM, TPM, or TPD limit.	Slow down, or raise your tier; limits scale with cumulative top-up.
`exceeded_current_quota_error`	Balance too low, account overdue, or voucher expired.	Check `available_balance` and top up.
No API error body	A client retry storm, a gateway 503, or a wrong key returning 401/404.	Read the status code first; do not retry blindly.

The first three are official and documented. The fourth is the one that wastes afternoons: it is not a 429 from the model at all, and no amount of backoff on the API call will fix a wrong key or a gateway outage.

The max_completion_tokens trap

Kimi's gateway calculates TPM from prompt tokens plus max_completion_tokens, not from the tokens the model actually generates. Set max_completion_tokens: 64000 on a 2,000-token prompt and you have reserved 66,000 tokens of TPM for that request, even if the answer is 400 tokens. A few concurrent agent calls with a generous ceiling can hit a TPM limit while your actual throughput is nowhere near it.

Two fixes: set a realistic ceiling per call (editors and chat turns rarely need 64k), and lower concurrency before you upgrade a tier. The docs are explicit that billing uses actual tokens while rate limiting uses the reservation. That gap is the trap.

Limits are per user, not per key

Moonshot enforces limits at the user level, not the key level, and shares them across models. Creating a second API key does not double your RPM or TPM. If you need more headroom, the lever is the account tier (cumulative top-up), not key count.

This is also why an error message can show a limit that does not match your dashboard: the key may belong to a different account. The docs use "organization" in one place and "user" in another for the same bucket; neither is per key.

Retries amplify the 429

The OpenAI SDK retries 429s by default. One failing operation can become three or five requests, each consuming quota, which turns a short limit into a longer one. When you debug, count requests in the client log, not operations in your code.

The fix is boring and effective: exponential backoff with jitter, honor Retry-After, cap retries at two or three, and make the retry budget visible. If you run an agent loop, put the retry policy in one place; per-tool retries multiply.

What a 429 looks like behind a gateway

A gateway adds a layer. We keep two provider keys per model and switch per request; when one key hits a cap, the next request goes to the other. If both are exhausted, the gateway returns 503 with an internal alert rather than passing a misleading 429 to the client.

That design was tested on 20 September 2026. A provider key hit its cap at 14:41; every channel backed by that key returned 429. The router failed over and recovered by design, but the incident lasted 31 minutes end to end. Failover shortens an outage; it does not make it instant. The lesson: per-key headroom is a production metric. A 429 is a capacity signal, not a billing error.

If you call a gateway and see 429, read the gateway's error body before touching your client. If you see 503, the provider pool is likely exhausted and retrying the same request will not help.

The triage order

Read error.type and the HTTP status.
If exceeded_current_quota_error, check balance and voucher expiry.
If rate_limit_reached_error, check concurrency and max_completion_tokens before upgrading.
If engine_overloaded_error, honor Retry-After; do not top up.
If there is no API error body, check the client's retry count and the base URL.
Only then change the tier.

429s are not charged

Moonshot's docs state that requests interrupted by a 429 are not charged. That matters for two reasons: a retry storm does not cost tokens, but it does consume quota and time; and a bill that looks flat during an incident is expected, not evidence that the limit did not happen.

Try the endpoint

Wallaby's K3 endpoint starts with $0.50 of trial credit and a $20 minimum top-up; the rate is $2.70 / $0.27 / $13.50 per million tokens, 10% off the official list. Create an account.

If you are debugging a client rather than a limit, Cline + Kimi K3: every error we've hit covers the 401/404 family; Kimi K3 in Codex covers the Responses API setup.

Sources: Moonshot AI, Recharge and Rate Limiting (platform.kimi.ai/docs/pricing/limits), Troubleshooting (platform.kimi.ai/docs/guide/troubleshooting), Introduction (platform.kimi.ai/docs/introduction), accessed 28 October 2026. Wallaby incident log, 20 September 2026.