Kimi K3 API Errors: Real Response Bodies for 401, 404 & More

Q: Why does Kimi K3 return 404 model not found?

The model ID is exactly kimi-k3. Moonshot's direct 404 conflates a wrong model name with a permissions problem: it reads 'Not found the model X or Permission denied'. Re-tested 2026-07-18 via EvoLink, the 404 body adds a did_you_mean field pointing at kimi-k3. If your spelling is correct, the issue is access or the gateway not carrying K3, not a typo.

The one that will actually get you isn't in this table's usual company: K3 returns HTTP 200 with an empty content when max_completion_tokens is too low for its reasoning to finish — and bills you in full. It is silent, it looks like success, and it is the most likely way a first integration breaks. Full write-up →

Measured 2026-07-16 against api.moonshot.ai, re-tested 2026-07-18 via direct.evolink.ai, model kimi-k3 — how we measured.

The error shape

Errors come back as a single error object with message, type, and code:

{
  "error": {
    "message": "API key is missing or invalid",
    "type": "invalid_authentication_error",
    "code": null
  }
}

Do not switch on code. It is nullable, and in every error we triggered against Moonshot direct it was absent entirely. type is the field that was always populated — match on that.

Through a gateway, the auth and model-not-found bodies below will not be byte-identical. A bad key is rejected by the gateway's own auth layer and never reaches Moonshot, so you get its wording, not Moonshot's. The symptoms, causes and fixes hold either way. The behavioural findings on this page — the empty-content trap, the parameters that don't validate — are properties of the model and apply wherever K3 is served.

{
  "error": {
    "message": "Invalid Authentication",
    "type": "invalid_authentication_error"
  }
}

The errors, by symptom

Reproduced 2026-07-16 against `kimi-k3`; 404 and tool_choice re-tested 2026-07-18 via `direct.evolink.ai`.
Symptom	What you actually get	Cause & fix
Empty `content`, billed anyway most likely	`HTTP 200` `finish_reason: "length"` `content: ""` populated `reasoning_content`	Reasoning consumed the whole token budget. Raise `max_completion_tokens` or leave it at the 131,072 default. The six runs →
`401` Unauthorized	`{"error": { "message": "Invalid Authentication", "type": "invalid_authentication_error" }}`	Key missing, mistyped, revoked, or the `Bearer` prefix was dropped. Confirm your shell actually exported the variable. There is no `code` field to match on.
`404` model not found	api.moonshot.ai, 2026-07-16: `{"error": { "message": "Not found the model kimi-k3-chat or Permission denied", "type": "resource_not_found_error" }}` via direct.evolink.ai, 2026-07-18: `{"error": { "code": "model_not_found", "did_you_mean": "kimi-k3", "message": "Model 'kimi-k3-chat' is not available for this API key (unknown model id, or not enabled for your group). This error is permanent — do not retry with the same model id. Did you mean 'kimi-k3'? Call GET /v1/models to list the models available to this key." }}`	The ID is exactly `kimi-k3`. Note Moonshot's message conflates "wrong name" with "no access" — if your spelling is right, this is a permissions or listing problem, not a typo. Check your gateway carries K3. Re-tested 2026-07-18 via `direct.evolink.ai`: EvoLink's 404 names the fix outright in a `did_you_mean` field.
`400` empty messages	`{"error": { "message": "Invalid request: messages must not be empty", "type": "invalid_request_error" }}`	Your message array got filtered to nothing upstream — usually a history-trimming bug. Guard before sending.
`400` forced tool_choice	`{"error": { "message": "tool_choice 'specified' is incompatible with thinking enabled", "type": "invalid_request_error", "code": null }}` Measured 2026-07-18 via direct.evolink.ai.	K3's always-on thinking rejects `tool_choice` forcing a specific function. `tool_choice: "auto"` works — the same tool schema returned `finish_reason: "tool_calls"`. Validate the returned tool name yourself instead of forcing it.
`429` rate limited	`{"error": { "message": "Rate limit exceeded", "type": "...", "code": null }}` Per EvoLink's documented schema — we did not trigger this one.	Too many requests or tokens per minute for your tier. Back off exponentially — 1s, 2s, 4s, with jitter. Serialise your own bursts: a retry storm reads as more load. We did not hit a 429 in 50 calls on 2026-07-18, but peak-hour rate limiting is real — OpenRouter's K3 page carries a load warning.
Timeout / hung request	No response for tens of seconds	Expected at long context: we measured 52s on a 498k-token prompt. Set client timeouts in minutes, not seconds, and use `stream: true`.
No `usage` while streaming	Stream completes, no usage block	Pass `stream_options: {"include_usage": true}`. Without it you are blind to what you spent — including reasoning tokens.
Insufficient balance	Provider-dependent	Check your dashboard. Long contexts spend fast: one 498k-token call is $1.49 of input alone.

The failures that don't error

This is the category worth internalising. K3 does not validate your parameters — we found two cases where an obviously invalid request returns a clean HTTP 200:

Both returned `HTTP 200` with a normal completion. 2026-07-16, re-verified 2026-07-18.
What we sent	Why it should fail	What happened
`reasoning_effort: "low"`	Only `max` is documented as supported	HTTP 200 — silently ignored: accepted, no warning, no consistent effect
`max_completion_tokens: 2000000`	Nearly double the 1,048,576 context window	HTTP 200 — value silently clamped to the ceiling, no warning

The lesson generalises beyond these two: a 200 from K3 does not mean your request was understood as you intended. If you are relying on a parameter to change behaviour, verify the behaviour changed — don't infer it from the absence of an error. Combined with the empty-content trap, the rule is simple: assert on the response, not on the status code.

A pre-ship checklist

model in the response echoes kimi-k3 — no silent gateway substitution.
finish_reason == "stop", not "length".
content is non-empty.
usage.total_tokens is non-zero, and you log reasoning_tokens.
Client timeout in minutes if you touch long context.
Any parameter you rely on has been verified by observed behaviour, not by a 200.

The assertion worth having in code is in the API guide.

Kimi K3 error FAQ

What does the Kimi K3 401 Invalid Authentication error mean?

Your API key is missing, mistyped, revoked, or the Bearer prefix was dropped from the Authorization header. The body is {"error": {"message": "Invalid Authentication", "type": "invalid_authentication_error"}} with no code field, so match on type rather than code.

Why does Kimi K3 return 404 model not found?

The model ID is exactly kimi-k3. Moonshot's direct 404 conflates a wrong model name with a permissions problem: it reads 'Not found the model X or Permission denied'. Re-tested 2026-07-18 via EvoLink, the 404 body adds a did_you_mean field pointing at kimi-k3. If your spelling is correct, the issue is access or the gateway not carrying K3, not a typo.

Does the Kimi K3 API validate request parameters?

Not reliably. Two invalid requests return HTTP 200 with a normal completion: reasoning_effort set to 'low' is silently ignored, and max_completion_tokens set to 2,000,000 — nearly double the context window — is silently clamped to the ceiling (re-verified 2026-07-18). Forcing a specific function via tool_choice does fail: 400, tool_choice 'specified' is incompatible with thinking enabled. A 200 does not mean your request was understood as intended.

Reproduce any of this

Every case here reproduces in seconds with a curl and a key. EvoLink carries kimi-k3 on an OpenAI-compatible endpoint — 10 free credits, sign up from anywhere — no Chinese phone number.

Get an EvoLink API key

Kimi K3 errors & failure modes