Routage & fallback

Comment un modèle est choisi, et ce qui se passe en cas de panne fournisseur.

routing_strategy

Chaque endpoint accepte model (optionnel) et routing_strategy (défaut "auto") :

manual — utilise exactement le model fourni. Erreur model_not_found s'il n'existe pas au catalogue.
auto — score pondéré qualité/coût (qualité x 0.7, pénalité de coût normalisée x 0.3) parmi les modèles disponibles de la catégorie. Un fournisseur moins cher peut donc l'emporter sur un fournisseur légèrement meilleur mais plus cher.
best_quality — trie uniquement par score de qualité, décroissant.
cheapest — trie uniquement par prix moyen, croissant.
fastest — trie par latence moyenne observée, croissante.

json

{ "model": "claude-opus-5", "routing_strategy": "manual" }

Fallback automatique

Sauf en manual, si le premier candidat choisi échoue (panne fournisseur, timeout, erreur 5xx), la requête est automatiquement retentée avec le candidat suivant du classement — de façon totalement transparente pour vous. L'appel n'échoue que si tous les candidats compatibles ont échoué (503 all_providers_unavailable).

État de santé des fournisseurs

Chaque fournisseur a un état surveillé en continu : healthy, degraded ou down. Un fournisseur down est exclu du classement (circuit ouvert) ; un fournisseur degraded reste utilisable mais en dernier recours. Consultable via :

bash

GET /v1/status

Catalogue de modèles

La liste complète des modèles disponibles par catégorie, avec prix et capacités, est interrogeable librement (aucun appel IA, gratuit) :

bash

GET /v1/models?category=text

Un fournisseur multi-catégories (ex. OpenAI en texte et en image) partage un seul état de santé entre ses catégories — une panne propre à une seule catégorie affecte aussi les autres catégories de ce fournisseur dans le routage automatique.