L'API Decisions de Google répond à 1 000 questions et ne facture aucune sortie

La partie la moins chère de Gemini Decision 1 est celle qui n'existe pas. Google a placé le modèle derrière une nouvelle Gemini Decisions API le 11 novembre 2026, et la page tarifaire affiche un coût de sortie de zéro — pas bon marché, pas remisé, absent, car POST /v1beta/decisions n'a aucune prose à générer. Vous envoyez un bloc d'entrée partagé ainsi que jusqu'à 1 000 questions typées ; vous recevez en retour une réponse calibrée par question et rien d'autre. Le chiffre du classement a attiré l'attention le jour du lancement. C'est la ligne de facturation qui change ce que vous construisez, et cela vaut la peine de faire le calcul avant de copier le diagramme d'architecture de qui que ce soit.

Toutes les autres décisions de modèle que vous avez prises au cours des deux dernières années ont été façonnées par deux coûts qui tirent dans des directions opposées : l'entrée que vous voulez envoyer une seule fois, et la sortie que vous voulez garder courte. Ce point de terminaison supprime entièrement la seconde tension et la remplace par une autre, interne à une seule requête. Une fois que vous voyez où se situe la nouvelle tension, le reste de la conception de l'API — le plafond de questions, le contexte partagé, l'absence de mise en cache — cesse de paraître arbitraire.

Ce que zéro token de sortie fait à l’arithmétique

Prenons un cas réaliste de scoring documentaire : une politique ou un contrat de 40 000 tokens, et 1 000 questions auxquelles vous souhaitez obtenir des réponses. Une seule requête à Decisions API facture une fois 40 000 tokens d’entrée, à 0,10 $ par million, soit quatre dixièmes de cent — 0,004 $ pour l’ensemble des mille réponses.

Posez maintenant les mêmes 1 000 questions de la manière dont vous les auriez posées une semaine plus tôt, sous forme de 1 000 appels generate-content distincts. Chaque appel doit transporter le document, car un point de terminaison de chat n'a aucun moyen de le conserver d'un appel à l'autre. Cela représente 40 millions de jetons d'entrée, soit $4.00 au même tarif par jeton, et l'écart se creuse dès que l'on ajoute les jetons de sortie que chacun de ces appels aurait produits. L'enveloppe n'est pas une fonctionnalité de confort. C'est une différence de coût d'un facteur mille pour le même travail, et elle découle d'un seul choix de conception : les questions sont évaluées par rapport à un contexte partagé unique en une seule passe, et non une question par aller-retour.

Ce calcul vous indique aussi la forme de la charge de travail que ce modèle attend. De nombreuses questions sur un seul grand objet, traitées ensemble. Si vos questions portent sur 1 000 objets différents, vous obtenez 1 000 requêtes et aucune économie.

L’enveloppe : 262 144 tokens, partagée et plafonnée à 1 000 questions

La fenêtre de contexte couvre ensemble l’entrée partagée et chaque question de la requête, pour 262 144 jetons. Dans ce budget, vous pouvez poser entre 1 et 1 000 questions. Le nombre qui compte est la limite supérieure : 1 000 questions en un seul appel, ce n’est pas du ressort d’un classifieur, c’est un volume de jugement équivalent à celui d’un moteur de règles, compressé en une seule passe. Un ticket d’assistance peut être vérifié par rapport à quarante clauses de politique ; un dossier de prêt peut être testé par rapport à toutes les règles de souscription à la fois.

Deux propriétés de la structure de la requête sont faciles à négliger et coûteuses à découvrir plus tard. Les questions sont évaluées indépendamment — la réponse à une question ne conditionne pas la suivante, vous ne pouvez donc pas enchaîner un raisonnement en posant une question de suivi qui dépend d’une réponse antérieure. Et le modèle ne voit jamais vos clés de question, uniquement le texte d’instruction que vous écrivez ; les clés servent donc à votre propre suivi et les instructions doivent se suffire à elles-mêmes.

Trois formes de questions, et le piège à l'intérieur de chacune

• Oui/non — le type noul renvoie une probabilité comprise entre 0,01 et 0,99 ainsi qu'un score de confiance. La valeur est bornée aux deux extrémités : un seuil de routage fixé à 0,995 ne se déclenchera donc jamais, quelle que soit la certitude du modèle. Choisissez des seuils dans la plage que l'API peut réellement renvoyer.

• Choix — de deux à 255 options nommées, renvoyant l’option gagnante, une probabilité pour chaque option dont la somme vaut un, et un indice de confiance. Avant le calcul du score, l’API trie les clés de vos options par ordre alphabétique selon l’ordre des octets UTF-8, ce qui signifie que l’ordre des clés JSON n’a pas d’importance et qu’une égalité exacte est tranchée en faveur de la clé qui se classe en premier. Les recommandations de Google en découlent : nommez votre option fourre-tout other, car un nom comme none_of_the_above se classe avant la plupart des catégories réelles et remportera des égalités qu’il devrait perdre.

• Score — de deux à 255 niveaux de barème ordonnés, deux à dix étant recommandés. La valeur renvoyée est un niveau attendu pondéré par les probabilités, et comme la valeur attendue fait la moyenne des indices du tableau plutôt que des libellés, une échelle écrite 1/10/100/1000 produit un nombre qui ne figure pas sur votre échelle. Gardez le barème régulièrement espacé en termes d'indices, ou convertissez vous-même l'indice attendu en libellé.

Ce que la documentation indique comme indisponible

Les lacunes vont toutes dans le même sens : il s’agit d’un point de terminaison à tir unique, sans rien autour. Il n’y a pas de mise en cache du contexte, donc un document de politique réutilisé d’une requête à l’autre est facturé à nouveau en totalité à chaque fois. Il n’y a pas d’API Batch, ce qui exclut un balayage nocturne à moitié prix des tickets de l’année dernière. Il n’y a ni niveau Flex ni niveau Priority. Le modèle est disponible uniquement sur la Gemini Developer API, en version v1beta, sans aucune mention dans Vertex AI dans la documentation livrée par Google — un détail qui compte pour quiconque dont les achats passent par un contrat cloud plutôt que par une clé API.

Le domaine des médias est à la fois exceptionnellement large et exceptionnellement délimité. Le texte, l’image, la vidéo, l’audio et le PDF passent tous dans une seule requête. Les limites sont de 100 Mo en base64 intégré, 50 Mo pour un PDF et 15 Mo par URL HTTPS externe. Les liens YouTube ne sont pas acceptés, pas plus que les URI gs:// ; vous transmettez des références de fichiers téléversés, des URL signées ou des octets.

Les limites de débit commencent à 200 requêtes et 50 000 jetons par minute sur le niveau gratuit, passent à 1 500 et un million au niveau 1, et atteignent 5 000 requêtes et quatre millions de jetons par minute au niveau 2, sans plafond quotidien de requêtes. Le niveau gratuit est exempt de frais, mais il est documenté comme étant utilisé pour améliorer les produits Google, ce qui le disqualifie pour tout usage soumis à une clause de confidentialité.

Le score, en bref

Sur l’Artificial Analysis Decision Index v2.1, le modèle se situe à 66 — 65,98 avant arrondi —, soit neuvième des dix-huit modèles de décision classés par le comité. Il occupe la première place sans partage sur deux des six composantes, AA-Omniscience-Decision v1.1 et HLE-MultiChoice v1.1, toutes deux pondérées à 15 %, et se situe en milieu de tableau sur AA-Paperclip, pondérée à 30 %, la composante qui détermine l’essentiel du composite. Le coût mesuré est de 345 $ par million de tâches et la latence de 211 millisecondes par tâche, contre une médiane du panel de 209. Google n’a publié aucun tableau de référence qui lui soit propre lors de la sortie ; chaque chiffre de performance ici provient du comité indépendant, sur son propre banc d’essai. L’arithmétique qui sous-tend le 66 est une question à part, traitée dans un autre article.

L'intégrer à un pipeline que vous acheminez déjà

OrcaRouter ne prend pas en charge gemini-decision-1, et la raison est structurelle plutôt que commerciale : un endpoint qui ne fournit que des probabilités n’est pas une cible de chat-completions, il n’y a donc rien qu’un routeur de notre forme puisse placer derrière une seule clé. La moitié du pipeline pour laquelle nous existons est l’autre moitié. Un service de décision repose presque toujours sur deux appels — quelque chose rédige la réponse candidate, la grille d’évaluation ou la liste restreinte, et quelque chose l’évalue — et c’est dans l’appel de rédaction que le choix du modèle est réellement disputé.

Cet appel peut s’exécuter sur plus de 200 modèles via un seul endpoint, au prix catalogue du fournisseur répercuté avec 0 % de marge, de sorte que lorsqu’un fournisseur baisse un prix, le nouveau tarif est actif de notre côté le jour même plutôt qu’au prochain cycle de facturation. La fusion de modèles mérite sa place ici d’une manière qui n’est pas le cas dans une interface de chat : deux rédacteurs produisent des réponses candidates concurrentes, et l’API Decisions les évalue toutes les deux selon la même grille d’évaluation en une seule requête, ce qui transforme un test A/B en une décision par enregistrement.

Le basculement mérite lui aussi d'être abordé avec précision. Le basculement automatique protège l'appel génératif — si le fournisseur derrière votre modèle de rédaction renvoie des erreurs, la requête est redirigée et le pipeline continue de tourner. Il ne peut pas protéger l'appel de scoring, car il n'existe qu'un seul endroit où l'envoyer. Si le point de terminaison des décisions est indisponible, votre pipeline est à l'arrêt, et aucun routage ne changera cela. Concevez la moitié rédaction pour qu'elle soit résiliente et acceptez que la moitié scoring soit une dépendance.

L'essentiel

L’API Decisions mérite d’être adoptée pour une raison, et ce n’est pas sa position au classement : elle réduit mille allers-retours à une seule entrée facturée, et cela change les questions qu’il est peu coûteux de poser. Appuyez-vous dessus si vos problèmes ressemblent à de nombreux jugements portant sur un seul gros objet — un contrat, un dossier de réclamation, une heure de vidéo — et prévoyez de garder vos prompts dans une seule requête, car tout ce qui la rend peu coûteuse se produit entre le premier et le dernier token d’un seul appel. Si vos problèmes ressemblent à une seule question portant sur mille petits objets, l’enveloppe ne vous apporte rien et le tarif des entrées est tout simplement trois fois ce que facture un modèle de décision moins cher.