Routage & fallback

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

routing_strategy

Chaque endpoint accepte model (optionnel) et routing_strategy (defaut "auto") :

  • manual — utilise exactement le model fourni. Erreur model_not_found s'il n'existe pas au catalogue.
  • auto — score pondere qualite/cout (qualite x 0.7, penalite de cout normalisee x 0.3) parmi les modeles disponibles de la categorie. Un fournisseur moins cher peut donc l'emporter sur un fournisseur legerement meilleur mais plus cher.
  • best_quality — trie uniquement par score de qualite, decroissant.
  • cheapest — trie uniquement par prix moyen, croissant.
  • fastest — trie par latence moyenne observee, croissante.
json
{ "model": "claude-opus-5", "routing_strategy": "manual" }

Fallback automatique

Sauf en manual, si le premier candidat choisi echoue (panne fournisseur, timeout, erreur 5xx), la requete est automatiquement retentee avec le candidat suivant du classement — de facon totalement transparente pour vous. L'appel n'echoue que si tous les candidats compatibles ont echoue (503 all_providers_unavailable).

Etat de sante des fournisseurs

Chaque fournisseur a un etat surveille 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 modeles

La liste complete des modeles disponibles par categorie, avec prix et capacites, est interrogeable librement (aucun appel IA, gratuit) :

bash
GET /v1/models?category=text
Un fournisseur multi-categories (ex. OpenAI en texte et en image) partage un seul etat de sante entre ses categories — une panne propre a une seule categorie affecte aussi les autres categories de ce fournisseur dans le routage automatique.