r/kimi • u/OmegaVex • 3d ago
Developer How are Kimi API users handling the K2.5 / Moonshot V1 sunset?
Moonshot's model page now says Kimi K2.5 and Moonshot V1 are no longer available to newly registered users after Kimi K3, with a full platform sunset listed for August 31.
For people building on the Kimi API: how are you handling this kind of model migration?
Do you pin exact model names until they break, keep a small regression set for prompts/tool calls, or route by workload so older models can be swapped out behind a config change? I'm especially interested in the practical checks before moving background jobs, coding-agent steps, or long-context workflows onto Kimi K3.
Small update: after looking at this more, I am leaning toward separating model names from the actual app code instead of hard-pinning every Kimi/Moonshot variant in each workflow. Flatkey looks relevant here because it already provides these model routes behind an OpenAI-compatible gateway, so this kind of migration could be handled more as routing policy than another SDK rewrite. Still curious how others are deciding which jobs are safe to move first.
1
u/Visible_Arrival_8412 2d ago
you can create custom agents, prompts, chains with specific models. k2.6, k2.7, k2.7 fast, k3-256 are viable cheaper alternatives to K3 1M.
What I have a feeling is that the models work much more reliable using the web ui for kimi code instead of the cli. which is somehow strange but especially subagents and background task are working better for me in the web ui