Kimi K2 Series Discontinued on May 25, 2026

What You'll Learn

• What the official Kimi model list says about the K2 sunset.
• Why Kimi K3 is the documented continued-support destination, while K2.6 remains a separate option.
• How the current Moonshot API base URL, model IDs and authentication work.
• How to migrate safely without assuming compatibility, cost or output quality.

Kimi K2 discontinued is no longer a rumour or a future deadline. Moonshot’s official Kimi API model list says the Kimi K2 series was discontinued on May 25, 2026 and is no longer maintained or supported. That is the part of the old article that remains correct.

The old article’s replacement story was too tidy. It treated Kimi K2.6 as the mandatory successor, copied an exact price table and promised a ten-minute migration. The current official documentation instead points users to Kimi K3 for continued support, while still listing Kimi K2.6 and Kimi K2.7 Code. A production migration should follow the model that fits the workload, not the shortest headline.

This guide uses Moonshot’s current documentation as the source of truth. Prices, model availability, account access and rate limits can change. The examples below show the documented API shape, but they should be tested with a non-production key and representative prompts before a live cutover.

What exactly happened to Kimi K2?

Moonshot’s official model list places the Kimi K2 identifiers in a deprecated-model section. It says the Kimi K2 series was officially discontinued on May 25, 2026 and is no longer maintained or supported. The listed deprecated identifiers include kimi-k2-0905-preview, kimi-k2-0711-preview, kimi-k2-turbo-preview, kimi-k2-thinking and kimi-k2-thinking-turbo.

Discontinued does not necessarily mean that every existing request fails at the same instant in every account or region. It means the provider no longer promises ongoing maintenance or support for those model IDs. That distinction matters because a request that happens to return a response today is not a sensible foundation for a new production integration.

The official page also notes that kimi-k2.5 and the Moonshot V1 series are no longer available to newly registered users after the Kimi K3 launch, with a full platform sunset expected on August 31. That is a separate status note from the May 25 K2 series discontinuation. Do not collapse the dates into one generic “Kimi shutdown”.

For broader AI-product context, see our Technology section and the AI prompt-engineering guide. The same rule applies to every rapidly changing API: verify the provider’s current documentation instead of relying on a cached launch article.

Should developers migrate to Kimi K3 or Kimi K2.6?

The official documentation does not say that Kimi K2.6 is the only replacement. The model list directs users to Kimi K3 for continued support and enhanced reasoning, while the K2.6 guide documents a separate general-purpose model with text, image and video input, thinking and non-thinking modes, dialogue, agent tasks and tool use.

Kimi K3 is Moonshot’s flagship model. Its guide describes a 1M-token context window, native visual understanding and long-horizon coding and knowledge-work capabilities. The guide says K3 access is available after a successful top-up with a minimum of $1, so account access is not the same as a universally free tier.

Kimi K2.6 remains relevant when a team specifically needs its documented multimodal and thinking-mode behaviour. It provides a 256K context window and supports text, image and video input. That does not make it a drop-in replacement for every K2 workload. Prompt formats, output quality, tool behaviour and account availability still need testing.

Our AI tool comparison work follows the same practical principle: compare a tool against the job, not against a marketing number copied from a launch page.

What is the current Kimi API endpoint?

Moonshot’s API overview documents the current service address as https://api.moonshot.ai. For the OpenAI SDK, set base_url to https://api.moonshot.ai/v1. Direct Chat Completions requests use https://api.moonshot.ai/v1/chat/completions.

The old article used https://api.kimi.com/v1 as the migration endpoint. That is not the base URL shown in the current official API overview. Updating the model name while leaving an unverified endpoint in production is not a migration plan.

The API is compatible with the OpenAI Chat Completions request and response format. That can reduce code changes, but “compatible” is not the same as “identical”. Kimi-specific extensions such as thinking and partial mode have their own documented request rules.

import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
completion = client.chat.completions.create(
model="kimi-k3",
messages=[
{"role": "user", "content": "Return one sentence about API migration."}
],
)
print(completion.choices[0].message.content)

The official quickstart also shows a cURL version of the same request. Keep the API key in an environment variable. Never place it in browser JavaScript, a public repository, a screenshot or application logs.

For a separate explanation of how AI products are changing developer workflows, see our interactive code-blocks and AI IDE guide. The security lesson is the same for every provider: credentials belong on the server side.

What changes in a Kimi migration?

The obvious code edit is the model identifier. The dangerous assumption is that the identifier is the only edit. A model sunset can affect context limits, tool calls, reasoning fields, vision payloads, token accounting, safety behaviour, rate limits and failure modes.

Do not compare models using one pleasant demo. Build a small evaluation set from your actual workload. Include long context, structured output, tool calls, refusals, malformed input, multilingual prompts and failure recovery. Record latency, output validity and cost per successful task.

For applications that use images or videos, confirm the input format. The K2.6 guide requires multimodal message content to be an array of content parts and documents base64 or file-upload approaches. A text-only migration test will not catch a broken vision path.

How should an API team migrate safely?

Start with an inventory. Search repositories, deployment manifests, secrets, prompt registries, scheduled jobs and third-party provider settings for kimi-k2, kimi-k2.5, api.kimi.com and older model aliases. A production system often has more than one route, especially when a framework or fallback provider stores its own model setting.

Next, create a non-production client using the current base URL and one candidate model. Keep the interface behind a configuration value rather than scattering a model string across application code. This makes rollback and side-by-side testing possible without another emergency patch.

1. Record the current K2 request shape, typical token usage, latency, output schema and tool behaviour.
2. Choose a candidate such as Kimi K3, Kimi K2.6 or Kimi K2.7 Code based on the workload, not the headline.
3. Update the base URL and model ID in a non-production environment.
4. Replay a representative evaluation set and compare correctness, latency, cost and failure modes.
5. Test authentication errors, rate limits, malformed requests, timeouts and fallback behaviour.
6. Canary a small share of production traffic and monitor before removing the legacy route.

The original “10-minute migration” promise was not retained because the time depends on the application. A simple chat wrapper may need a small configuration change. An agent with tools, vision inputs, structured outputs and strict cost limits may need a real compatibility project.

What does Kimi K3 cost and what should teams budget?

The official Kimi K3 pricing page lists $0.30 per 1M cache-hit input tokens, $3.00 per 1M cache-miss input tokens and $15.00 per 1M output tokens. It lists a 1,048,576-token context window and notes that prices exclude applicable taxes.

Those figures are K3 figures, not a replacement price table for Kimi K2. The old article’s comparison of $0.60 versus $0.95 input and $2.50 versus $4.00 output was removed because the current official model documentation does not present it as the relevant K2-to-K2.6 migration table.

Budget against successful work, not raw token price alone. A model with a higher output rate can still be cheaper if it needs fewer retries or produces valid structured responses more often. Conversely, a larger context window can increase spend when prompts are allowed to grow without a retrieval or truncation policy.

Read the AI workflow guide for a broader reminder about measuring real task cost. The same discipline applies to API migrations.

What should developers do if an old K2 request still works?

Treat a successful response as a temporary compatibility observation, not as a support commitment. The official model list says the K2 series is no longer maintained or supported. A request that works today can still fail after a routing change, account change, quota change or endpoint retirement.

Log the model ID and provider response metadata for controlled tests, but do not log the API key or sensitive prompt data. Keep a fallback decision ready, and document which target model passed the evaluation set. If the application cannot tolerate a model change, pin the tested configuration and monitor the provider’s model list and pricing pages.

Do not announce that Kimi K2.6 or Kimi K3 will preserve every benchmark, output style or tool-call pattern. The current docs establish model capabilities and API conventions, not a guarantee of application-level equivalence.

The practical takeaway

Kimi K2 was discontinued on May 25, 2026, and Moonshot’s current documentation says it is no longer maintained or supported. The official model list points users to Kimi K3 for continued support while keeping Kimi K2.6 and Kimi K2.7 Code available as distinct options.

Use the current endpoint https://api.moonshot.ai/v1, keep credentials server-side and test the target model against real prompts, tools, context lengths, costs and failure modes. Do not replace a model ID in production and call the job complete.

The old article’s shutdown date was right, but its K2.6-only migration story, copied pricing, benchmark promises and ten-minute estimate were not reliable enough to retain. Current provider documentation is the source of truth, and a small reproducible evaluation is the fastest way to find out whether a migration is actually safe.