Moonshot is retiring Kimi K2.5 on 31 August 2026

What Moonshot announced

The Kimi API platform’s model list now carries a note that following the Kimi K3 launch, kimi-k2.5 and the moonshot-v1 series are no longer available to newly registered users, with a full platform sunset on 31 August 2026.

Two things are happening at once here, and they have different urgency:

• Already in effect: new accounts cannot access K2.5 at all. If you signed up after the K3 launch in July 2026, this model was never available to you.
• 31 August 2026: existing access ends.

If you have kimi-k2.5 in a production codebase, you have until the end of the month.

This is the second retirement in four months

The pattern matters more than the individual announcement.

Model	Discontinued	Notice period
kimi-k2 series (incl. kimi-k2-thinking, turbo variants)	25 May 2026	—
kimi-latest	28 January 2026	—
kimi-thinking-preview	11 November 2025	—
kimi-k2.5, moonshot-v1 series	31 August 2026	Announced with K3 launch, July 2026

Four retirements in roughly nine months. Moonshot is iterating fast — K2 to K2.5 to K2.6 to K2.7 to K3 in under a year — and it consolidates the lineup as it goes rather than maintaining old endpoints indefinitely.

The precedent from May is the one to pay attention to: when the kimi-k2 series was discontinued, those endpoints stopped responding. There is no documented grace period, and no evidence of deadlines being extended.

What this means if you are shipping on Kimi

Three practical conclusions.

Treat model identifiers as configuration, not code. If switching models means a code change and a deploy, you will do it under time pressure at some point. Putting the identifier in an environment variable costs nothing today and turns a future migration into a config change.

Put the platform changelog in your monitoring. Moonshot publishes deprecations to its changelog, not by emailing every API key holder. Nobody is going to tap you on the shoulder.

Budget for a migration roughly twice a year. On the current cadence, whatever model you standardise on today has a lifespan measured in months. That is not a criticism — it is the cost of a vendor shipping frontier models quickly — but it should be in your planning rather than a surprise.

What to move to

For most workloads, Kimi K2.6. It has the same 262,144-token context window, the same text, image and video input, and no change to the request format — in most integrations the migration is one line.

Expect a cost increase. K2.5 was the cheapest model in the lineup:

	K2.5	K2.6	Change
Input, cache hit	$0.10	$0.16	+60%
Input, cache miss	$0.60	$0.95	+58%
Output	$3.00	$4.00	+33%

USD per million tokens, excluding tax, verified 6 August 2026.

If your workload is coding, Kimi K2.7 Code is priced identically to K2.6 on cache-miss input and output while being specialised for the task — strictly the better choice at the same money. If you need more than 262,144 tokens of context, Kimi K3 is the only option.

Full instructions, including what to test before you ship, are in the Kimi K2.5 migration guide.

One footnote on open weights

Moonshot published open weights for K2.5, and the platform sunset does not withdraw them. Self-hosting therefore remains technically possible after 31 August.

For almost everyone this is not the answer. K2.5 is a 1-trillion-parameter model, and standing up inference infrastructure for it is a far larger commitment than changing a model identifier. Open weights are a genuine insurance policy against vendor lock-in, but they are not a substitute for migrating.