Guide des modèles GPT-6 : trois niveaux, effort de raisonnement et maîtrise des coûts

Le 2 octobre 2026, OpenAI a publié « A model guide for the GPT-6 family », un document pratique destiné aux startups et aux développeurs. Le guide n'annonce aucun nouveau modèle. Il transforme une gamme déjà commercialisée en une méthode d'ingénierie que les équipes peuvent suivre pas à pas. Le cadrage est net dès les premières lignes : GPT-6 est une suite, pas un modèle unique. Elle compte trois membres. GPT-6 Astra est présenté comme le plus intelligent, facturé 10 dollars par million de jetons en entrée, 50 dollars en sortie et 1 dollar pour l'entrée mise en cache. GPT-6.1 Sol offre une intelligence proche de celle d'Astra pour un cinquième du prix : 2 dollars en entrée, 10 dollars en sortie et 0,10 dollar en entrée mise en cache. GPT-6 Luna vise le travail quotidien, rapide et efficace, à grande échelle, pour 0,10 dollar en entrée, 0,50 dollar en sortie et 0,01 dollar en entrée mise en cache. L'écart est considérable : le prix d'entrée de Luna représente un centième de celui d'Astra. Le choix du modèle cesse donc d'être une question du type « prendre le meilleur » et devient une décision budgétaire que chaque équipe doit prendre en connaissance de cause.

La première partie du guide porte sur l'exploitation en production, et son conseil central est de maîtriser le contexte avant toute chose. Il faut retirer le contexte dont la tâche n'a pas besoin, tout en conservant les éléments de preuve nécessaires. Les tâches indépendantes doivent s'exécuter ensemble, afin qu'une étape lente ne bloque pas un travail sans rapport. Pour les tâches récurrentes, la mise en cache des prompts permet de réutiliser le contexte partagé. OpenAI indique que les jetons d'entrée mis en cache coûtent jusqu'à 95 % de moins que les jetons non mis en cache, selon le modèle. La grille tarifaire le confirme : le tarif en cache de Sol, 0,10 dollar, vaut un vingtième de son tarif d'entrée standard. Pour obtenir cette remise, les équipes doivent placer les instructions stables et les documents de référence avant les détails changeants de la tâche, et garder des définitions d'outils identiques d'un appel à l'autre. Un tableau de bord de cache et un guide de diagnostic montrent où la réutilisation se rompt. Pour estimer le coût d'un flux de travail complet, le guide précise qu'il faut inclure les écritures en cache et les éventuels tarifs de contexte long. Pour les conversations longues, la compaction réduit la taille du contexte tout en préservant l'état nécessaire à la suite. Avant le déploiement, il convient d'exécuter des tâches représentatives et de mesurer le taux de réussite, la latence et le coût par tâche réussie. Ce dernier indicateur mérite l'attention. Un appel bon marché ne fait pas un flux de travail bon marché. Un modèle qui exige trois tentatives peut coûter plus cher, en pratique, qu'un modèle plus onéreux qui réussit du premier coup.

La deuxième partie traite de l'adéquation entre le modèle et la charge de travail, que le guide présente comme un arbitrage entre intelligence et prix. Astra est réservé aux raisonnements les plus difficiles, là où l'intelligence maximale est nécessaire. Sol convient au code complexe, à la recherche et à l'usage d'ordinateur. Luna convient aux tâches ciblées à grande échelle, avec un objectif clair : extraire les champs d'une facture, classer des demandes ou produire des synthèses structurées. Au-delà du modèle, l'API permet de choisir un niveau de raisonnement. Le niveau faible convient aux tâches de routine, comme l'extraction de faits ou de petites corrections. Le niveau moyen convient au travail qui demande du jugement, comme la planification d'une fonctionnalité ou la comparaison d'options. Le niveau élevé convient au débogage difficile, à l'analyse approfondie ou à la relecture minutieuse. Les niveaux très élevé ou maximal, lorsqu'ils existent, ne doivent être testés que si le niveau élevé ne suffit pas, et conservés seulement si le gain justifie le temps et le coût supplémentaires. Dans l'API, l'effort de raisonnement peut changer en cours de conversation sans casser le cache. Dans Codex, le conseil est de partir du niveau par défaut du modèle, puis de le baisser pour les tâches simples ou de le relever pour les analyses plus profondes. Lorsque le temps de réponse compte, comme dans les applications de chat et les outils de code, l'API propose aussi un mode rapide. Modèle, effort et vitesse forment trois réglages qui permettent de configurer le coût par tâche plutôt que par ligne de produit.

La troisième partie concerne les prompts et les compétences. Le guide demande de confier au modèle une mission claire et de définir la sortie attendue. Les prompts, les compétences et les instructions du dépôt doivent s'accorder sur ce que le modèle doit livrer, ce qu'il peut faire seul et ce qui compte comme terminé. Cela paraît banal, mais c'est l'une des sources de défaillance les plus fréquentes dans les flux agentiques. Si un fichier du dépôt autorise des modifications libres alors que le prompt demande de consulter d'abord, le modèle oscille entre deux consignes. Formuler la définition du « terminé » comme une condition vérifiable limite aussi les arrêts prématurés et les retouches sans fin.

La quatrième partie concerne les travaux de longue durée. OpenAI recommande le pilotage en cours d'exécution, les outils asynchrones et la délégation pour gérer les mises à jour en cours de tâche et les sous-tâches indépendantes. Elle demande aussi de fixer des limites claires sur le moment où le modèle doit s'arrêter pour demander l'avis d'un humain. Pour les tâches longues, cette limite compte plus que l'intelligence brute, car un agent qui agit alors qu'il aurait dû demander coûte bien plus cher qu'une question de plus. Pour Codex, le guide mentionne aussi l'usage d'ordinateur, qui permet au modèle de prendre en charge une plus grande part du travail qu'une personne ferait autrement à la main. L'article se clôt sur des exemples d'équipes passées du test à la production avec GPT-6 Astra.

La valeur de ce guide tient moins à une capacité nouvelle qu'à la façon dont il intègre la maîtrise des coûts à la conception du produit. Les équipes choisissaient souvent le modèle le plus puissant, puis cherchaient des économies. OpenAI propose l'ordre inverse. D'abord définir la tâche et les critères de réussite. Ensuite choisir le modèle et le niveau d'effort les moins chers qui les satisfont. Enfin réduire la facture grâce au cache, à la compaction et au parallélisme. Pour les startups, cela signifie qu'un jeu d'évaluation et le coût par tâche réussie doivent devenir des indicateurs quotidiens. Les modèles étagés dotés d'un effort de raisonnement réglable deviendront probablement le schéma par défaut du secteur, et la concurrence se déplacera des scores de benchmark isolés vers la fiabilité et l'économie unitaire de flux de travail entiers.