GPT-6 Astra : max coûte 2.3x low, mêmes réponses

Sur GPT-6 Astra, reasoning_effort: "max" coûte 2.3x plus cher que low et renvoie la même réponse sur chacune des 11 tâches vérifiées. Seul none change la précision, avec 17 échecs sur 33 exécutions (11 tâches, 3 exécutions chacune). Le paramètre reasoning_effort règle la quantité de raisonnement interne effectuée par le modèle avant sa réponse. Ce calcul est facturé en reasoning tokens, au tarif des tokens de sortie. Cet article mesure tous les niveaux, de none à max. Ils ne correspondent pas à ceux de la documentation : la validation de l’API annonce sept valeurs, dont une (minimal) est rejetée par tous les modèles, tandis qu’une autre, absente de la liste (disabled), est acceptée par Astra sans rien désactiver. Ce point change la lecture des benchmarks de lancement d’OpenAI, présentés comme « le meilleur score, tous niveaux d’effort confondus » : le score du classement provient du niveau le plus coûteux.

TL;DR

• GPT-6 Astra accepte sept valeurs de reasoning_effort, dont none et disabled. La documentation en indique cinq et affirme que none n’est pas pris en charge.
• none est la seule valeur qui ramène les reasoning tokens à zéro, et elle échoue sur 17 des 33 tâches vérifiées. Tous les autres niveaux réussissent 33 fois sur 33.
• disabled consomme 243 reasoning tokens, contre 151 pour low, et coûte 54% plus cher par bonne réponse, à précision identique.
• Au tarif public, GPT-6 Astra coûte 1.57x GPT-5.6 Sol par bonne réponse avec low et 2.57x avec max, sur des tâches que les deux modèles réussissent.

Où se situe GPT-6 Astra dans les benchmarks ?

Il devance les autres modèles sur les tâches de type agent, où le modèle pilote des outils en boucle, souvent dans un terminal. Il reste derrière Claude Fable 5.1 sur Humanity’s Last Exam et sur l’Artificial Analysis Intelligence Index, un agrégat indépendant de dix évaluations. Chaque résultat correspond au niveau d’effort ayant obtenu le meilleur score. Le tableau ci-dessous vient de la page de lancement d’OpenAI et reprend les modèles qu’OpenAI a choisi de comparer :

Trois éléments à garder en tête avec ces résultats :

• Sur Humanity’s Last Exam, Astra est derrière Fable 5.1 de 7.8 points. Cette information figure dans le tableau, mais pas dans le texte.
• Dans la ligne Artificial Analysis du propre tableau d’OpenAI, Astra est derrière Claude Fable 5.1, Claude Opus 5 et Claude Fable 5. Dans le classement v4.2 actuel, Fable 5.1 obtient 57 et Astra 55, soit la première et la troisième place.
• Selon OpenAI, les scores de cybersécurité ont été produits « sans les protections de production ». Le modèle commercialisé « refusera » les tâches d’exploitation de vulnérabilités avec preuve de concept.

La phrase située sous les tableaux relie directement les benchmarks à la facture : « Les scores d’évaluation correspondent au meilleur résultat, tous niveaux d’effort confondus. » Le classement Artificial Analysis affiche chaque modèle une fois par niveau d’effort. Astra obtient 54 avec xhigh, contre 55 avec max. La suite de cet article chiffre le coût de ce point supplémentaire.

Quelles valeurs de reasoning_effort GPT-6 Astra accepte-t-il ?

Sept, mais pas celles annoncées par l’API. Une valeur présentée comme valide est rejetée par tous les modèles, tandis qu’une valeur acceptée n’est mentionnée nulle part. La page du modèle répertorie low, medium, high, xhigh et max, et affirme que le modèle « ne prend pas en charge le niveau d’effort none ». L’API contredit deux fois la documentation et se contredit elle-même une fois.

Avec une valeur invalide, la première validation, qui vérifie la structure de la requête avant de sélectionner un modèle, renvoie la même liste de valeurs autorisées pour GPT-6 Astra et GPT-5.6 Sol :

Invalid value: '__invalid__'. Supported values are: 'none', 'minimal', 'low', 'medium', 'high', 'xhigh', and 'max'.

Lorsqu’on envoie ensuite chacune de ces valeurs, une seconde validation propre au modèle rejette certaines valeurs pourtant annoncées par la première. Un code 200 signifie que la requête a été traitée, un code 400 qu’elle a été rejetée :

none fonctionne donc malgré ce qu’indique la documentation. minimal est annoncé, mais rejeté partout. disabled est accepté uniquement par Astra, sans apparaître dans aucune liste. Les messages d’erreur révèlent aussi la version datée actuellement ciblée par l’alias gpt-6-astra : gpt-6-astra-2026-09-03.

none désactive-t-il le raisonnement ? Et disabled ?

none le désactive, et c’est la seule valeur qui le fasse. disabled est un niveau normal au nom trompeur. Nous avons d’abord calculé localement les réponses de 11 tâches par recherche exhaustive afin d’avoir un corrigé incontestable : une règle appliquée 40 fois de suite, un problème de dénombrement soumis à trois contraintes, un problème de sac à dos, une conversion de base, 7 puissance 222 modulo 1000 et six tâches plus courtes. Nous avons testé les sept niveaux d’effort, six sur Sol qui rejette disabled, à raison de 3 exécutions par tâche et par niveau, via un endpoint compatible avec l’API OpenAI Chat Completions. Voici les résultats des cinq tâches les plus difficiles sur GPT-6 Astra :

Le coût par bonne réponse correspond au coût d’une cellule tâche-effort divisé par le nombre d’exécutions réussies. Avec une précision de 20%, il faut payer cinq exécutions pour obtenir une bonne réponse. Le décrochage tient en un seul niveau. De low à max, les deux modèles réussissent les 33 exécutions sur les 11 tâches. Avec none, Astra réussit 16 fois sur 33 et Sol 21 fois sur 33. Sur la tâche d’application itérative, Astra a même renvoyé trois résultats faux différents en trois exécutions. Il n’y a pas de dégradation progressive à ajuster : soit le raisonnement est actif, soit le modèle devine.

disabled est le piège. Cette valeur consomme plus de reasoning tokens que low, medium ou high, et coûte 54% plus cher par bonne réponse que low pour la même précision de 100%. Seuls xhigh et max coûtent davantage par bonne réponse que la valeur dont le nom suggère une désactivation.

Qu’apporte max par rapport à low ?

Rien sur ces tâches, pour un prix 2.3x plus élevé : $0.01946 par appel contre $0.00851, avec 100% de bonnes réponses dans les deux cas. Les reasoning tokens passent de 151 avec low à 370 avec max, tous facturés au tarif de $50 par million de tokens de sortie.

C’est le chiffre à mettre en regard du tableau des benchmarks. Dire que les scores correspondent au « meilleur résultat, tous niveaux d’effort confondus » signifie que chaque score provient du niveau le plus performant. Dans le classement indépendant, la meilleure entrée d’Astra est celle de max, un point devant xhigh. Nos mesures montrent que ce niveau coûte 1.3x celui qui le précède. Sur une charge proche des benchmarks de lancement, cet effort supplémentaire peut être rentable. Sur une charge proche de la nôtre, il ne l’est pas. Pour savoir dans quel cas vous vous trouvez, commencez par mesurer vos propres tâches avec low.

GPT-6 Astra coûte-t-il 2.5x GPT-5.6 Sol par réponse ?

Avec low, non : 1.57x. Avec max, oui : 2.57x. Le tarif public correspond au prix par token publié sur la page du fournisseur. Astra est affiché à $10 en entrée et $50 en sortie par million de tokens, contre $4 et $20 pour Sol. Ces tarifs proviennent des pages OpenAI des modèles Astra et Sol, consultées le 2026-09-07. L’écart public est donc de 2.5x en entrée comme en sortie. La [comparaison entre GPT-5.6 Sol et GPT-6 Astra](/compare/models/gpt-5-6-sol-vs-gpt-6-astra/) reprend les tarifs actuels du catalogue. Voici le coût par bonne réponse, calculé à partir du nombre de tokens et de ces tarifs publics sur les 11 tâches. Les deux modèles obtiennent 33 bonnes réponses sur 33 à partir de low :

Aux niveaux bas, Astra utilise moins de reasoning tokens que Sol pour arriver à la même réponse : 91 contre 158 par appel sur les 11 tâches avec low. C’est ce qui réduit l’écart. Sa consommation augmente ensuite plus vite : 249 contre 242 avec max. À ce niveau, l’écart par réponse rejoint l’écart complet des tarifs publics.

La conclusion reste limitée à ce test : les deux modèles atteignent 100% à partir de low. Ce jeu de tâches ne permet donc pas de comparer leurs capacités, seulement le prix d’une réponse qu’ils trouvent tous les deux. Selon la valeur d’un seul paramètre, l’écart varie de 1.6x à 2.6x. La page de lancement d’OpenAI donne le résultat inverse sur les tâches d’agent : sur Terminal-Bench 4.0, Astra aurait un « coût API estimé par tâche inférieur d’environ 9% et 63% » à Sol et Fable 5.1. Un modèle qui résout davantage de tâches avec moins de tokens peut coûter moins cher malgré un prix par token supérieur. Les charges sont différentes, mais dans les deux cas, le niveau d’effort détermine la facture.

Un schéma JSON ou un appel d’outil ajoute-t-il un coût de raisonnement ?

Pas avec low, mais oui avec medium. Nous avons envoyé une tâche en une seule étape, ajouter 2 heures 37 minutes à 08:15, sous trois formes : directement, dans un schéma JSON strict via response_format, où la réponse doit respecter la structure fournie, et sous forme d’appel d’outil forcé, avec tool_choice fixé à une fonction pour obliger le modèle à répondre en l’appelant. Chaque forme a été testée à quatre niveaux d’effort, avec 3 exécutions par combinaison. Voici la moyenne des reasoning tokens de GPT-6 Astra, leur part dans tous les tokens de sortie facturés et le coût par appel :

low peut descendre jusqu’à zéro : sur une tâche sans étape intermédiaire, il ne consomme aucun reasoning token et coûte autant que none. Sur le jeu de tâches en plusieurs étapes, il consomme entre 16 et 345 tokens par tâche tout en restant correct là où none s’effondre. low est donc le niveau plancher. L’enveloppe de la requête n’est pas la source du surcoût : avec low, un schéma ou un appel d’outil ajoute entre 0 et 4 reasoning tokens. Avec medium, le raisonnement représente 57 à 67% des tokens de sortie pour la forme directe et le schéma, et 18% pour l’appel d’outil, alors que la tâche ne demande aucun raisonnement. Dans le schéma, la même extraction coûte 1.6x plus cher avec medium qu’avec low, et 2.2x plus cher sous forme directe. Le guide des coûts de GPT-5.6 publié en juillet identifiait le même levier sur cette famille. Sol varie moins : aucun reasoning token pour la forme directe et le schéma, quel que soit le niveau, puis 14 à 18 tokens pour l’appel d’outil à partir de medium.

Peut-on lire le raisonnement facturé ?

Sur l’une des deux interfaces API d’OpenAI. L’ancien endpoint Chat Completions et le nouvel endpoint Responses acceptent le même modèle et appliquent la même facturation. Nous avons envoyé la même question avec medium, 3 fois sur chaque interface :

Les nombres de tokens restent dans la marge de variation normale. La facturation est donc identique, la seule différence étant la possibilité de consulter ce qui a été payé. À $50 par million de tokens de sortie, c’est l’endpoint qui décide de cette visibilité. La documentation impose également Responses pour les appels d’outils : « GPT-6 Astra prend en charge Chat Completions, mais les appels d’outils nécessitent Responses ». Une charge qui utilise des outils passe donc obligatoirement par l’interface lisible.

Qu’est-ce qui reste identique à GPT-5.6 ?

L’essentiel du contrat. Nos mesures donnent les résultats suivants :

• Tokenizer. Le même texte de 900 mots produit 1,017 prompt tokens sur GPT-6 Astra, GPT-5.6 Sol, GPT-5.6 Luna, GPT-5.5, GPT-5.4 et GPT-5.2. Les tailles de prompt mesurées sur les modèles 5.x restent valables avec Astra, sans nouveau comptage.
• Paramètres. temperature renvoie une erreur 400 sur Astra comme sur Sol (« non pris en charge avec ce modèle »), tout comme top_p et logprobs. Sur les deux modèles, response_format avec un schéma JSON strict produit une sortie conforme au schéma, tandis qu’une valeur de max_tokens inférieure à 16 est rejetée.
• max sur Sol. En juillet, reasoning_effort: "max" renvoyait une erreur 400 sur GPT-5.6 Sol via Chat Completions. Cette valeur est désormais acceptée, et Sol obtient 33 bonnes réponses sur 33 avec ce niveau.

Les informations suivantes viennent de la documentation et n’ont pas été mesurées ici : la fenêtre de contexte est de 1,050,000 tokens, avec un maximum de 922,000 tokens en entrée et de 128,000 en sortie. Au-delà de 272K tokens en entrée, les prompts sont facturés 2x sur les tarifs d’entrée et de cache. La famille GPT-5.6 applique le même seuil, avec le même mécanisme que nous avons mesuré chez plusieurs fournisseurs. Les lectures du cache sont affichées à $1 par million de tokens et les écritures à $12.50. Un nouveau paramètre prompt_cache_options.ttl: "30m" remplace prompt_cache_retention. Le mode Fast, une option payante qui peut doubler la vitesse selon OpenAI, coûte 2x le tarif standard.

Gestion par Synthorai

La gateway transmet reasoning_effort sans le modifier, y compris pour les valeurs absentes de la documentation. Dans les données d’usage de chaque requête, reasoning_tokens reste un champ distinct, à côté de completion_tokens et du coût facturé. Tous les tableaux ci-dessus reposent sur ces données : le niveau d’effort envoyé, les reasoning tokens consommés et le coût, visibles requête par requête au lieu d’être reconstitués à partir d’un total mensuel.

FAQ

GPT-6 Astra prend-il en charge reasoning_effort none ?

Oui. La documentation affirme le contraire, mais l’API l’accepte sur GPT-6 Astra comme sur GPT-5.6 Sol. C’est la seule valeur qui renvoie zéro reasoning token. Elle échoue aussi sur 17 des 33 exécutions de notre jeu de tâches vérifiées. Elle convient donc aux consultations et aux transformations simples, pas aux tâches comportant plusieurs étapes.

Que fait reasoning_effort disabled sur GPT-6 Astra ?

Il active le raisonnement. disabled est accepté sur GPT-6 Astra, mais rejeté sur GPT-5.6 Sol. Il n’apparaît dans aucune liste documentée ou annoncée. Sur notre jeu difficile, il a consommé 243 reasoning tokens par appel, contre 151 pour low, avec une précision identique. Il faut le considérer comme un alias coûteux d’un niveau intermédiaire, pas comme un interrupteur de désactivation.

Quel reasoning_effort utiliser par défaut sur GPT-6 Astra ?

low. Sur GPT-6 Astra, il n’a consommé aucun reasoning token pour une tâche en une étape et entre 16 et 345 tokens par tâche pour celles en plusieurs étapes. Il a obtenu 33 bonnes réponses sur 33, contre 16 pour none, tandis que max coûtait 2.3x plus cher pour les mêmes réponses. N’augmentez le niveau d’un appel précis que si une évaluation sur vos propres tâches montre une amélioration des résultats. Définissez-le explicitement sur chaque appel et récupérez le nombre de reasoning tokens dans les données d’usage :

resp = client.chat.completions.create(
    model="gpt-6-astra",
    reasoning_effort="low",
    messages=[{"role": "user", "content": prompt}],
)
print(resp.usage.completion_tokens_details.reasoning_tokens)

Mesures réalisées le 2026-09-07 via une interface Chat Completions compatible avec OpenAI, ainsi que via l’endpoint Responses pour comparer la visibilité : 11 tâches avec des corrigés calculés localement par recherche exhaustive, 7 niveaux d’effort, 3 exécutions par cellule sur les deux modèles, prompts salés avec un suffixe unique par requête afin qu’aucune réponse ne provienne d’un cache, et coût issu des données d’usage de chaque requête. Les chiffres des benchmarks viennent du tableau de lancement d’OpenAI et du classement Artificial Analysis, consultés le même jour. Le coût par bonne réponse face à GPT-5.6 Sol est calculé à partir du nombre de tokens et du tarif public documenté de chaque modèle.

À lire aussi : contrôles du raisonnement sur 13 modèles, guide des coûts de GPT-5.6, coût de Claude Opus 5, tarification par paliers du contexte long, coût d’écriture du prompt cache.

← Retour au blog