DashScope OpenAI Responses API — compatible-mode/v1 Now Supports Qwen with Stateful Context and Built-in Tools

The routing decision this changes is not which model to use — it is which API surface to build on. Alibaba Cloud Model Studio (DashScope) has published official support for the OpenAI Responses API, meaning teams that have already adopted client.responses.create() can now point the same SDK at Qwen models by changing only the base_url and API key.

What happened

Alibaba Cloud's Model Studio documentation now includes a full guide for calling Qwen models via the OpenAI Responses API — the stateful, agent-native successor to Chat Completions that OpenAI introduced in early 2025. The supported model list covers the current recommended tier: qwen3.7-max, qwen3.6-plus, qwen3.6-flash, qwen3.5-plus, qwen3.5-flash, qwen3-coder-plus, qwen3-coder-flash, and several open-weight variants.

The endpoint is live across four regions:

• Beijing (China): https://dashscope.aliyuncs.com/compatible-mode/v1
• Singapore: https://dashscope-intl.aliyuncs.com/compatible-mode/v1
• US (Virginia): https://dashscope-us.aliyuncs.com/compatible-mode/v1
• Frankfurt: https://{WorkspaceId}.eu-central-1.maas.aliyuncs.com/compatible-mode/v1

DashScope also issued a deprecation notice: the old URL path /api/v2/apps/protocols/compatible-mode/v1/responses is being retired. Teams using that path must migrate to /compatible-mode/v1/responses.

Why it matters for AI engineering teams

The OpenAI Responses API differs from Chat Completions in three ways that matter operationally:

Stateful context via previous_response_id. Instead of reconstructing the full message history on every turn, you pass the ID of the previous response. DashScope stores context server-side for seven days. This changes how you think about token accounting: the input token count for turn N includes the accumulated context from prior turns, but you do not pay to re-transmit it. For long-running agent sessions, this can meaningfully reduce per-request payload size.

Built-in tools without custom function definitions. The Responses API on DashScope exposes web search, web scraping, code interpreter, image search, and image similarity as first-class tools — no function schema required. For teams building research or coding agents, this removes a layer of prompt engineering and tool-call plumbing.

reasoning.effort for thinking control. Where Chat Completions uses the non-standard enable_thinking parameter (passed via extra_body), the Responses API uses reasoning.effort with values none, minimal, and higher levels. This is a cleaner interface for controlling thinking depth per request, and it aligns with how OpenAI's own reasoning models expose the same knob.

The practical implication: if your team has standardized on the Responses API for OpenAI workloads, you can now add Qwen as a routing target without maintaining a separate code path for Chat Completions.

The router/operator angle

Provider dependency and fallback. The Responses API surface on DashScope is not yet at full parity with OpenAI's implementation. Notably, qwen3.6-max-preview and deepseek-v4-pro are not in the Responses API supported model list — they are Chat Completions only. If your routing policy selects models dynamically, you need to track which models support which API surface, not just which provider supports which model.

Stateful context creates new failure modes. When previous_response_id is used, a failed or expired response breaks the conversation chain. The seven-day TTL means long-running agent workflows that pause for more than a week will lose context silently. Operators building multi-day agent loops need explicit checkpointing logic, not just retry-on-failure.

Region selection affects both latency and data residency. The four DashScope Responses API regions are not equivalent: the Beijing endpoint serves China-region traffic; Singapore and US serve international workloads. For teams with data residency requirements, the Frankfurt endpoint requires a Workspace ID in the URL — a different auth pattern than the other three regions. Routing policies that treat all four endpoints as interchangeable will hit auth errors on Frankfurt requests.

Billing surface changes. DashScope's response object includes an x_details array with x_billing_type: "response_api" — a separate billing category from Chat Completions. If your cost reconciliation pipeline parses usage objects, it needs to handle this new field. Reasoning tokens are reported under output_tokens_details.reasoning_tokens, consistent with OpenAI's format.

Old URL path deprecation. Any proxy or gateway that hardcodes /api/v2/apps/protocols/compatible-mode/v1/responses will break when DashScope retires that path. Audit your base URL configurations now.

What TheRouter users should watch or try

If you are routing OpenAI Responses API traffic through TheRouter to OpenAI today, the architecture question is whether to add DashScope as a fallback or cost-optimization target for the same Responses API surface. The key check: confirm that your routing layer passes previous_response_id through to the upstream provider without stripping it — stateful context only works if the session ID reaches DashScope intact.

For teams not yet on the Responses API, this is a reasonable moment to evaluate the migration. The Chat Completions API remains fully supported on DashScope, but the Responses API's built-in tools and stateful context reduce boilerplate for agent workflows. The migration guide in the DashScope docs includes a side-by-side comparison of Chat Completions and Responses API request formats.

Watch for: DashScope expanding the Responses API supported model list to include qwen3.6-max-preview and the DeepSeek V4 family, which are currently Chat Completions only.