Model Studio's legacy Qwen retirements: a replacement test plan

What the policy confirms, and what it leaves to the notices

Model Studio's decommissioning policy defines the mechanics, not the list. A retirement has three checkpoints: start of retirement, End of Marketing, and End of Service. For stable models, End of Marketing comes 7 days after the start and End of Service 3 months after it. For preview models, End of Service comes 14 days after the start¹. Stable models are the series name (such as qwen-plus), a dated version, and a -latest alias. All three count as stable¹.

The page lists a batch scheduled for deprecation on January 19, 2027 and another deprecated on October 10, 2026, and points to a separate announcement for each¹. The policy page itself names no ids, and it does not say which checkpoint those dates are. When this post was written, the linked notice pages returned no readable text. So get the id list from the announcements in your console and email, not from this article. Alibaba says it emails accounts that called a retiring model in the previous 3 months¹.

One timing detail matters for planning. From the start of retirement, new users lose access and the model's default QPM and TPM limits may be gradually reduced. Models with raised quotas first revert to the default limit¹. A model can therefore get slower to use before it stops. Do not wait for End of Service to start.

1. Build the inventory from what you actually call

• Open Model Monitoring in each region you use and list every model with calls in the last 90 days. The policy points to the Singapore and China (Beijing) monitoring pages for this check¹.
• Add what monitoring cannot see: scheduled jobs, notebooks, staging, and third-party tools holding your key.
• Record for each id: region, whether it is a series name, dated snapshot or -latest alias, request volume, and the owner.
• Compare against the announcement list. Anything called but not listed is either already retired or a different alias of a listed model.

Aliases need care. The pricing page shows qwen-plus as "currently equivalent to" qwen-plus-2025-12-01, and qwen3.7-max as equivalent to qwen3.7-max-2026-05-20². A bare series name can change which snapshot it points to. Code that sends an alias may be in scope of a retirement without naming a dated id. See model aliases vs pinned snapshots.

2. Map each retired id to a replacement

The replacement belongs in a mapping table that you fill from the notice, with Alibaba's current recommendations as candidates. At the time of reading, the recommended list names qwen3.8-max for complex reasoning and coding, qwen3.7-plus for balanced performance, speed and cost, and qwen3.8-flash for fast, cost-effective work. It also lists third-party text models such as deepseek-v4-pro-0813, deepseek-v4.1-flash, glm-5.3 and kimi-k3³.

Check thinking mode explicitly. Pricing for several current Qwen ids distinguishes non-thinking and thinking output, and for qwen-plus the two output rates differ². A replacement that thinks by default can change both latency and cost with no change in your code.

3. Check region and data location per id

Model Studio runs in six regions: China (Beijing), US (Virginia), Singapore, Japan (Tokyo), Germany (Frankfurt) and China (Hong Kong). Regions differ in endpoints and base URLs, API keys that are not interchangeable across regions, supported models, platform features and pricing⁴. The base URL includes your workspace ID and a region segment, for example ap-southeast-1 for Singapore or eu-central-1 for Frankfurt⁴.

• For every replacement, confirm in the console of each region you serve that the id is listed. Do not assume a model in Singapore exists in Frankfurt.
• Record the deployment scope in the pricing table. The same id appears under different scopes: qwen3.8-max is priced at $2 input and $6 output per million tokens under "International" in Singapore and under "US" in Virginia. It is $1.65 and $4.951 under "Global" in the other regions listed on the page².
• Write down what your contracts or privacy notices say about where prompts are processed. A change of scope can change that answer. Read what the page says about the scope, rather than inferring it from the region name.
• Verify third-party availability yourself. The product introduction says DeepSeek is available only in China (Beijing)⁴, while the recommended-models and release pages list DeepSeek ids with Singapore links³⁵. These pages disagree, so a console check settles it.

import os
from openai import OpenAI

# Pattern from Alibaba's docs: workspace id + region segment.
REGIONS = {
    "singapore": "ap-southeast-1",
    "beijing": "cn-beijing",
    "frankfurt": "eu-central-1",
}

def client(region: str) -> OpenAI:
    ws = os.environ["MODELSTUDIO_WORKSPACE_ID"]
    return OpenAI(
        api_key=os.environ[f"DASHSCOPE_API_KEY_{region.upper()}"],
        base_url=f"https://{ws}.{REGIONS[region]}.maas.aliyuncs.com/compatible-mode/v1",
    )

4. Build the regression set before you compare models

A regression set is frozen production behavior, replayed against old and new ids. Build it before looking at any candidate's scores.

• Sample real requests by task type, not at random: include the long-context ones, tool-calling turns, structured-output requests, non-English text, and known past failures.
• Freeze inputs, system prompts, tool schemas and sampling parameters. Pin dated snapshots on the candidate side.
• Define pass/fail per task type: schema validity, exact tool name and arguments, a rubric-graded answer, or a human label. Where you use an LLM judge, calibrate it first (calibrating graders against humans covers how).
• Run each case several times per model; record pass rate, p50 and p95 latency, output length, and retry count.
• Run the old id until its last day, so you have a same-day baseline.

Check the rate limits too. A replacement may have lower default RPM and TPM than the quota you raised on the old id, so replay at production concurrency, not one request at a time.

5. Price per successful task, not per token

List rates are the starting input. Each page here gives rates per million tokens, and some models use tiers where one request's total input tokens set the unit price for every token in that request². Cache-hit input tokens and explicit cache creation are billed at different unit prices (the page's example is 125% for creation and 10% for hits)². Batch calls on supporting models are billed at 50% of the real-time price, and the page says the batch rate and the context-cache rate cannot apply together².

Use your own contract rates where you have them. Then compute:

cost per successful task =
  (sum of billed cost for all attempts, including retries and failed schemas)
  / (number of tasks that passed the regression check)

Longer outputs and thinking tokens move this number more than the rate does. See cost per successful task for the full method.

6. Voice workloads: qwen-audio-3.1-realtime-flash

The release page dates qwen-audio-3.1-realtime-flash to 2026-10-27, with service scope "International"⁵. It is a real-time duplex speech model with text and audio input and output, function calling, web search and voice cloning. It speaks WebSocket, WebRTC and AOQ, and enable_thinking is not supported⁶. The recommended list groups it under speech-to-speech with qwen-audio-3.1-realtime-plus, qwen3.5-omni-plus and qwen3.8-omni-flash-realtime³. The release notes say the Plus model uses the same integration protocol as 3.0 Plus⁵. I found no equivalent statement for Flash, so test the protocol rather than assume it.

Billing detail to test: text-only responses are billed at the text output rate, but for responses that carry both text and audio, only the audio output is billed⁶. Voice cost is therefore tokens, not minutes. Measure tokens per call from real sessions and compute cost per completed conversation (resolved, no handoff, no dropped call).

Voice checklist:

• Context limits: 262,144-token window, 50 turns, and 300 seconds of cumulative audio⁶. Replay your longest real calls to find where a session breaks.
• Capacity: the default is 60 RPM and 100,000 TPM, and WebSocket RPM counts connection requests, with no separate concurrent-connection limit⁶. Load-test against reconnect storms.
• Turn detection: the page lists server_vad, smart_turn, smart_turn_v2 (recommended) and push-to-talk. Test interruption and barge-in under each mode on noisy audio.
• Tool calls: replay your function-calling cases with audio input. Web search is enabled with enable_search and can be combined with function calling⁶, so check that it is off where you do not want live search.
• Voice identity: the default voice is longanqian_v3.1⁶. If you cloned or picked a voice on the retired model, confirm it exists or re-record it.

For a wider voice comparison, see voice agent APIs compared.

7. Cut over and keep a way back

• Ship behind a flag: 5% of traffic, with the old id still live, then step up.
• Compare pass rate, latency and billed cost per success on live traffic against the regression results.
• Keep the retired id in config until End of Service, then delete it, so no code path can call it.
• Re-check the announcement for Change notes before each step.

A gateway can help with the mechanics here. INFRO records vendors' deprecation and shutdown dates, warns organizations still sending a retiring model, and refuses it from the shutdown date, naming the replacement. Its console shows deprecation notices with what in your organization still uses the model. Per-request usage, custom rates and cost estimates support the cost-per-success arithmetic, and routes can split traffic by weight. Which providers it covers is listed in the INFRO docs (opens in a new tab) and at /providers, so check there for Model Studio before you rely on it. The documented endpoints (chat, speech, transcription and others) include no realtime duplex socket⁷, so run the voice track directly against Model Studio. For the general method, see the model deprecation playbook.