Check the model behind your app
If an app you run calls a Kimi K2 model, check its replacement plan. Kimi’s current official model list and pricing pages say it plans to retire all K2-series API models by the end of December 2026. [1][2]
An API is the software connection an app uses to ask a model for help. A script might use it to draft delivery updates or summarize support tickets. When the model it requests is retired, that job can fail until the connection is updated.
Two dates mean different things
The notice says K2-series models stopped being available to newly registered users from October 31. Existing users are unaffected by that restriction. That does not promise indefinite access: the same notice sets out the later retirement plan. [1][2]
Neither page gives an exact retirement day. We checked the documentation on November 3; this is catch-up coverage of the stated plan, with no verified first-publication hour. [1][2]
Keep API access separate from subscriptions
This notice concerns API models. The pricing page says API usage is billed by use, separate from Kimi membership and Kimi Code. Check the product and model identifier your own software uses before deciding what needs to change. [1]
Our take
Start with a small inventory: which jobs call K2, who maintains them, and what happens if they stop? Ask the maintainer to identify the model setting before changing it. The model’s name on a chat screen is not a substitute for checking an app’s configuration.
Try a replacement on a known, non-sensitive job with an expected result. For a delivery-update script, use a fictional order. Compare factual accuracy, response format, any required tool actions, and the bill. A successful reply alone does not show that the whole workflow still works.
Record the result and decide who will pause or repair the job if it fails. Plan the migration before the stated retirement window ends. We reviewed the documentation; we have not tested an API or migrated an application.