Kimi K2 Turbo Preview Is Offline: Migration to Kimi K3

Kimi K2 Turbo Preview was introduced as a faster version of Kimi K2. Early announcements described major output-speed improvements while keeping the K2 model family’s general characteristics. Later updates increased reported throughput and context capacity. The preview name signaled a changing product, and pricing promotions and performance figures were tied to specific dates.

Historical articles remain useful for understanding old configuration, invoices, or search results, but they should not be read as current availability. Preview documentation can also remain indexed after an endpoint changes. The authoritative source for a production integration is the current model list and live API behavior.

Kimi’s official model documentation now lists kimi-k2-turbo-preview as offline and states that the K2 series was retired from ongoing API support. It recommends moving to a current model such as kimi-k3. A retired model identifier should not be offered in a new selector or used as a fallback without an explicit tested compatibility service.

If an old request still appears to work through a gateway, determine whether the gateway is aliasing the name to another model. Silent aliases can change output, limits, and cost while preserving the string in client configuration. Ask the provider for the resolved model and migration policy.

Search application code, environment configuration, dashboards, deployment variables, examples, tests, saved presets, database records, and customer documentation for the old model ID. Include observability rules and cost calculators that may encode K2 Turbo prices or its 256K-era context. Record every caller and owner before changing production.

Capture a baseline from representative historical requests where policy permits. Record response quality, schema compliance, tool calls, latency, token usage, and errors. These samples form a migration set. Do not rely on unit tests that only assert a 200 response; model migrations change probabilistic behavior.

Kimi K3 adds a larger maximum context, native vision, and explicit reasoning-effort behavior, but a new model is not a drop-in guarantee for every prompt. Check accepted parameters, temperature behavior, output limits, tool schemas, structured output, streaming chunks, usage fields, and error responses. Remove settings that are unsupported rather than assuming they will be ignored.

Prompts optimized for a non-reasoning or earlier model may produce excessive analysis, different formatting, or changed tool decisions on K3. Test low, high, and max effort where available. Recalculate budgets using current input, cached-input, and output rules instead of carrying forward K2 Turbo promotional prices.

Add K3 behind a configurable model setting rather than replacing the old string everywhere at once. Run offline comparisons, then shadow eligible production requests without using the shadow output. Review quality and cost. Move a small traffic segment, monitor errors and user outcomes, and retain a supported rollback model during the observation period.

For structured workflows, validate schemas and tool calls automatically. For coding and research, use expert review on sampled outputs. Update rate limits, timeouts, context budgets, and dashboards before expanding traffic. A successful migration is an application change, not merely a renamed environment variable.

Remove K2 Turbo Preview from product selectors and current setup guides. Keep one dated legacy page so users encountering the old keyword understand its status. Mark historical speed and price figures as historical, link to the official retirement notice, and direct readers to the supported model guide.

State the exact date your application stopped accepting the old ID and whether an alias exists. Update code samples, API references, changelogs, support macros, and status pages together. Clear communication prevents developers from debugging an identifier that the underlying provider no longer supports.

Monitor traffic and error logs after the documentation change. Requests using the retired name can reveal an old mobile release, scheduled job, copied customer example, or third-party integration that the initial inventory missed. Return an actionable error with a link to the migration guide rather than a vague model-not-found message where you control the gateway. Set a clear end date for temporary aliases and avoid keeping an untested compatibility path indefinitely. Notify active integrators before that deadline and confirm that usage reaches zero before removing the final compatibility rule.