Mistral lists October 31, 2026, as the retirement date for its hosted Z.ai GLM 5.2 model, zai-glm-5-2. Its recommended replacement is zai-glm-5-3, available at the same listed price. Applications pinned to the older identifier should treat the retirement as an immediate compatibility risk. Mistral’s changelog directs developers to switch models; it does not promise automatic migration.
The configuration change is small. The production decision takes more work: developers need to establish whether GLM 5.3 preserves the outputs, tool behavior, and operating costs their applications depend on. The most useful distinction is between changing the model selector and validating the replacement. Completing the first does not complete the second.
The Retirement Follows a September Deprecation Notice
Mistral’s documentation records three separate events:
- September 28, 2026: GLM 5.3 became generally available.
- September 29, 2026: Mistral announced GLM 5.2’s deprecation and named GLM 5.3 as its replacement.
- October 31, 2026: GLM 5.2 reaches its retirement date.
Those dates appear in the changelog, while the models overview also lists October 31 as GLM 5.2’s retirement date. This is the cutoff associated with an earlier notice, not a new GLM 5.3 launch.
Mistral specifies a date without a cutoff hour or time zone. Developers should not assume midnight UTC, or count on availability through the end of their local day. The cited notice also does not specify the exact error response retired-model requests will return.
The notice concerns Mistral’s hosted model ID. It says nothing about GLM 5.2 availability through other providers or independently hosted deployments.
What Stays the Same, and What Needs Verification
Mistral describes both versions as third-party text models from Z.ai with a 1 million-token context window. Its older GLM 5.2 model card says that version was served without Mistral modifications and lists a maximum output of 128,000 tokens.
The published evidence supports the following comparison:
| Property | Hosted GLM 5.2 | Recommended GLM 5.3 |
|---|---|---|
| Model ID | zai-glm-5-2 | zai-glm-5-3 |
| Model type | Third-party Z.ai text model | Third-party Z.ai text model |
| Context window | 1 million tokens | 1 million tokens |
| Listed price relationship | Previous model’s pricing | Same price, according to Mistral |
| Maximum output | 128,000 tokens | Not specified in the cited overview |
| Lifecycle position | Retirement dated October 31 | Recommended replacement |
Sources: GLM 5.2 model card, models overview, and changelog.
GLM 5.2’s card also lists chat completions, function calling, structured outputs, predicted outputs, prefix support, and batching. These are useful categories for a migration checklist. The cited pages do not provide a corresponding feature-by-feature GLM 5.3 specification, so they should not be treated as proof that every option carries over unchanged.
The shared context size is meaningful for applications that submit large documents or codebases. It does not establish equal retrieval accuracy, output length, latency, or instruction-following behavior. Context capacity tells you how much material a model can accommodate, not how reliably it will use every part.
Change the Model ID Wherever Requests Originate
For an integration that selects its model through a model field, the documented replacement is:
- "model": "zai-glm-5-2"
+ "model": "zai-glm-5-3"
This fragment illustrates the identifier change inside an existing request or configuration. It is not a complete API request, and it does not verify the rest of the payload.
Search beyond the main application configuration. Model IDs can also live in:
- Environment variables and deployment secrets.
- API gateway routing rules and model allowlists.
- Background workers, scheduled jobs, and batch-generation code.
- Retry handlers, fallback routes, and evaluation scripts.
A foreground chat route can migrate successfully while an overnight worker continues submitting the retired identifier. Logging the effective model ID at the request boundary is a useful way to catch that split.
Keep unrelated prompt and parameter changes out of the first migration pass where possible. My preference would be to change the model selector first: if output quality shifts, that gives the investigation fewer moving parts.
Do not rely on a silent alias from the old ID. Mistral explicitly names a replacement ID, which makes an intentional configuration update the sensible path.
Build Regression Tests Around Application Contracts
Use representative production inputs with sensitive information removed. If GLM 5.2 is already unavailable, compare GLM 5.3 with retained outputs, previous evaluation results, or task-level acceptance criteria. A live side-by-side comparison should not be a prerequisite for recovering service.
Tool Calls and Agent Workflows
For applications using function calling, check tool selection, argument validity, and completion of the full workflow.
A syntactically valid tool call can still be wrong: the model might select the wrong function, omit a required argument, or repeat a call after receiving a usable result. Multi-step tests should therefore score whether the intended task finishes, how many tool calls it takes, and whether the agent stops at the right point.
Use sandboxed or read-only tools for replay tests. A migration evaluation should not accidentally send customer messages or modify production records.
Structured Outputs and Downstream Parsing
Run responses through the actual parser and validator used by the application. Check required fields, field types, enum values, and any assumptions about surrounding text.
JSON validity is only the first gate. A response can parse successfully while carrying a value that breaks business logic. Include sparse inputs, ambiguous requests, and error cases alongside ordinary examples.
If existing code depends on particular wording in an otherwise free-form response, this is a good point to identify that dependency explicitly.
Long-Context Tasks and Output Limits
Test examples near the context sizes the application actually uses, including important information placed early, midway through, and late in the input.
For document question answering, verify that answers use the relevant passage. For code work, check whether edits respect instructions distributed across multiple files.
Also test truncation and large-output handling. GLM 5.2’s documented 128,000-token output ceiling should not be copied into a GLM 5.3 capacity assumption without verification.
Optional Features and Delivery Behavior
Applications using predicted outputs, prefix support, or batching should exercise those paths separately. Successful basic chat responses do not validate them.
If the application streams responses, test partial-output handling, interrupted requests, and completion detection. For batch workloads, check result-to-request matching and partial failures. These tests target the application’s integration behavior; they are not claims that Mistral has changed any particular interface.
Frequently Asked Questions
3 questions
1When Does Mistral Retire GLM 5.2?
Mistral lists October 31, 2026, as the retirement date for zai-glm-5-2. Its notice does not specify an exact cutoff time or time zone.
