Intelligent Routing

Intelligent Routing dynamically analyzes request content and automatically matches the most suitable model from the candidate set, helping enterprises achieve optimal AI resource allocation in complex scenarios.

Overview

The model-code has a fixed auto-model prefix followed by 8 random characters (e.g., auto-model-abcd1234). The client calls this model-code → routing dynamically analyzes request content and matches the most suitable model from the candidate set → actual model infers → response (x-dashscope-resolved-model marks actual model, retains real token usage).

Scope:

Key advantages:

• Maximize model effectiveness: Automatically matches the optimal model for each task, ideal for users with extreme quality requirements.
• Precise cost reduction: Routes simple tasks to lightweight models and complex tasks to high-end models, avoiding over-provisioning and achieving precise cost-demand alignment.
• Eliminate model selection difficulty: No need for manual model evaluation or comparison; the platform auto-selects the optimal solution, drastically lowering the model selection barrier.
• Minimal learning curve: Consistent with regular model access; call via model-code with zero code changes.

Create intelligent routing

In the Bailian console under "Model Inference > Dedicated Deployment", click Deploy New Model to enter the creation page, and select Intelligent Routing under "Deployment Mode".

Prerequisites

• A Bailian workspace is activated.
• The target route model version is published, and the current account has invocation permission for the version and candidate models.

Steps

1. Enter a Service Name (required, up to 50 characters).
2. Under Deployment Mode, select "Intelligent Routing".
3. In Route Model Version, select a published version (maintained by the platform).
4. Under Routing Strategy, select "Effect First" or "Cost First".
5. Under Candidate Model Set, select candidate models (at least 2).
6. Click Confirm Deploy to complete creation.

After deployment, the system generates a globally unique model-code (in the form auto-model-XXXXXXXX). The model-code is not reused after deletion.

Routing strategy

The routing strategy determines which model in the candidate set executes each request. Both strategies dynamically match by request content (not fixed routing); the choice is made at creation.

Candidate model configuration

The candidate model set is the range the routing service can choose from. When creating intelligent routing, select the models to participate in routing from the candidate list in the Candidate Model Set area—at least 2 candidate models are required, otherwise deployment is blocked.

Route model version is the standardized release form of intelligent routing capability; each version specifies the model range and core capabilities supported by the routing system for that stage. The candidate list is determined by the selected route model version—each version corresponds to one candidate set; cross-version combination is not allowed. The currently published route model version and candidate models:

Price unit: CNY per million tokens. The deepseek-v4 series uses busy/idle time-based pricing; the table shows busy-time prices. All candidate models support thinking mode; thinking tokens are billed at output price.

Invoke intelligent routing

Once created, calling intelligent routing is the same as calling a regular model—just replace the model parameter in the request with the router's model-code (e.g., auto-model-abcd1234); the client can integrate with zero code changes.

Example call:

curl -X POST https://{WorkspaceId}.cn-beijing.maas.aliyuncs.com/compatible-mode/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto-model-abcd1234",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_DASHSCOPE_API_KEY",
    base_url="https://{WorkspaceId}.cn-beijing.maas.aliyuncs.com/compatible-mode/v1",
)
resp = client.chat.completions.create(
    model="auto-model-abcd1234",
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)
print(resp.model)  # the actual executing model name

# DashScope SDK (install first: pip install dashscope)
# Intelligent routing only supports maas.aliyuncs.com; configure DASHSCOPE_HTTP_BASE_URL
import os
os.environ['DASHSCOPE_HTTP_BASE_URL'] = 'https://{WorkspaceId}.cn-beijing.maas.aliyuncs.com/api/v1'
from dashscope import Generation

resp = Generation.call(
    model="auto-model-abcd1234",
    api_key="YOUR_DASHSCOPE_API_KEY",
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.output.choices[0].message.content)

// OpenAI SDK (install first: npm install openai)

const OpenAI = require("openai");

const client = new OpenAI({
  apiKey: process.env.DASHSCOPE_API_KEY,
  baseURL: "https://{WorkspaceId}.cn-beijing.maas.aliyuncs.com/compatible-mode/v1",
});
const resp = await client.chat.completions.create({
  model: "auto-model-abcd1234",
  messages: [{ role: "user", content: "Hello" }],
});
console.log(resp.choices[0].message.content);
console.log(resp.model); // the actual executing model name

Response: the x-dashscope-resolved-model response header holds the actually-called model's identifier (use it to verify routing took effect); the body retains the actual executing model name and real token usage, and billing is by the actually-routed model.

Billing: Billed by the actual model each request is routed to; the intelligent routing service itself is free.

Auto-failover

Intelligent Routing has a built-in auto-failover, enabled by default with no configuration. When the target model is unavailable, the routing service reissues the whole request with another candidate model, not switching mid-inference.

The following do NOT trigger auto-failover; errors pass through with the actual model's original error info:

• 429 (rate limit)
• 400/403/404/500 and other deterministic errors (switching models would likely fail too)
• Timeout or network errors
• Errors after streaming has started returning content

Real-time filtering rules

The routing service applies real-time filtering to the candidate set:

• Filters out models the current account has no permission to call.
• Filters out models that are offline.
• Filters out models incompatible with the current request's parameters (e.g., if the request carries response_format, only candidate models supporting that parameter are routed to).

The actually-selectable subset for a single request changes dynamically with permissions, model state, and request parameters.

Usage limits

Protocol support:

Parameter notes

• response_format: Routes only to candidate models supporting this parameter.
• enable_search: Routes only to candidate models supporting this parameter .
• reasoning_effort: Routes only to candidate models supporting this parameter by default; supported enum values: none, minimal, low, medium, high, xhigh, max.
• enable_thinking: Set to false to disable thinking, preferring non-thinking models; set to true to automatically exclude non-thinking models and enable thinking.
• max_tokens: When set, it is automatically converted to the max_completion_tokens parameter and passed to candidate models; routing only selects candidate models that support the max_completion_tokens parameter.

In intelligent routing mode, the following parameters are not supported; setting them causes a runtime error:

Cache

Intelligent routing does not support explicit cache parameters:

• If the request carries an explicit cache identifier, the system ignores the explicit cache parameters.
• Explicit cache is not billed.

Only implicit cache provided by the actual model called is supported: cache may only be hit when a request is routed to the same model and the prompt prefix meets that model's cache conditions. Since different requests may be routed to different models, intelligent routing does not guarantee cache hit rate. For details on how caching works and supported models, see Context Cache.

Manage route service

View detail

After deployment, click the service name in the Dedicated Deployment list to enter the detail page:

• Basic info: service name, model-code, running status, routing strategy tag.
• Route configuration: route model version, routing strategy, candidate set and candidate model list.
• Billing: pay-as-you-go, billed by the actual model's unit price.
• Deploy config: each candidate model's TPM/RPM throttle quota.

Modify route config

Click "Edit" in the Route Configuration area to modify route version, strategy, and candidate models. Switching version changes the candidate set, taking effect within a few minutes without affecting live requests.

After selecting a specific version, online routing behavior remains long-term stable; please conduct a thorough evaluation before upgrading to avoid business impact. Current version: model-router-2026-0908. Route versions are not auto-updated.

Delete service

Delete the intelligent routing service from the Dedicated Deployment list. model-code is not reused after deletion.

Routing effect

This chapter covers routing effect metrics and monitoring. Effect metrics are viewed on the detail page's "Routing effect" tab; call monitoring is viewed on the Model Monitoring page.

Routing metrics

View the following metrics on the detail page's "Routing effect" tab. The displayed metrics are estimates, for reference only; not for billing settlement; actual billing is based on "Cost and Usage":

Cost notes

Cost analysis data has approximately a 1-hour delay and is not real-time. The above costs are all estimated by catalog price as full cost, excluding account discounts and free quotas, for reference only to evaluate routing savings. Tiered billing models use the lowest-tier catalog price; peak-valley pricing models use peak prices. Actual billing can be viewed in "Cost and Usage".

Model monitoring

For more granular call monitoring, go to the Model Monitoring page. It shows model monitoring and logs at the auto-model dimension, not individual monitoring of the actually-routed models.