kimik3.io/Status
Kimi K3 status
Is Kimi K3 up right now? Success rate and latency over time, plus a 60-second self-check that tells you whether it’s down for you.
Right now: checking… — fetched by your browser at page load, refreshed every 60 seconds.
kimi-k3 (5-minute window per point)Raw collected series; collector script in the repository.
Live fetch unavailable in your browser (blocked or offline) — the 60-second self-check below still works.
The 60-second self-check
One request, no SDK. This is the exact command we ran on 2026-07-18 (response shown below it):
curl https://direct.evolink.ai/v1/chat/completions \
-H "Authorization: Bearer $EVOLINK_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"kimi-k3","messages":[{"role":"user","content":"Reply with the single word: up"}]}'{
"model": "kimi-k3",
"choices": [{
"message": { "content": "up" },
"finish_reason": "stop"
}],
"usage": { "prompt_tokens": 92, "completion_tokens": 48 }
}Read your result
| You got | It means | Do this |
|---|---|---|
200 + content | Not down. Your production issue is elsewhere | Check timeouts and retries in your client |
401 | Your key, not the model | Wrong/expired key or wrong env var — real 401 body |
404 | Model name typo | The ID is exactly kimi-k3 — real 404 body |
429 | Rate limited, not down | Back off and retry; check your balance |
5xx / timeout | Possibly a real incident | Retry once, try the backup base URL, then check provider channels |
200 + empty content | Not an outage — the max_completion_tokens trap, billed in full | The six runs that map it |
| 200 but very slow | Variance, not death — we measured 36s on a trivial prompt | Stream by default; set client timeouts in minutes — timings |
Three things that look like an outage but aren't
- The silent wait. K3 reasons before it answers on every request. Non-streaming, that's seconds-to-minutes of nothing on the wire — a frozen-looking call that's actually working. Streaming shows reasoning tokens within ~3s and makes the same call feel alive.
- The empty response. A capped
max_completion_tokensreturns HTTP 200, an empty string, and a full bill. Every monitoring setup that only checks status codes calls this "up"; every user calls it "broken". It's neither — it's a setting. - The SDK timeout. Long-context calls legitimately run 52+ seconds; default client timeouts kill them and report failure. The model didn't go down — your HTTP client gave up. Set timeouts in minutes at long context.
Status FAQ
Is Kimi K3 down right now?
The charts at the top of this page answer that: they refresh with current data every 60 seconds. For your stack specifically, the 60-second self-check above is definitive.
Why is Kimi K3 so slow?
Usually it isn't down — it's thinking. K3 reasons on every request before emitting the answer; non-streaming that looks like a hang, and we measured real variance (3.6s and 36.1s wall clock for the same trivial prompt on different runs). Stream by default and the first reasoning token arrives in ~3s.
Why does my call return HTTP 200 but empty content?
That's the max_completion_tokens trap, not an outage: budgets at or below ~1,024 returned empty strings with finish_reason: "length", billed in full, across all six of our test runs. Leave the parameter at its 131,072 default.
How often is this page updated?
The live block refreshes itself in your browser every 60 seconds — no action from us involved. The check script is in the site repository, so you can also run exactly what we run.
Run the self-check with your own key
EvoLink carries kimi-k3 on an OpenAI-compatible endpoint — one key reaches GPT, Claude, Gemini, and dozens of the world's mainstream models. 10 free credits, sign up from anywhere — no Chinese phone number.