Qwen's Deprecation Cadence on Alibaba Cloud's Hosted API

A Qwen model on Alibaba Cloud Model Studio can be addressed by three different names, and they make three different promises. Two of them will change what they point at without telling your code. Knowing which is which is most of what deprecation planning on DashScope amounts to.

Three names for one model

Model Studio — the service whose API is still widely called DashScope, after the endpoint hostname — publishes each commercial Qwen model under a family of identifiers. Using qwen-max as the example:

• The stable name, qwen-max. This is an alias. It points at a specific snapshot, and Alibaba Cloud repoints it to a newer snapshot periodically, on a documented lag behind the newest release. Your code keeps working; the weights behind it do not stay the same.
• The latest name, qwen-max-latest. Also an alias, repointed as soon as a new snapshot exists. This is the one to use when you want new capabilities immediately and have accepted that behaviour can change on any request.
• The dated snapshot, of the form qwen-max-2025-01-25. A specific set of weights. It does not change. It is instead the only one of the three that can be withdrawn, and that withdrawal is what a deprecation notice is about.

The same triple exists for qwen-plus, qwen-turbo and the vision and audio families. Open-weight Qwen checkpoints served through Model Studio use their upstream names — qwen3-30b-a3b and similar — and are versioned by the checkpoint, not by a date suffix.

The naming is identical whether you call the native DashScope API or the OpenAI-compatible endpoint, because both front the same catalogue. What is not identical is the region. Model Studio is deployed separately for mainland China and for the international regions, with different hostnames, different keys and different model lists. A model identifier is scoped to a region: it can exist in one and never have existed in the other, and it can be retired in one while remaining available in the other. Any statement of the form “Qwen retired X” is incomplete without the region it applies to.

Which of them can change under you

This is the trade the naming scheme is asking you to make, and it has no free option:

qwen-max              stable weights? no    can be withdrawn? no
qwen-max-latest       stable weights? no    can be withdrawn? no
qwen-max-2025-01-25   stable weights? yes   can be withdrawn? yes

An alias never 404s, which is why it is tempting for production, but an alias is also how a prompt that has been carefully tuned against one snapshot starts producing subtly different output on a Tuesday with no deployment on your side. A pinned snapshot cannot do that, and in exchange it is the thing that eventually gets a retirement date. If you have an evaluation suite, pin; if you do not, an alias is at least honest about the fact that you are not checking. Pinning a Qwen checkpoint walks through both sides of that, including the Hugging Face half for open weights.

What a retirement notice contains

Alibaba Cloud publishes model lifecycle changes as dated announcements in the Model Studio documentation rather than as an API field. A notice names the model identifiers affected, the date the endpoint stops accepting requests, and the model the notice recommends moving to. Older snapshots of a family are withdrawn before the family alias is, and a family is only retired when a successor family exists.

Two structural points about the notices are stable enough to rely on. They are published ahead of the effective date rather than at it, so there is a window; and they are published per region, because Model Studio is deployed separately in the China and international regions and a model available in one may never have existed in the other. A notice that does not apply to your endpoint hostname does not apply to you.

How a retirement reaches your code

If you miss the window, the failure is a request-time error rather than a silent fallback. Through the OpenAI-compatible endpoint it arrives as an HTTP 400 with a model-not-found style code; through the native DashScope endpoint it arrives as a 400 with InvalidParameter and a message naming the model. Either way the shape is the same:

{
  "error": {
    "code": "InvalidParameter",
    "message": "Model not exist.",
    "request_id": "b1f0c9a2-..."
  }
}

The thing to notice is what does not happen: there is no automatic substitution to a successor model. An unrecognised model name is a hard failure, which is the correct behaviour — a silent substitution would change your output quality without changing your logs — but it means the retirement lands on your users rather than on your dashboard unless you were already watching.

The other failure mode is quieter and has no error at all. When a stable alias is repointed to a newer snapshot, every request keeps returning 200 and the output distribution changes. Prompts tuned against the previous snapshot may hold, may improve, or may regress on the one case you care about; parameters that were valid may now be rejected or newly supported; the output ceiling may have moved. None of this appears in your metrics unless you were already measuring output quality, which is the argument for pinning even if you intend to follow every release.

Reading the notice before the traffic does

• Keep the model identifier in one place. A string literal repeated across nine call sites is nine things to find on the morning of a retirement. One constant, or one environment variable, turns the migration into a one-line change you can roll back.
• Log the identifier you sent, not the family. “We use qwen-plus” is not a fact you can act on when the notice names qwen-plus-2025-01-25.
• Have a fallback path that is already exercised. A second model configured but never called is not a fallback; it is an untested code path that will be discovered during an incident. Route a small fraction of traffic to it so the first request is not during the outage.
• Treat the notice date as the deadline for your evaluation, not for your deployment. Moving from one snapshot to the next changes output; that is the whole point of a new snapshot. The work is re-checking your prompts, and it is not five minutes.
• Check the region on every notice before acting on it. A retirement announced for the China-region service says nothing about the international one, and reacting to the wrong notice means an unnecessary migration and a real one still pending.
• Keep the open-weight option in the plan. The Qwen checkpoints published under Apache 2.0 cannot be withdrawn from you once downloaded, which makes them a genuinely different kind of dependency from a hosted endpoint. That does not make them the right answer, but it is the reason a hosted-only architecture and a mixed one have different risk profiles.