The engine is currently overloaded

Kimi K3
1

I just recently started to try Kimi-K3 via the API.

However, basically every request I’m sending works for 5-10 minutes to then fail with this error:

{‘error’: {‘message’: ‘The engine is currently overloaded, please try again later’, ‘type’: ‘engine_overloaded_error’}}

All the while, the tokens get counted, but I never get a result I can use. This basically makes the system totally useless. How do I get around that?

2

Hi there,

Sorry for the frustration!

  • Errors are not billed: Requests that fail with an engine_overloaded_error are not charged to your account.
  • Enable Streaming (Crucial): K3 generates very long outputs. We strongly recommend enabling streaming (stream: true). This guarantees you receive intermediate results and prevents your local gateway or ISP from dropping the connection as a dead link due to long TCP idle times. See Streaming Guide.
  • Upgrade your Tier: Higher API tiers receive better queue priority, which significantly improves request success rates during peak loads. Recharge and Rate Limiting.

Please try turning on streaming, and let us know if you still run into issues!

3

Thanks for the prompt reply.

  1. They definitely seem to be. I have a prepaid value, and I only asked a few questions today, which all errored out with the overload error, or the last one just stopped in the middle of it, with no error at all. Yet it shows as today’s bill of $3.77
  2. Streaming is/was enabled. So yes, I do see part of the reply, and also the thinking, but partial results are not that helpful in my case
  3. And yeah, I guess I’m at the bottom of the food chain with my prepaid value.

As an improvement, I’d suggest to first check if it can handle my request, and error out at the beginning if I’m not a priority, to avoid making the machines busy to then drop me like a hot potatoe in the middle of it.

4

I’ve been getting this issue as well. Only with K3 though - 2.7 is fine. Not good

1 Like
5

It’s basically unusable. I can understand that it is popular, but again, if it keeps stopping mid-reply, it useless. It should filter straight from the start.

6

Thanks for the follow-up. I had checked our service side, and here’s what I can share:

  • If the cluster is overloaded and cannot take a request, it’s rejected while still in the queue and fails with 429 typically within tens of seconds — regardless of tier. It would never be held for 5–10 minutes first.
  • For accepted requests, TTFT (time to first token) is currently( and in the last a few weeks ) around 10–20s at P50. On a cache miss combined with a very long input, the first token can take noticeably longer and fluctuate. Queue priority only affects how long an accepted request waits in the queue — lower tiers may wait somewhat longer there at peak.

As for the request that stopped mid-way, “stopped in the middle with no error” is hard to act on by itself, but two things are worth checking first: K3 emits its chain-of-thought in a separate reasoning_content field (see Chat API docs) and only afterwards starts producing content and tool calls — if the client only renders content, a reply can look empty or stalled while the model is actually still outputting reasoning. Also check max_completion_tokens and the final finish_reason: if the token budget was unset or too small, generation ends with finish_reason=length. Beyond that I can’t tell much from the description alone — if you can share the actual output chunks of that request (or the request id), I can analyze it concretely.

And on the bill: requests that fail with engine_overloaded_error are not charged. A request that was accepted and generated tokens (even a partial reply) is billed for what it consumed. The console has a Billing Details page with per-request usage — feel free to cross-check each request there directly; if anything on the statement looks off, let us know.