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

The replacement model needs organization-level access, and an old beta error can send developers looking for the wrong fix.

By Paras Madan | 2026-11-07


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](https://docs.sarvam.ai/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](https://docs.sarvam.ai/api/token-factory/models) 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](https://docs.sarvam.ai/api/token-factory/models/kimi-k3.1-pro) 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](https://docs.sarvam.ai/api/getting-started/pricing) 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](https://cal.com/paras-madan/30min).