Enrutamiento y failover

Cómo se elige un modelo, y qué ocurre en caso de fallo del proveedor.

routing_strategy

Cada endpoint acepta model (opcional) y routing_strategy (por defecto "auto"):

manual — usa exactamente el model proporcionado. Error model_not_found si no existe en el catálogo.
auto — puntuación ponderada calidad/coste (calidad x 0.7, penalización de coste normalizada x 0.3) entre los modelos disponibles de la categoría. Un proveedor más barato puede así ganar a uno ligeramente mejor pero más caro.
best_quality — ordena únicamente por puntuación de calidad, descendente.
cheapest — ordena únicamente por precio medio, ascendente.
fastest — ordena por latencia media observada, ascendente.

json

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

Failover automático

Salvo en manual, si el primer candidato elegido falla (fallo del proveedor, timeout, error 5xx), la solicitud se reintenta automáticamente con el siguiente candidato del ranking — de forma totalmente transparente para ti. La llamada solo falla si todos los candidatos compatibles han fallado (503 all_providers_unavailable).

Estado de salud de los proveedores

Cada proveedor tiene un estado monitorizado continuamente: healthy, degraded o down. Un proveedor down queda excluido del ranking (circuito abierto); un proveedor degraded sigue siendo utilizable pero como último recurso. Consultable vía:

bash

GET /v1/status

Catálogo de modelos

La lista completa de modelos disponibles por categoría, con precios y capacidades, se puede consultar libremente (sin llamada de IA, gratis):

bash

GET /v1/models?category=text

Un proveedor multicategoría (p. ej. OpenAI en texto e imagen) comparte un único estado de salud entre sus categorías — un fallo propio de una sola categoría también afecta a las demás categorías de ese proveedor en el enrutamiento automático.