Routage automatique (Auto Router)

Un seul model=auto, et c’est la passerelle qui décide « quel modèle utiliser ».

​

Cas d’usage

• Applications généralistes : lorsque vous ne savez pas quel type de requête vos utilisateurs vont envoyer, laissez auto répartir selon le contenu.
• Optimisation des coûts : laissez les tâches simples basculer automatiquement vers des modèles moins chers et plus rapides (auto privilégie le coût par défaut).
• Optimisation de la qualité : assurez-vous que les requêtes complexes sont routées vers des modèles plus puissants (auto:quality_first).
• Scénarios à faible latence : pour la voix en temps réel ou les boucles multi-tours d’un agent, privilégiez le modèle le plus rapide à répondre (auto:latency_critical).
• Point d’entrée unique, sans choix de modèle : les différents types de requêtes sont automatiquement répartis vers leur modèle optimal — plus besoin de maintenir une table de correspondance « tâche → modèle », ni de suivre en continu les évolutions des modèles ou de comparer manuellement les prix et de changer de nom.

​

Démarrage rapide

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?" }
    ]
  }'

​

Comment confirmer le modèle réellement utilisé

• Le champ model du corps de la réponse est renseigné avec le vrai modèle utilisé (par exemple mimo-v2.5-pro), et non auto.
• Les en-têtes de la réponse fournissent l’information complète sur la décision :

Les en-têtes HTTP sont insensibles à la casse : le tableau ci-dessus utilise par convention une majuscule en début de mot, mais le retour réel en HTTP/2 est en minuscules x-aihubmix-router-* ; les deux sont équivalents.

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

​

Stratégies de routage

# qualité prioritaire + tâche de code
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 a choisi la version non -think — la variante « thinking » a une latence de raisonnement plus élevée, et la stratégie faible latence l’évite activement. On voit que les pondérations de stratégie agissent réellement sur l’arbitrage « capacité / coût / latence », et pas seulement sur la capacité.

Le contenu modifie aussi le résultat : si l’on applique le même auto:quality_first à une tâche de code (la requête de l’exemple ci-dessus), la dimension passe de text.overall à text.coding et, en mesure réelle, c’est claude-opus-4-6-think qui est utilisé — la stratégie et le contenu de la requête déterminent ensemble le modèle final.

​

Fonctionnement

Remarquez que claude-fable-5 a le score de capacité le plus élevé (1510), mais qu’il est relégué à la troisième place sur le score global en raison d’un coût plus élevé et d’une latence plus grande. C’est tout l’intérêt du scoring pondéré : non pas un « tout-capacité », mais un arbitrage entre capacité / coût / latence selon la stratégie.

​

Fiabilité et tolérance aux pannes

​

Facturation

​

Limitations

• Le routage automatique vise actuellement l’interface de complétion de conversation /v1/chat/completions (voir FAQ : quelles interfaces sont prises en charge).
• ?router=off ou l’en-tête X-Router-Off font renvoyer un 400 directement à model=auto — c’est un refus explicite de l’usage ambigu « vouloir auto tout en désactivant le routage », plutôt qu’une ignorance silencieuse :
  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", ...}}
  
• L’ensemble des candidats varie dynamiquement avec le catalogue de la plateforme : un même auto peut utiliser des modèles différents à différents moments (c’est voulu par conception, auditable via les en-têtes de réponse).

​

Différences avec OpenRouter / LiteLLM

​

FAQ

​

Ressources connexes

• Mappage de modèles et fallback : alias fixe au niveau de la clé + repli en cas d’échec, complémentaire au routage automatique.
• Paramètres d’inférence unifiés : paramètres de requête cohérents entre modèles.
• Page des modèles AIHubMix : consultez les noms de modèles, les prix et les Input Modalities.