Sarvam Kimi K3 Removed: How to Migrate to K3.1 Pro

Sarvam removed kimi-k3, mimo-v2.6-flash and mimo-v2.6-pro from Token Factory on November 6. Its Kimi replacement is kimi-k3.1-pro, but changing the model name alone may leave your application failing: K3.1 Pro requires Provisioned Throughput access enabled for your organization.

The awkward detail is the error message. A request without that access can still say “This model is currently in beta.” Before rewriting an SDK integration or repeatedly rotating keys, check whether the organization can use the model at all.

What changed in Token Factory

The November 6 changelog separates the catalog into Serverless and Provisioned Throughput models. The latter label replaces the earlier beta designation; Sarvam says the access process works as before. It also explicitly lists the three removed model IDs, so this should be treated as a migration rather than a temporary outage.

Search your application configuration for those IDs, including background jobs, evaluation scripts and fallback routes. Updating the main chat interface while leaving an overnight worker on the old model is an easy way to miss half the migration. Record which workflows depended on Kimi and which used MiMo before choosing replacements.

Fix the misleading beta error first

Sarvam's access documentation says that GET /v2/models can list a provisioned model even when the requesting organization cannot call it. Without access, a request returns 400 invalid_request_error with the beta message. The documented next step is to contact Sarvam with the model and expected usage volume.

A visible catalog entry does not prove that your API key has access. Treat model discovery and account authorization as separate checks. Keep the request ID and exact error when escalating the problem, rather than sending credentials or an entire production prompt.

Once access is confirmed, make a small text-only request using kimi-k3.1-pro. Keep the existing endpoint and SDK during this first check so you change one thing at a time. Sarvam supports the model on both /v2/chat/completions and /v2/responses; its OpenAI-compatible base URL is https://api.sarvam.ai/v2.

Check reasoning and request compatibility

The K3.1 Pro model reference documents always-on reasoning. Supported effort levels are low, high and max, with max as the default. Chat requests use reasoning_effort; Responses uses reasoning.effort. Reasoning consumes the output-token allowance, so a limit intended for a short visible answer can be too restrictive.

Make the effort setting explicit in your migration configuration. Then test whether the application correctly handles a response that spends part of its budget reasoning before producing an answer. Record the actual usage alongside answer quality instead of assuming the final text explains the whole bill.

If you use multimodal inputs, test them separately. The documentation describes video as a short-clip beta available through Chat Completion V2, not Responses, and rejects remote video URLs. Image support is not a reason to assume every existing video request will work unchanged.

Kimi K3.1 Pro pricing with a worked example

Sarvam's published prices exclude GST and charge reasoning as output. The current rates are:

Token category	Price per million tokens
Uncached input	₹250
Cached input	₹25
Output, including reasoning	₹1,350

Consider an illustrative workload of 100 requests, each using 10,000 uncached input tokens and 2,000 billed output tokens. That is one million input tokens costing ₹250, plus 200,000 output tokens costing ₹270: ₹520 before GST. This is arithmetic using the published rates, not a measured workload or a quote for provisioned capacity.

If billed output doubles while input stays unchanged, the same workload costs ₹790. That makes reasoning behavior worth measuring before rollout. Do not apply the cached-input rate to repeated prompts unless the service actually reports the relevant cached usage.

Choose a fallback before moving production traffic

For applications that need a self-serve route while access is being arranged, the changelog points to glm5.3-flash for the lowest per-token price. That is a candidate to evaluate, not evidence that it can replace Kimi or MiMo without affecting results.

Run representative requests through the proposed replacement and check answer correctness, structured output, tool arguments, latency and total billed usage. Keep external actions disabled during these comparisons, especially if the workflow normally sends messages or changes customer records.

A successful smoke test establishes connectivity. A successful migration also establishes that the application still does its job. Keep those decisions separate, and move traffic only when both have evidence behind them.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn API changes and product decisions into clear, useful content for developers.

Book a 30-minute call.