Auto Router

One model=auto, and the gateway decides “which model to use.”

​

Use cases

• General-purpose apps: when you don’t know what kind of request a user will send, hand it to auto to dispatch by content.
• Cost optimization: let simple tasks land on cheaper, faster models automatically (auto is cost-first by default).
• Quality optimization: ensure complex requests are routed to more capable models (auto:quality_first).
• Latency-critical scenarios: real-time voice and multi-turn agent loops prefer the fastest-responding model (auto:latency_critical).
• Single entry point, no model selection: different request types are dispatched to their own optimal models—no need to maintain a “task → model” mapping table, and no need to keep tracking model releases, comparing prices, and swapping names by hand.

​

Quick start

curl https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "messages": [
      { "role": "user", "content": "What is the meaning of life?" }
    ]
  }'

​

How to confirm which model was used

• The model field in the response body is backfilled with the real resolved model (e.g. mimo-v2.5-pro), not auto.
• The response headers give you the full decision detail:

HTTP response headers are case-insensitive: the table above capitalizes them by convention, but the actual HTTP/2 response returns them lowercased as x-aihubmix-router-*—the two are equivalent.

curl -i https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "messages": [
      { "role": "user", "content": "What is the meaning of life?" }
    ]
  }' | grep -i "^x-aihubmix-router"

x-aihubmix-router-decision-id: 05dbad09-33c5-42de-85b5-559fdb73eb4c
x-aihubmix-router-dimension: text.overall
x-aihubmix-router-policy: cost_optimized
x-aihubmix-router-reason: policy=cost_optimized dim=text.overall top=0.182 survivors=20/33
x-aihubmix-router-resolved-model: xiaomi-mimo-v2.5-pro

​

Routing policies

# Quality first + a coding task
curl -i https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto:quality_first",
    "messages": [
      { "role": "user", "content": "Write a Python function to reverse a linked list." }
    ]
  }' | grep -i "^x-aihubmix-router"

latency_critical picked the non--think version—thinking variants have higher reasoning latency, so the latency policy actively avoids them. This shows that policy weights genuinely act on the “capability / cost / latency” tradeoff, not on capability alone.

Content changes the result too: applying the same auto:quality_first to a coding task (the request in the example above), the dimension shifts from text.overall to text.coding, and the measured resolved model is claude-opus-4-6-think—the policy and the request content together determine the final model.

​

How it works

Note that claude-fable-5 has the highest capability score (1510), yet its higher cost and larger latency push its composite score down to third. This is exactly the point of weighted scoring: not “capability above all,” but a policy-driven tradeoff among capability / cost / latency.

​

Reliability and fault tolerance

​

Billing

​

Limitations

• The Auto Router currently targets the chat completions endpoint /v1/chat/completions (see FAQ: which endpoints are supported).
• ?router=off or the request header X-Router-Off makes model=auto return 400 directly—this is an explicit refusal of the ambiguous “want auto but also turn routing off” usage, rather than a silent ignore:
  curl -i "https://aihubmix.com/v1/chat/completions?router=off" \
    -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
    -H "Content-Type: application/json" \
    -d '{"model":"auto","messages":[{"role":"user","content":"hi"}]}'
  # → HTTP/1.1 400 Bad Request
  # {"error":{"message":"auto requires router enabled; remove ?router=off / X-Router-Off", ...}}
  
• The candidate pool changes dynamically with the platform catalog: the same auto may resolve to different models at different times (this is by design, and reviewable via the response headers).

​

Differences from OpenRouter / LiteLLM

​

FAQ

​

Related resources

• Model Mapping and Fallback: Key-level fixed aliases + failure fallback, complementary to the Auto Router.
• Unified Inference Parameters: consistent request parameters across models.
• AIHubMix models page: look up model names, prices, and Input Modalities.