About this site

Who we are, and the conflict of interest

kimik3.io is built by the team at EvoLink, an API gateway that carries kimi-k3 alongside GPT, Claude, Gemini, and dozens of the world's mainstream models on an OpenAI-compatible endpoint. We would like you to use EvoLink. That is why this site exists, and you should read everything on it with that in mind.

So here is the deal we've made with ourselves, and you can hold us to it:

• The facts don't bend toward us. Prices are quoted from Moonshot's official page with the date we read them. Measurements are what came back, including the ones that are inconvenient. If K3 is slow, we say 52 seconds.
• We mark the boundary of what we know. Moonshot documents no cache TTL, no minimum prefix length, and nothing about cache-write surcharges. We could have filled those gaps with confident-sounding guesses. We didn't, and where we extrapolate we label it.

If you find something on this site that's wrong, it's a bug and we want to fix it. The raw measurement data is published on this site, so you don't have to take our word for any of it.

Why this site exists

K3 launched in July 2026 and the API was live the same day. Within hours there were pages quoting guessed prices, repeating unconfirmed parameter counts, and reprinting the official quickstart. What there wasn't: anyone who had actually run the thing and written down what happened.

That's a small, specific gap and it's the one we set out to fill. Not "what is Kimi K3" — Moonshot's docs cover that, and they'll always be more authoritative than us about their own model. The gap is the layer above the docs: what breaks, what it really costs, how long it really takes. Everything here that isn't a quoted official fact came from us running kimi-k3 and writing down the result.

How we measured

Every number marked measured on this site was produced on 2026-07-16 by calling https://api.moonshot.ai/v1/chat/completions with model kimi-k3, from a single client on a single network path.

What we did

• Cache tests used freshly generated prefixes containing random UUIDs and hashes, so nothing we tested had ever been sent to Moonshot before. That is what makes a "cold" call genuinely cold — a prefix someone else had already warmed would have quietly invalidated the result.
• Error bodies came from deliberately malforming real requests: an invalid key, a wrong model string, an empty message array, out-of-range parameters. The JSON on the errors page is copied from the wire, not reconstructed.
• Latency was measured with a streaming client timing the first delta of any kind, the first content delta separately, and total wall clock.
• The empty-response finding was reproduced across six budgets from 64 to 2,048 tokens, changing nothing but max_completion_tokens.

What these numbers are not

They are not benchmarks, and we'd rather say so plainly than let the tables imply more than they support:

• They carry our network path and Moonshot's load on a launch day, when a brand-new flagship model is presumably busy. Your latency will differ.
• Extrapolations are labelled. The full-window cost and timing on the context window page are arithmetic from two measured points, not a measurement.

What carries through a gateway, and what doesn't

We measured against Moonshot direct. Most people reach K3 through a gateway, so the useful question is which of our findings still apply. The line is clean:

We would rather draw this line explicitly than let a blanket disclaimer imply our model findings are somehow provisional. They aren't — they reproduce anywhere K3 is served. The two exceptions are exceptions for a physical reason, not a hedging one.

The raw data

The complete measurement dataset is published here, machine-readable:

• measurements-2026-07-16.json — every run, raw; CC BY 4.0, cite kimik3.io

The method section above describes each test precisely enough to rerun with your own key. If your results differ from ours, we would genuinely like to know.