Tarifs de l’API Batch d’OpenRouter : la remise de 50 % vaut-elle l’attente ?

Une API deux fois moins chère, c’est tentant… jusqu’au moment où le résultat arrive après l’échéance. L’API Batch d’OpenRouter convient très bien aux traitements de texte et d’embeddings exécutés en différé, mais pas aux appels interactifs : elle fonctionne de manière asynchrone, prévoit une fenêtre d’exécution de 24 heures et sa remise affichée ne s’applique pas de la même façon à tous les postes de facturation.

La décision en une phrase

Utilisez l’API Batch d’OpenRouter pour l’annotation, les évaluations, les embeddings, la synthèse de files d’attente et les autres traitements qui peuvent attendre. Pour le chat destiné aux utilisateurs, les agents IDE, les workflows de recherche web et les requêtes multimodales, restez sur l’API synchrone.

Selon OpenRouter, Batch propose généralement une tarification par token inférieure d’environ 50 % sur plus de 70 modèles. La fenêtre d’exécution officielle est de 24 heures. Dans son annonce de lancement, OpenRouter indiquait une durée médiane de 7 minutes et 90 % des traitements terminés en moins d’une heure pendant la bêta ; il s’agit de mesures observées, pas d’un SLA (annonce officielle).

Ce que couvre réellement la remise de 50 %

La remise concerne avant tout le prix des tokens du modèle. Elle ne réduit pas automatiquement le coût de chaque composant de la facture d’inférence.

Coût ou paramètre	Traitement avec l’API Batch
Tokens d’entrée et de sortie	Généralement environ 50 % du tarif standard du modèle
Appels de recherche web	Facturés aux tarifs standard, selon le guide de démarrage officiel
Mise en cache des prompts	Variable selon le modèle ; consultez sa page
Inférence BYOK	Le fournisseur facture directement l’inférence ; OpenRouter indique séparément ses frais BYOK
Prix exact applicable	À confirmer sur la page du modèle concerné et dans l’utilisation du batch terminé

Le guide de Will Cygan sur le coût du batching présente l’exemple d’un Claude Sonnet 5 dont le prix passe de 40 $ en synchrone à 20 $ en batch pour 10 millions de tokens d’entrée et 2 millions de tokens de sortie. Il s’agit d’un calcul propre à ce modèle, pas d’un tarif universel.

« La route batch est facturée exactement à la moitié du tarif synchrone. » — Will Cygan, Batching (LLM Inference)

Ne comptabilisez pas l’économie avant d’avoir vérifié le fournisseur et le modèle. Un utilisateur réel, @fogelmania, a signalé qu’un modèle de la bêta lui revenait plus cher que des appels synchrones concurrents, car son trafic batch était dirigé vers un autre fournisseur : publication de @fogelmania. Ce retour invite à contrôler le coût final ; il ne prouve pas que tous les modèles se comportent ainsi.

Un batch est un traitement, pas un endpoint plus rapide

L’annonce de l’API Batch d’OpenRouter et son guide de démarrage décrivent un workflow basé sur des traitements, et non une réponse immédiate. Une soumission acceptée renvoie le code HTTP 202 Accepted, ainsi qu’un identifiant de batch dont le statut est validating. Le cycle normal est le suivant :

validating → in_progress → finalizing → completed

Les autres états finaux sont failed, expired et cancelled. Votre worker doit conserver l’identifiant du batch et interroger son statut jusqu’à l’obtention d’un état final, plutôt que de maintenir ouverte une requête interactive.

OpenRouter indique avoir traité plus de 230 000 batches pendant la bêta, avec une durée médiane de 7 minutes et 90 % des traitements terminés en moins d’une heure. Un test réalisé par @luismmolina faisait état de 5 à 8 minutes à un moment donné le jour du lancement (publication du test) ; ces observations ne remplacent pas la limite de planification de 24 heures.

La structure d’implémentation qui évite de tout refaire

Le guide de démarrage actuel utilise un tableau JSON requests intégré à la requête, plutôt que l’envoi d’un fichier JSONL. Chaque ligne doit posséder un custom_id unique ; cet identifiant permet de rattacher une réponse terminée ou une erreur à l’enregistrement d’origine.

Voici la structure minimale d’une requête :

{
  "endpoint": "/v1/chat/completions",
  "model": "openai/gpt-4o",
  "requests": [
    {
      "custom_id": "ticket-0001",
      "body": {
        "messages": [
          {"role": "user", "content": "Classify this ticket: ..."}
        ]
      }
    }
  ]
}

Le guide de démarrage documente POST https://openrouter.ai/api/beta/batches. L’endpoint et le modèle définis au niveau supérieur s’appliquent à l’ensemble du batch : des formats d’API ou des modèles différents nécessitent donc des batches distincts. Les formats pris en charge incluent Chat Completions, Responses, Anthropic Messages et Embeddings.

Après l’envoi, interrogez GET https://openrouter.ai/api/beta/batches/:id. Un batch terminé renvoie les résultats directement dans la réponse. Chaque résultat contient soit une response, soit une error, tandis que request_counts distingue le nombre total de lignes, les lignes terminées et les lignes en échec. Relancez uniquement les lignes en échec à partir de leur custom_id ; ne rejouez pas automatiquement l’intégralité du batch.

Si le comportement du fournisseur a des implications pour votre politique de données, votre configuration BYOK ou vos ressources accessibles par URL, imposez le fournisseur à l’aide des contrôles documentés, plutôt que de vous en remettre au routage vers le fournisseur le moins cher. Avant le déploiement, vérifiez que le modèle et le fournisseur sélectionnés proposent bien une route batch éligible.

Les cas où Batch bloque le workflow

Les limitations du guide de démarrage font de Batch un workflow principalement orienté texte. Les images, l’audio, la vidéo et les parties de contenu correspondant à des fichiers sont refusés dans les requêtes batch. Les ressources encodées en Base64 et les URI data: sont également rejetées ; la prise en charge des ressources accessibles par URL dépend du fournisseur. Le plugin de recherche web d’OpenRouter n’est pas disponible avec Batch.

Utilisez l’API synchrone lorsqu’un utilisateur attend une réponse, qu’un modèle doit analyser un fichier envoyé localement, qu’une requête nécessite de l’audio ou de la vidéo, ou que l’application impose un objectif de temps de réponse de l’ordre de la seconde.

Exemple de coût : quand l’économie est réelle

Prenons 10 000 tickets de support, chacun nécessitant 1 000 tokens d’entrée et 200 tokens de sortie. Cela représente 10 millions de tokens d’entrée et 2 millions de tokens de sortie.

Route	Entrée	Sortie	Total
Exemple synchrone	10M × 2 $ = 20 $	2M × 10 $ = 20 $	40 $
Exemple Batch	10M × 1 $ = 10 $	2M × 5 $ = 10 $	20 $

L’économie théorique est de 20 $ par exécution, soit 1 040 $ par an si cet exemple est lancé chaque semaine. L’économie réelle est plus faible dès que la reprise sur erreur, la supervision ou un basculement d’urgence vers le synchrone coûte plus cher que la différence nominale.

Intégrez cette réserve dans votre décision. Si l’échéance est impérative, comparez la fenêtre de 24 heures au temps restant pour relancer le traitement sur un périmètre réduit ou basculer vers le synchrone. Un batch moins cher au token, mais inutilisable après la date limite, n’est pas moins cher pour ce processus métier.

FAQ

L’API Batch d’OpenRouter est-elle toujours deux fois moins chère ?

Non. OpenRouter présente cette remise comme une tendance dépendant du modèle. Les frais de recherche web restent standard, la mise en cache varie et le BYOK sépare les coûts d’inférence du fournisseur des frais d’OpenRouter.

Combien de temps prend un batch OpenRouter ?

La fenêtre d’exécution prise en charge est de 24 heures. Les mesures observées pendant la bêta donnent un ordre de grandeur utile, mais ne constituent pas un niveau de service garanti.

Puis-je envoyer un fichier JSONL ou mélanger plusieurs modèles ?

Le guide de démarrage accepte un tableau JSON requests intégré à la requête. Le modèle et le format d’API s’appliquent à l’ensemble du batch : des batches distincts sont donc nécessaires pour des modèles ou des formats d’endpoint différents.

Puis-je relancer uniquement les lignes en échec ?

Oui. Lorsqu’un batch terminé renvoie des erreurs au niveau des lignes, utilisez le custom_id de chaque ligne pour constituer un batch de relance plus petit. Traitez séparément les échecs, expirations ou annulations au niveau du batch, car les résultats peuvent alors être indisponibles.

Dois-je utiliser Batch ou l’API synchrone ?

Choisissez Batch pour les traitements de fond non urgents. Préférez l’inférence synchrone lorsque le résultat s’inscrit dans une interaction active avec l’utilisateur ou nécessite des modalités et des outils non pris en charge.

En pratique : utilisez Batch au cas par cas

Avant de migrer une charge de travail, vérifiez cinq points :

La page du modèle indique une route batch éligible et le fournisseur attendu.
Le processus métier peut tolérer la fenêtre complète de 24 heures.
Chaque ligne possède un custom_id stable et un plan de relance.
L’application enregistre l’utilisation et le coût réellement constatés une fois le batch terminé.
Un responsable est défini pour les entrées et les résultats, avec une politique de nettoyage.

Le guide de démarrage d’OpenRouter précise que les entrées et les résultats des batches sont conservés pendant 30 jours, sauf suppression anticipée. Supprimez les batches arrivés à un état final lorsque leurs artefacts ne sont plus nécessaires.

La meilleure première migration consiste à choisir un corpus figé et vérifiable, pas un parcours destiné aux clients où une réponse tardive coûterait davantage que ce que la remise sur les tokens permet d’économiser.