# Nebius Model Shutdowns: Migrate Token Factory Calls After November 9

Eleven Serverless model IDs are being retired, and changing the name in your request is only the first migration check.

By Paras Madan | 2026-11-09

Nebius scheduled eleven Token Factory Serverless model IDs for removal on November 9, 2026. Requests are not automatically redirected to replacements. If your integration uses an affected ID, update its routing and test the new model before restoring traffic. Dedicated Endpoints are outside this retirement.

The immediate question is which string to change. The more consequential question is whether the replacement still satisfies the application contract. A request that returns successfully can still break a document extractor, a tool-using agent or a vision workflow.

## Which Nebius model IDs are affected?

The [official November deprecation notice](https://docs.tokenfactory.nebius.com/model-deprecations-november-2026) lists these migrations. These are provider recommendations, not claims of identical behavior or cost.

| Retiring Serverless model ID | Recommended replacement |
| --- | --- |
| `zai-org/GLM-5.1` | `zai-org/GLM-5.3` |
| `nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B` | `nvidia/Nemotron-3_5-Lightning` |
| `nvidia/nemotron-3-super-120b-a12b` | `nvidia/Nemotron-3.5-Super-VL` |
| `deepseek-ai/DeepSeek-V4-Pro` | `deepseek-ai/DeepSeek-V4-Pro-0813` |
| `deepseek-ai/DeepSeek-V4-Flash-0731` | `deepseek-ai/DeepSeek-V4.1-Flash-1017` |
| `deepseek-ai/DeepSeek-V4.1-Flash` | `deepseek-ai/DeepSeek-V4.1-Flash-1017` |
| `Qwen/Qwen3.5-397B-A17B` | `Qwen/Qwen3.8-27B` |
| `Qwen/Qwen3-235B-A22B-Instruct-2507` | `Qwen/Qwen3-30B-A3B-Instruct-2507` |
| `moonshotai/Kimi-K2.6` | `moonshotai/Kimi-K3` |
| `moonshotai/Kimi-K2.7-Code` | `moonshotai/Kimi-K3` |
| `openbmb/MiniCPM-V-4_5` | `nvidia/Nemotron-3.5-Super-VL` |

Notice that some replacements cross model families or change model size substantially. Treat those rows as candidate selections for evaluation, rather than mechanical version upgrades. This guide follows the published retirement schedule; it does not claim to have tested an authenticated request against every retired endpoint.

## Find the ID actually reaching the provider

Start with a failed request's resolved provider, model and destination host. A friendly name such as “fast” in your app may hide a different model string in a gateway, background worker or environment variable. Inspect metadata without copying API keys or customer prompts into debugging tools.

Search application configuration, deployment variables, agent definitions and fallback routes for the exact retired strings. Include scheduled jobs and evaluation scripts. Fixing the interactive chat route while leaving a nightly worker untouched creates an intermittent failure that looks unrelated to the migration.

Do not diagnose every unsuccessful request as retirement. Authentication, quota, request formatting and transport problems need their own checks. The notice does not specify a universal HTTP status or error message, so use the response body and request configuration rather than an assumed error code.

## Change the model, then run a small smoke test

The [Token Factory quickstart](https://docs.tokenfactory.nebius.com/quickstart) uses the OpenAI client with the following base URL. This illustrative request substitutes the recommended DeepSeek Flash replacement; it is a starting point, not a reported test result.

```python
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.tokenfactory.nebius.com/v1/",
    api_key=os.environ["NEBIUS_API_KEY"],
)

response = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-V4.1-Flash-1017",
    messages=[{
        "role": "user",
        "content": "Reply with the single word ready."
    }],
    max_tokens=32,
)
print(response.choices[0].message.content)
```

Use your existing authorized key, keep it outside source code and remember that an API test can incur usage charges. If your application intentionally goes through a gateway, update that gateway's upstream mapping instead of bypassing it just to match this example.

A successful smoke test establishes that the basic request path works. It tells you almost nothing about production accuracy. Keep that distinction visible in the migration ticket: “endpoint responds” and “application passes evaluation” should be separate checks.

## Test the contract your application depends on

For a document extractor, prepare a small representative set with expected fields and deliberately awkward cases: missing values, contradictory dates and a long document. Check parsed values as well as parse success. Valid JSON containing the wrong amount is still a failed extraction.

Nebius's [structured-output documentation](https://docs.tokenfactory.nebius.com/ai-models-inference/json) distinguishes arbitrary JSON objects from schema-constrained output and directs users to model cards for JSON-mode support. Verify the replacement supports the format you send, then run your own schema validation. Do not infer support from the presence of an OpenAI-compatible endpoint.

For an agent, keep external actions mocked during evaluation. Check whether it selects the correct tool, supplies valid arguments and handles the returned result. Nebius's [function-calling guide](https://docs.tokenfactory.nebius.com/ai-models-inference/function-calling) makes the execution boundary clear: the model proposes calls; your application executes them. A migration test should not accidentally send an email or change a customer record.

For a vision workflow, replay representative image inputs rather than testing with text alone. Compare output quality, input acceptance, latency and token usage under the same workload. Record the current price of the replacement separately; a newer model name is not evidence that your per-task cost decreases.

## Roll forward without hiding a regression

Once the candidate passes your acceptance checks, direct a small portion of traffic to it and watch failed requests, validation failures and task completion. Keep routing changes separate from unrelated prompt rewrites so you can identify which change caused a regression.

**A retired model is not a usable rollback plan.** Prepare another available, evaluated route or a controlled failure mode, such as queueing work for review. Automatically switching to any model that responds can conceal a quality problem behind an apparently healthy service.

For teams requiring tighter control over model lifetimes, a dedicated deployment is worth evaluating separately. It is an infrastructure and capacity decision, not an emergency promise of compatibility.

The useful lesson from this retirement is to make model lifecycle checks part of application maintenance. Keep an inventory of the exact provider IDs your product depends on, with an owner and a tested alternative. That turns the next shutdown into a configuration change you planned for instead of an incident you discover through customers.

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

I help technical teams turn API changes, migration lessons and product decisions into clear content developers can use.

[Book a 30-minute call](https://cal.com/paras-madan/30min).