L'API Decisions d'OpenAI est désormais en bêta publique — et son prix n'est pas ce que la couverture du lancement avait supposé

Huit jours après que le fournisseur a présenté l'API Decisions au DevDay, elle a cessé d'être une chose à laquelle il fallait être invité. Le point de terminaison est passé en bêta publique le 6 octobre 2026, accompagné d'une page de documentation, d'un lien vers le Playground et du premier prix publié pour le service. Deux détails de cette publication comptent plus que tout le reste. Le premier est que GPT-6 Luna est le seul modèle que le point de terminaison acceptera — les capacités de l'API et son plafond ne font donc, pour l'instant, qu'un. Le second est que l'arithmétique du jour du lancement à laquelle presque tout le monde s'est livré, y compris nous, était erronée d'une manière qui mérite d'être corrigée : la première vague de couverture a déduit le coût par appel en se référant à la grille tarifaire des tokens de Luna, et cette déduction sous-estime en réalité la remise d'un facteur cinq.

Rien de ce qui suit n’est de la spéculation. Tout est lisible aujourd’hui dans la documentation développeur d’OpenAI elle-même, et c’est là le changement : le 30 septembre, il n’y avait nulle part dans la documentation d’OpenAI de page de documentation pour ce point de terminaison, aucune entrée de journal des modifications, aucun tarif et aucune forme de requête indiquée. Ces quatre éléments existent désormais.

Qu'est-ce qui a été livré, précisément

La bêta est un point de terminaison dédié — POST /v1/decisions — et ce n'est pas un mode de l'API Responses, qui est l'élément auquel elle est comparée. Une requête comporte trois champs :

• modèle — actuellement gpt-6-luna et rien d'autre
• entrée — les données partagées : une chaîne de texte, ou des messages utilisateur contenant du texte et des images
• questions — une ou plusieurs questions, chacune avec un type, des instructions et d'éventuelles options autorisées

La réponse est un réponses tableau, une entrée par question, indexé par le nom que vous avez donné à chacune. C'est tout le contrat, et l'ingénierie intéressante réside dans les trois types de questions plutôt que dans la plomberie.

• predicate — renvoie une probabilité de 0 à 1 qu'une condition donnée soit vraie. « Cette photo de produit montre-t-elle des dommages visibles ? » L'exemple de la documentation renvoie 0,92 et vous invite à le comparer à un seuil que vous avez choisi.
• choice — renvoie une valeur parmi un ensemble que vous fournissez, ainsi qu'une distribution de probabilités sur toutes les options et un champ confidence distinct. L'exemple de la documentation achemine une réclamation de facturation vers billing à 0,95.
• score — renvoie une moyenne pondérée par les probabilités sur des niveaux ordonnés. Fournissez-lui trois niveaux de gravité — cosmétique, solution de contournement disponible, totalement bloqué — et des probabilités de 0,1, 0,7 et 0,2 donnent un score de 1,1, qui se situe délibérément entre deux niveaux plutôt que de se caler sur un seul.

Le prix est inférieur à ce qu’on pourrait spontanément supposer, et le mode de facturation est différent.

Voici la correction. Lorsque l’API Decisions était en aperçu limité, la position honnête était qu’aucun prix n’existait et que quiconque en citait un ne faisait que l’inférer. L’inférence naturelle portait sur les tarifs de jetons de Luna : 0,10 $ par million de jetons d’entrée et 0,50 $ par million de jetons de sortie. Ce n’est pas ainsi que le point de terminaison facture.

Le tarif documenté pour /v1/decisions avec gpt-6-luna est de 0,10 $ par million de jetons d'entrée, avec aucun frais de sortie, et aucun frais de lecture ou d'écriture de cache non plus. Vous payez pour les preuves que vous envoyez, pas pour la réponse qui vous revient. Rapporté à la grille tarifaire du modèle lui-même — où la sortie coûte cinq fois le prix de l'entrée et les lectures de cache un dixième de celui-ci — c'est un profil de coût sensiblement différent, et meilleur pour exactement la charge de travail à laquelle le point de terminaison est destiné, où l'entrée est un paragraphe ou une image et la sortie vaut la valeur d'un seul jeton de décision.

Deux mises en garde s'ajoutent à ce chiffre, et toutes deux sont énoncées par OpenAI plutôt que déduites : les suppléments régionaux de traitement et les multiplicateurs d'entrée pour les contextes longs s'appliquent toujours, et le montant statique de 0,10 $ correspond précisément au tarif /v1/decisions — les autres requêtes utilisant gpt-6-luna suivent la tarification ordinaire du modèle et du niveau de traitement.

Si vous évaluiez cela par rapport à la grille tarifaire de Luna en partant du principe qu'une décision coûte une entrée plus une sortie, refaites le calcul. Cela représente environ un cinquième de ce que ce modèle implique, avant même de tenir compte du palier de contexte long.

L'affirmation sur la latence, reformulée

L’autre chose qui a changé, c’est la formulation de l’affirmation centrale sur la performance, et le changement est assez subtil pour mériter d’être signalé, car il déplace ce qui est comparé.

Le texte de lancement d'OpenAI indiquait que la Decisions API prend des décisions « jusqu'à 10 fois plus rapidement que GPT-6 Luna via la Responses API ». La documentation commence désormais par : l'API « évalue du texte, des images, ou les deux, et renvoie des réponses typées environ 10 fois plus rapidement que la Responses API ».

Ce ne sont pas les mêmes phrases. La première compare un point de terminaison à décision contrainte à un appel génératif complet et attribue la différence au point de terminaison. La seconde compare le point de terminaison à l’API Responses de manière générale. Dans les deux cas, le chiffre reste déclaré par le fournisseur et non reproduit — aucune distribution, aucune région, aucune taille d’entrée, aucun niveau de concurrence, aucun accord de niveau de service — et un chiffre unique est une mauvaise base pour une décision entre un clic et un paiement : mesurez vos propres p99 et p999 avec votre propre trafic.

Ce qui s'est vraiment amélioré, c'est qu'il est désormais possible de répondre à la question, tout simplement. En preview, vous ne pouviez pas tester cela sans accès. En bêta publique, vous le pouvez.

Où il s’exécute, et la seule chose à garder à ses côtés

Deux notes opérationnelles issues de la documentation qu’il est facile de manquer en survolant. Le point de terminaison prend en charge la Zero Data Retention et l’utilisation HIPAA pour les clients éligibles, et la résidence des données est proposée aux États-Unis et en Europe — plus précisément l’EEE plus la Suisse. Ces éléments sont conditionnés à l’éligibilité plutôt qu’activés par défaut, donc consultez la page des contrôles de données avant de supposer que l’un ou l’autre s’applique à votre compte.

Il existe également un guide d'accompagnement pour connecter le point de terminaison à l'API Live, afin qu'une requête vocale puisse être transformée en une action choisie dont le résultat est ensuite rapporté au locuteur. C'est l'utilisation de second ordre la plus intéressante de la primitive : non pas « classer ce ticket », mais « décider ce que l'agent doit faire ensuite, à voix haute, dans une conversation ».

L'API est le propre packaging d'OpenAI et nous ne la routons pas ; si vous voulez ce point de terminaison précis, c'est chez OpenAI qu'il se trouve. Le modèle qui se trouve en dessous est une autre affaire — GPT-6 Luna est une route active sur OrcaRouter au prix catalogue d'OpenAI, avec aucune marge appliquée, et comme les limites propres au point de terminaison peuvent évoluer pendant une bêta, la forme raisonnable pour un déploiement en production est une décision contrainte sur le chemin critique, avec un repli basé sur un prompt déjà préchauffé derrière elle. Garder ce repli sur la même clé que tout le reste signifie aucun second contrat et aucune réécriture du chemin de repli lorsqu'un aperçu modifie ses limites.

Que faire cette semaine, et ce qui manque encore

Le résumé honnête de l'état des choses : deux des quatre lacunes présentes au lancement ont été comblées, et deux ne l'ont pas été. Le prix est publié, la forme de la requête est publiée, les trois types de questions sont documentés avec des exemples concrets, et la question du traitement des données est au moins évoquée. Ce qui manque encore, c'est toute limite publiée sur le nombre de questions candidates qu'une seule requête peut contenir, toute déclaration sur la possibilité d'ajuster l'outil sur vos propres données étiquetées, et — parce qu'il s'agit d'une bêta de l'aveu même d'OpenAI — aucun engagement selon lequel le tarif que vous lisez aujourd'hui perdurera jusqu'à la disponibilité générale.

Cela rend le calcul simple plutôt que spectaculaire. Si votre problème est la classification ou le routage à grande échelle, où une mauvaise branche est peu coûteuse et réversible, on peut désormais réellement bâtir sur la bêta publique, et la tarification à l’entrée uniquement rend l’arithmétique exceptionnellement clémente. Si votre décision autorise de l’argent ou envoie des messages à un client, le point de terminaison a cessé d’être inconnaissable, mais il n’a pas encore cessé d’être une bêta, et la différence entre ces deux choses est la différence entre un prototype et une dépendance porteuse.