Modèles & routage

UberLLM envoie chaque requête à un fournisseur tiers disponible pour le modèle que vous avez demandé. Si le fournisseur échoue avant de commencer à répondre, la requête est relancée, et une requête qui échoue toujours n'est pas facturée. Chaque requête est facturée au prix du fournisseur, sans frais UberLLM supplémentaires, et son coût est indiqué dans Tableau de bord → Activité. Vous choisissez un modèle, pas un fournisseur.

Identifiants de modèle

Utilisez l'identifiant de modèle du catalogue, par exemple deepseek/deepseek-v4-flash, anthropic/claude-sonnet-5 ou z-ai/glm-5.3. Voici ce que vous pouvez appeler dès maintenant :

GET https://api.uberllm.dev/v1/models : les modèles de chat auxquels vous pouvez envoyer une requête dès maintenant. Ainsi, un outil qui remplit son menu de modèles à partir de cette liste (SillyTavern, LibreChat, n8n, Cline) n'affiche que les modèles avec lesquels il peut discuter. Ajoutez ?type=video (ou image, music, speech, transcription, audio pour les deux, chat, plusieurs joints par des virgules) pour d'autres types, ou ?type=all pour tous les modèles, d'abord le chat, puis l'image, la vidéo, la musique, la parole et la transcription. Chaque entrée contient type (chat, image, video, music, speech, transcription), endpoints (les chemins qui le servent) et pricing.
Chaque modèle de chat indique également ce qu'il peut faire : context_length, max_output_tokens, input_modalities (image = il lit les images), supports_tools, supports_reasoning, supports_vision et supported_parameters (les champs de requête qu'il accepte). Les mêmes informations sont également disponibles sous les noms d'OpenRouter (architecture.input_modalities, top_provider.context_length, top_provider.max_completion_tokens, et pricing.prompt / pricing.completion en dollars par token), de sorte que les outils conçus pour la liste d'OpenRouter lisent la nôtre telle quelle.
GET https://api.uberllm.dev/v1/models/<model id> : un modèle, avec son prix, son contexte (chat) et, pour un modèle média, parameters : un JSON Schema du corps de la requête (voir Créer une vidéo ou une image).
Chaque entrée, dans les deux réponses, contient également :
- available : true lorsqu'une requête pour ce modèle peut être traitée immédiatement. false signifie que personne ne le sert pour le moment, donc une requête serait refusée avec no_available_provider. Choisissez un autre modèle ou réessayez plus tard.
- input_modalities : ce que le modèle accepte. Un modèle qui a besoin d'une image (image vers vidéo, référence vers vidéo, édition d'image) liste "image" à côté de "text" ; un modèle qui prend une vidéo (upscaling) liste "video".
- nsfw : true pour un modèle conçu pour du contenu adulte ou non filtré (Lustify, les modèles "non censurés" et similaires). Ignorez ceux-ci si votre produit doit rester adapté au travail.
Public, sans clé : GET https://api.uberllm.dev/api/v1/public/models (avec les prix, et les mêmes champs available, input_modalities et nsfw)
Web : uberllm.dev/#models, et une page par modèle à uberllm.dev/models/<model id>

Que se passe-t-il à chaque requête

UberLLM vérifie que le modèle existe, que votre prompt tient dans sa fenêtre de contexte et qu'il prend en charge les outils si votre requête les utilise.
Il réserve le coût estimé sur votre solde et transmet la requête.
La requête est envoyée à un fournisseur disponible pour ce modèle. Le fournisseur est choisi à nouveau pour chaque appel : le moins cher qui commence à répondre assez vite pour la taille de votre prompt (dans les 2x du plus rapide mesuré, ou en moins de 1 seconde). Un long prompt en streaming est également envoyé à un second fournisseur rapide si le premier est lent à démarrer ; vous obtenez et payez une seule réponse. Nommer les fournisseurs dans provider.only, ignore ou order, ou définir sort, remplace ce choix. Comment ça marche : le routage intelligent.
Lorsque la réponse est terminée, UberLLM règle au prix que le marketplace rapporte pour cet appel et libère le reste de la réservation.

Relances automatiques

Si un appel échoue avant que tout contenu ne vous parvienne, UberLLM le relance pour vous. La marketplace ré-associe un vendeur à chaque tentative, et elle ne facture rien pour un appel qui a échoué avant d'être acheminé, donc une nouvelle tentative ne vous coûte que du temps.

Relancé en cas de : aucun vendeur disponible pour le modèle actuellement (no_sellers_for_model, no_healthy_sellers), la marketplace a manqué de temps pour acheminer (route_deadline_exceeded), un 429 demandant d'attendre 5 secondes ou moins, tout 5xx, une erreur de connexion, un vendeur dont la clé de fournisseur ou le compte a échoué, ou aucun premier octet dans les temps.
Pas de nouvelle tentative en cas de : le modèle n'existe pas, la requête est invalide, ou un problème de facturation ou d'authentification. Ceux-ci reviennent immédiatement.
Calendrier : jusqu'à 4 tentatives, en attendant 0.3 s, 0.9 s, puis 2.7 s entre elles (ou le Retry-After envoyé par la marketplace, s'il est de 5 secondes ou moins). Quand personne ne vend le modèle, la réponse revient en quelques secondes.
Attente du premier octet : un stream obtient 10 secondes (plus pour un prompt long, et plus pour un modèle qui est habituellement lent) ; une réponse sans "stream": true obtient 85 secondes, car rien n'arrive tant qu'elle n'est pas complète. Une tentative qui épuise les 85 secondes complètes n'est pas attendue une deuxième fois. Aucune nouvelle tentative ne démarre après 150 secondes.

Une fois que le streaming a commencé, rien n'est relancé : un échec en cours de stream met fin au stream et vous n'êtes facturé que pour ce qui a été produit.

Si toutes les tentatives échouent, vous obtenez une erreur au lieu d'une réponse, et la réservation est entièrement libérée. Les erreurs courantes :

HTTP	`code`	Quand
503	`no_available_provider`	Personne n'a pu servir ce modèle actuellement, même après des nouvelles tentatives : aucun vendeur, chaque vendeur échouant ou étant trop lent à démarrer, ou vos options `provider` n'ont rien laissé à acheminer. Le message nomme le modèle. Réessayez sous peu ou choisissez un autre modèle.
503	`service_unavailable`	Un problème temporaire du côté d'UberLLM. Réessayez dans quelques minutes.
404	`model_not_found`	L'ID du modèle n'est pas disponible.

Voir Erreurs pour la liste complète.

Modèles de secours

Envoyez models avec une liste d'autres identifiants de modèle à essayer, dans l'ordre, lorsque le premier ne peut pas être servi :

{ "model": "deepseek/deepseek-v4-flash",
  "models": ["z-ai/glm-5.3", "qwen/qwen3.6-plus"],
  "messages": [{ "role": "user", "content": "hi" }] }

Le modèle suivant n'est essayé que lorsque personne ne peut servir celui d'avant en ce moment (no_available_provider), ou que personne ne le vend dans votre provider.max_price. Une erreur de requête (un corps de requête invalide, un identifiant de modèle inconnu dans l'un ou l'autre champ) et un refus de paiement (solde, limites de clé) reçoivent une réponse immédiate et ne sont jamais transmis à la liste. Au maximum 5 modèles dans model et models combinés. Le champ model de la réponse et la ligne d'activité nomment le modèle qui a répondu. models fonctionne sur /v1/chat/completions et sur les requêtes d'image, de vidéo, de musique et de parole ; /v1/messages et /v1/audio/transcriptions ne le lisent pas.

Alias de modèles

Au lieu d'un ID de modèle, vous pouvez nommer ce dont vous avez besoin, et UberLLM choisit le modèle à chaque requête :

best-price:<job> : le modèle disponible avec le prix le plus bas pour une requête ordinaire. Un modèle de chat est comparé par son prix par million de tokens avec la sortie comptée trois fois ; un modèle d'image par une image (une image 1024×1024 quand elle est tarifée par mégapixel) ; un modèle vidéo par son clip le plus court ; un modèle de musique par une piste ; un modèle de parole par 1K caractères ; un modèle de transcription par une minute.
fastest:<job> : le modèle avec le temps médian le plus bas sur ses requêtes réussies sur UberLLM au cours des 7 derniers jours (temps jusqu'au premier token pour le chat, temps jusqu'au fichier terminé pour les médias), en ne comptant que les modèles avec au moins 5 de ces requêtes. Quand aucun modèle n'en a assez, la requête est refusée avec 503 no_timing_data, et best-price: fonctionne toujours.

Les deux ne choisissent que parmi les modèles disponibles actuellement : le marché en direct montre un vendeur sain pour celui-ci, et la dernière requête d'UberLLM à celui-ci au cours des 10 dernières minutes n'a pas trouvé tous les vendeurs occupés ou en panne (la même règle que available sur /v1/models). Sur une route média, quand le modèle choisi par un alias répond que personne ne peut finalement prendre la requête, la même requête passe au modèle suivant que l'alias représente (jusqu'à 3 modèles), et le model de la réponse nomme celui qui a répondu. Quand aucun modèle pour le travail n'est disponible, la réponse est 503 no_available_provider et rien n'est facturé.

<job> est l'un des chat, image, image-edit, text-to-video, image-to-video, music, speech, transcription. Envoyez un alias de chat à /v1/chat/completions ou /v1/messages, et un alias média à sa route média. Le champ model de la réponse nomme le modèle vers lequel il a été résolu. GET /v1/models/aliases liste chaque alias qui se résout actuellement et son modèle ; GET /v1/models/best-price:chat décrit le modèle qu'il représente, avec alias défini.

Options de routage

L'objet provider est lu sur /v1/chat/completions. Une option qu'UberLLM ne peut pas appliquer est refusée avec 400 unsupported_routing_option et rien n'est facturé, ainsi une requête ne s'exécute jamais avec un paramètre ignoré silencieusement.

Option	Ce qu'elle fait
`only` / `allow`	Uniquement ces routes ou fournisseurs. `uberllm` (la route marketplace d'UberLLM) et `seller` (les offres propres des vendeurs) choisissent parmi nos routes. Tout autre nom, tel que `openai` ou `api.venice.ai`, est un fournisseur sur la marketplace : la requête passe alors par la route `uberllm`, qui n'utilise que les offres de ces fournisseurs.
`ignore` / `deny`	Jamais ceux-ci. Noms de routes comme ci-dessus. Les noms de fournisseurs (au maximum 32) sont refusés sur la marketplace, et la requête passe alors par la route `uberllm`.
`order`	Ordre préféré. Les noms de routes ordonnent nos routes ; les noms de fournisseurs définissent l'ordre de tentative de la marketplace. Cela ne rend jamais un fournisseur éligible ou inéligible.
`sort`	`price` (par défaut), `latency` (le plus rapide observé en premier, dans une fourchette de prix) ou `uptime` (le plus fiable en premier, dans la même fourchette). `throughput` ordonne uniquement nos propres routes.
`max_price`	Le montant maximum que vous payez par million de tokens, en dollars US : `{ "prompt": 1.0, "completion": 3.0 }`. Les routes dont le prix est supérieur sont ignorées ; la route marketplace est maintenue pour les vendeurs au moins aussi loin en dessous du prix catalogue du modèle que votre plafond l'exige. S'il ne reste rien, la requête est refusée avec `400 max_price_exceeded` et rien n'est facturé. Lorsque vous définissez à la fois `prompt` et `completion`, une requête n'est jamais facturée au-delà de ces montants pour les tokens qu'elle a utilisés.
`allow_fallbacks`	`false` désactive les tentatives automatiques ci-dessus ; le premier échec vous est renvoyé.
`data_collection`	Seul `"allow"` (par défaut) est accepté.
`zdr`, `require_parameters`	Seul `false` est accepté.

Les suffixes de modèle :floor et :nitro sont acceptés et retirés de l'ID du modèle ; :floor trie par prix et :nitro par débit.

Pour l'image, la vidéo, la musique et la parole, chaque requête est envoyée à un fournisseur tiers disponible pour le modèle. provider.max_price est le coût maximum d'une unité (image, seconde, mégapixel, minute, 1K caractères ou requête), sous forme de nombre : { "max_price": 0.05 } ; il plafonne également la facture. Toute autre option provider est refusée pour les médias.