OpenRouter a ajouté GPT-6 Luna Decisions le 8 octobre, élargissant l’accès à l’interface OpenAI de classification, notation et sélection d’actions. L’API Decisions était entrée en bêta publique deux jours auparavant. La fiche élargit la distribution, pas les preuves que les probabilités sont suffisamment calibrées pour piloter un système en production.
OpenAI annonce des décisions jusqu’à dix fois plus rapides que GPT-6 Luna via Responses API. C’est une comparaison du fournisseur entre deux accès à la même famille, non une supériorité indépendamment établie sur tous les classificateurs, règles ou travaux. Une réponse typée est plus facile à analyser, mais ne signifie ni jugement correct ni autorisation d’agir.
Ce qui est distribué
OpenRouter identifie OpenAI comme fournisseur. Ce n’est pas un modèle entraîné séparément par OpenRouter : OpenAI fournit toujours l’inférence. Les utilisateurs existants gagnent un endpoint dans leur portefeuille, pouvant simplifier achats, facturation et expériences. Ils doivent encore vérifier requêtes, erreurs, disponibilité régionale, observabilité et parité avec le service direct.
L’interface directe utilise un endpoint Decisions dédié plutôt que Responses ; seul GPT-6 Luna était pris en charge dans la bêta décrite. Elle reçoit éléments et questions contraintes au lieu d’une demande de paragraphe libre. Predicate estime la vérité d’une condition, choice sélectionne des options définies, score évalue des niveaux ordonnés d’une grille.
L’entrée peut être du texte ou un message avec texte et image intégrée ; le JSON décrivant l’état peut être transmis en texte. Des réponses nommées permettent plusieurs questions indépendantes sur les mêmes éléments dans une requête. L’endpoint peut classer avant indexation, choisir un modèle ou signaler une escalade. Il n’exécute pas lui-même l’action choisie.
Ces limites distinguent les interfaces. OpenAI recommande Structured Outputs via Responses pour du JSON personnalisé et function calling pour proposer un outil avec arguments. Responses reste adapté aux contenus ouverts, explications, extractions et flux plus larges. Le contrat étroit sert quand conditions observables, options connues ou niveaux ordonnés pertinents correspondent réellement au problème.
Pourquoi une décision limitée change le chemin critique
Une assistance peut nécessiter seulement facturation, technique, livraison ou autre service, pas une explication. La modération peut interroger une violation sur image ; la vente appliquer une grille. Dans une application modulaire, modération, intention, recherche, choix du modèle, outil et vérification finale peuvent chacun nécessiter un jugement sans texte.
Le mécanisme pourrait choisir recherche web, interne, code ou raisonnement renforcé, ou exclure des documents avant consommation du contexte. L’exemple vocal OpenAI choisit une action depuis l’état courant avant qu’un autre composant rapporte le résultat. Dommages sur photos, médias à examiner et classement avant extraction sont des exemples possibles, pas des résultats d’exactitude publiés entre domaines.
Contraindre les sorties réduit potentiellement génération et analyse inutiles. Le développeur doit néanmoins fournir vrais services, actions approuvées, conditions observables et niveaux opérationnels pertinents. Des options fixes empêchent certains noms d’outils inventés, mais ne prouvent pas la pertinence ni l’autorisation.
« Jusqu’à dix fois » décrit le meilleur cas, pas un facteur garanti. Longueur, images, nombre de questions, réseau et routage influencent la latence. OpenRouter ajoute une frontière de service. Le routeur doit coûter moins et aller plus vite que le travail évité, sinon une décision supplémentaire partout peut effacer le gain.
Cet appel crée aussi une dépendance de disponibilité. Un modèle accessible par OpenRouter peut choisir le suivant, mais une panne du décideur peut empêcher tout travail aval. Règles déterministes, modèle par défaut ou chemin direct offrent un repli. Extensions exactes, droits de compte et restrictions régionales relèvent généralement du code ; le probabiliste sert l’ambiguïté plutôt que le remplacement d’une règle précise.
Une probabilité exige interprétation et test
Le typage ne rend pas le jugement déterministe ni ne prouve le calibrage. Une valeur peut refléter fréquence réelle, préférence relative ou confiance sous un prompt donné. On ne peut présumer leur équivalence. Le calibrage exige de vérifier si des confiances prédites semblables correspondent à des exactitudes observées comparables.
Les premières discussions posent des questions, pas des classements définitifs. Un participant rapportait un concurrent meilleur sur plusieurs centaines de tests de jeux, tout en avertissant que l’échantillon étroit n’était pas un benchmark général. Un autre signalait des différences predicate/choice sur une pièce biaisée synthétique, choice concentrant davantage la probabilité qu’attendu. Aucune anecdote n’est une évaluation formelle générale.
Les coûts d’erreur varient. En modération, faux positifs et négatifs ont des conséquences différentes ; le calibrage peut changer avec langues, images et politiques. Envoyer le complexe à un petit modèle baisse la qualité, envoyer le facile toujours au grand supprime les économies. Les seuils doivent refléter les résultats aval, pas seulement l’exactitude du routeur.
Les urgences rares se cachent dans une bonne moyenne. Il faut évaluer séparément predicate, choice et score, plages de confiance, groupes importants, distributions de latence et coûts des actions erronées. Les entrées hors options demandent une stratégie d’abstention. Ajouter « autre » est possible, mais son usage doit être testé.
Choisir n’autorise pas l’exécution
« Rechercher dans les connaissances internes » plutôt qu’« envoyer un e-mail » peut appartenir au plan de contrôle. Un code distinct doit encore vérifier identité, droits, consentement, politique et confirmation avant les outils. Une classification assurée ne fournit aucune de ces autorisations, surtout avec conséquences externes.
Enregistrer état, options permises, probabilités, seuils et actions distingue erreur du modèle, du seuil ou de l’exécution. Responses permet aussi ces traces, mais le contrat étroit encourage l’isolation d’un choix et son test lors des changements. C’est une différence d’architecture, pas une opposition entre OpenAI et son distributeur.
Entrées, facturation et chemin des données restent déterminants
La documentation décrite prévoit une facturation des seules entrées, mais la première version ne faisait pas état du traitement des entrées en cache. C’est une question ouverte, non l’affirmation que le cache ne pourra jamais être ajouté. Répéter une longue politique, un catalogue ou un état peut accumuler tokens et transfert malgré une requête apparemment efficace.
Regrouper des questions indépendantes sur des éléments communs réduit la répétition. Cela ne permet pas à une question de dépendre d’une réponse antérieure dans le même lot. Détecter un dommage puis son type exige des appels séparés, de la latence et un point supplémentaire de propagation de l’incertitude.
Les images nécessitent selon la documentation des URL de données base64 intégrées, pas des liens hébergés ou des identifiants existants. Les bibliothèques doivent prévoir taille et transfert. Les utilisateurs OpenRouter doivent vérifier capacités et limites maintenues : quotas, codes d’erreur, reprises et observabilité dépendent du comportement exact, pas d’un résumé de marketplace.
OpenAI indique que le direct accepte des configurations éligibles Zero Data Retention et de santé réglementée ; ses contrôles décrivent régions de traitement et résidence. Ce sont des capacités conditionnelles. OpenRouter ajoute intermédiaire et autre chemin, exigeant vérification distincte des journaux, du routage et des contrats. L’éligibilité du modèle ne couvre pas automatiquement chaque intermédiaire.
Une catégorie doit encore prouver sa valeur en production
Compte et interface communs réduisent les frictions, mais les métadonnées comparables restent limitées. Les benchmarks de code ou raisonnement ne remplacent pas calibrage, abstention, latence et erreurs pondérées par les conséquences. OpenRouter pourrait ajouter télémétrie, évaluations et comparaisons de repli ; ce sont des perspectives, pas des fonctions démontrées par la fiche.
Changer de fournisseur nécessite plus qu’une syntaxe normalisée. Confiance, notes et refus peuvent avoir des sémantiques différentes, imposant contrat interne stable et validation spécifique. D’autres laboratoires, petits modèles et poids ouverts rivalisent sur vitesse, calibrage ou contrôle local. Un classificateur traditionnel peut surpasser un modèle de langage sur une tâche stable bien étiquetée ; la logique exacte reste adaptée aux règles.
Decisions vise le jugement zero-shot ou défini par prompt sans entraînement séparé, utile avec catégories changeantes et mélange texte-image. Sur des tâches mûres riches en étiquettes, sa commodité peut céder à un classificateur prévisible et moins complexe. OpenAI contrôle modèle, endpoint, SDK et options professionnelles de données ; OpenRouter consolide accès et choix. Aucune voie n’évite l’évaluation.
Trois évolutions éclaireraient sa durée : résultats indépendants spécifiques, charges de production conservées et stables après coût des erreurs et opérations, changements avant disponibilité générale. Modèles supplémentaires, cache, images, SDK et recommandations de calibrage restent à observer. La progression rapide de la bêta était une attente, pas une date promise ; les écarts initiaux entre playground et requête relevaient des retours communautaires, pas d’une panne de chaque intégration.
Interfaces, quotas et comportement peuvent évoluer. Un déploiement réversible parallèle compare le même trafic étiqueté à Responses, règles et classificateurs existants. Probabilité, seuil, résultat et coût doivent séparer faux positifs et négatifs et inclure adversarial, ambigu et hors distribution ; exemples et historique des politiques peuvent accompagner les résultats.
La confiance moyenne peut conduire à un grand modèle ou un humain ; le haut risque conserve l’autorisation explicite même avec forte confiance. Si les endpoints améliorent décisions et coûts globaux, les architectures modulaires peuvent avancer ; un mauvais calibrage ou une faible observabilité peut favoriser Responses, classificateurs ou règles. OpenRouter facilite l’expérience, n’en détermine pas l’issue.
Sources et lectures
Annonce OpenRouter · Fiche du modèle · Documentation Decisions · Annonce bêta et discussion · Délégation vocale · Contrôles des données · Lecture : bases de connaissances