Kimi K2.5

Can you still use Kimi K2.5?

Only if your account already has access. Moonshot AI closed Kimi K2.5 to accounts registered after the Kimi K3 launch, and sunsets the model entirely on August 31, 2026. For most people reading this, it is not a purchasing option — it is a migration problem or a historical note.

That makes this page unusual. Every price below is real and currently in force, and almost none of it should influence a decision you make today. If you are choosing a model, start at Kimi K2.6 or Kimi K3 instead.

If you do have an existing integration, the rest of this page is for you, and the useful part is the timeline.

What should you migrate to?

Kimi K2.6 for almost everyone. It matches K2.5 on the things that usually break a migration — same 262,144-token context window, same text, image and video input, web search still documented — and it has no scheduled retirement.

	Kimi K2.5	Kimi K2.6	Kimi K2.7 Code
Context window	262,144	262,144	262,144
Input, cache hit	$0.10	$0.16	$0.19
Input, cache miss	$0.60	$0.95	$0.95
Output	$3.00	$4.00	$4.00
Web search	Documented	Documented	Not documented
Status	Sunsets August 31, 2026	Current	Current

Per million tokens.

Choose K2.7 Code instead if the workload is mostly code — it is priced identically to K2.6 on cache-miss input and output, and it is tuned for instruction-following in long contexts. The one thing it gives up is web search.

Go to K3 only if you need more than 262,144 tokens of context or structured output. Neither is a reason most K2.5 workloads will hit, and K3 costs considerably more per token.

Our migration guide walks through the actual code changes, which in most cases amount to changing one model identifier.

Your bill will go up. How much?

Expect an increase on output tokens, because K2.5 is the cheapest model Moonshot still serves. Output goes from $3.00 to $4.00 per million on the move to K2.6, and cache-miss input from $0.60 to $0.95.

We would rather state that plainly than describe the migration as a free upgrade. It is not. The price difference is real and it is the reason people delay the move.

What softens it is cache behaviour. Both models discount cached input by roughly the same proportion, so a workload with a stable repeated prefix sees a smaller effective increase than the headline rates suggest. If you have not audited your cache hit rate, the migration is a good moment to — the cost calculator models both models side by side with a cache-hit input.

Why is the deadline the part that matters?

Because the alternative to migrating on your schedule is migrating on Moonshot’s, in production, after requests start failing. Moonshot has not published what happens to K2.5 calls after August 31, 2026, so the safe assumption is that they stop working rather than quietly routing somewhere else.

There is precedent worth taking seriously. The whole kimi-k2-* series was discontinued on 25 May 2026 and those endpoints no longer respond — no fallback, no grace period we are aware of. Kimi K2 is the page for that, and it is the second Kimi retirement inside four months. We wrote up what this shutdown means and what the pattern suggests in Moonshot is retiring Kimi K2.5 on 31 August 2026.

That cadence is the real lesson here, and it is why this site puts a verification date next to every number. Moonshot ships and retires models faster than most published comparisons get updated. A price you find quoted elsewhere for a Kimi model may be describing something that no longer exists.

What does the migration actually involve?

For most integrations, changing one string. The Kimi API is Chat Completions-shaped across every model, so the request and response formats do not change between K2.5 and K2.6 — which is why this migration is far less work than the deadline makes it feel.

The checklist we would work through:

1. Find every hardcoded model identifier. kimi-k2.5 may appear in more than one place — application code, background jobs, evaluation scripts, notebooks. This is the step people miss, and the leftovers fail silently until the shutdown date.
2. Move it into configuration. If you are touching every call site anyway, make the next migration a deploy rather than a refactor. There will be a next migration.
3. Check capability assumptions. K2.6 documents the same text, image and video input and keeps web search, so most code carries over untouched. Confirm rather than assume if you rely on anything unusual.
4. Re-run your evaluations. Different model, potentially different outputs. If you have no evaluation set, a sample of real prompts compared side by side is better than nothing.
5. Re-estimate cost before you switch, not after. The rates go up. Model it in the cost calculator with your real cache hit rate so the first invoice is not a surprise.
6. Audit your cached prefix while you are in there. Cache-hit pricing is where the increase gets absorbed, and a prefix with a timestamp interpolated into it is not getting cached at all.

The migration guide covers the code-level detail.

What if you cannot migrate in time?

The weights are downloadable, so self-hosting is technically an option — K2.5 is published as open weights, and the API shutdown does not remove them. That is a genuine escape hatch for a workload that cannot move.

It is also a serious undertaking, and it is not the same as a hosted API. You take on serving infrastructure, throughput, availability and the licence terms attached to the weight release. Read that licence before assuming commercial deployment is permitted. For most teams, changing one model identifier is dramatically cheaper than standing up inference.