GPT-6.1 Sol propose cinq niveaux d'effort de raisonnement : low, medium (par défaut), high, xhigh et max. Le grand changement par rapport à GPT-6 Sol est que none et minimal ont disparu, donc low devient le niveau minimal.
Ce seul réglage influence à la fois la latence et le coût. Vous ne voyez jamais les tokens de raisonnement, mais vous les payez au tarif de sortie (10 $ par million pour 6.1 Sol sur AIHubMix), et ils occupent de la place dans la fenêtre de contexte. Avec le mauvais niveau, vous pouvez facilement payer plusieurs fois plus que nécessaire.
À quoi sert chaque niveau
Ce tableau combine les descriptions d'OpenAI issues du guide sur le raisonnement avec nos propres recommandations :
| Niveau | Description d'OpenAI | Bon usage | Mauvais usage |
|---|---|---|---|
| low | Raisonnement efficace avec une légère hausse de latence | Étapes intermédiaires dans les boucles d'outils, recherche, planification légère, classification, extraction, réponses de support | Débogage complexe, refactorisations sur plusieurs fichiers |
| medium (par défaut) | Le réglage équilibré par défaut pour la plupart des charges de travail | Codage courant, revue de code, rédaction, tâches d'agent typiques | Usage interactif critique en latence |
| high | Raisonnement complexe, débogage avancé, planification approfondie | Bogues délicats, travail d'architecture, tâches de type SWE | Trafic en ligne à fort QPS |
| xhigh | Recherche approfondie, travaux asynchrones, longues exécutions d'agents | Tâches en arrière-plan, rapports de recherche | Tout ce que vos évaluations ne justifient pas |
| max | Raisonnement maximal pour les tâches les plus difficiles | Utilisation de l'ordinateur, problèmes de niveau recherche, gros calculs hors ligne | Presque toutes les demandes quotidiennes |
OpenAI parle de l'effort comme d'« un bouton de réglage, pas le moyen principal de retrouver la qualité ». Quand les résultats sont mauvais, examinez d'abord le prompt, les définitions d'outils et le contexte. N'augmentez l'effort qu'ensuite.
Ce que disent les benchmarks sur chaque niveau
Ce sont les chiffres d'OpenAI, compilés par Vellum et DataCamp. Considérez-les comme un guide, pas comme une vérité absolue.
Pour le codage, high suffit généralement. Sur DeepSWE v1.1, 6.1 Sol en high obtient 75,2, égalant Astra en high (74,8), pour environ 1,50 $ par tâche. Sa courbe de coût atteint 72 % à 75 % pour un coût compris entre 0,50 $ et 1,50 $ par tâche. GPT-6 Sol, poussé au maximum, plafonnait à 68,8 pour environ 2,60 $.
Aller au-delà de medium n'aide pas toujours. Sur AutomationBench, 6.1 Sol obtient 35,4 % en medium et seulement environ 36,0 % avec un effort plus élevé. Pour l'automatisation métier, les tokens de raisonnement supplémentaires n'ont presque rien apporté.
Réservez max à l'utilisation de l'ordinateur et à la recherche. Sur OSWorld 2.0, max obtient 71,4 pour environ 1,30 $ par tâche. Terminal-Bench Science en max coûte 5,47 $ par tâche : bien moins cher que les 23,80 $ d'Astra, mais un ordre de grandeur au-dessus de la plupart des autres charges de travail.
Low s'est aussi amélioré. Le taux d'erreurs factuelles en low est passé de 11,4 % sur 6 Sol à 7,7 %. Si vous aviez relevé des tâches en medium sur 6 Sol parce que low n'était pas assez précis, réessayez low.
Points de départ selon le cas d'usage
| Cas d'usage | Point de départ | Remarques |
|---|---|---|
| Appels qui utilisaient none sur 6 Sol | low | Correspondance officielle d'OpenAI. Si la latence est critique, envisagez GPT-6 Luna, qui prend toujours en charge none |
| Appels qui utilisaient minimal | low | Commencez par low et comparez les résultats |
| Chatbots, support client | low | Demandez au modèle une introduction d'une ligne pour obtenir le premier token plus tôt |
| Q&R RAG | low → medium | La qualité de la recherche compte plus que l'effort |
| Assistant de codage dans l'IDE | medium | La valeur par défaut convient |
| Correction automatisée de bogues, agents SWE | high | DeepSWE montre que high égale déjà Astra |
| Utilisation de l'ordinateur, agents de navigation | high → max | OSWorld culmine avec max |
| Recherche en arrière-plan, longues exécutions | xhigh | Seulement lorsque les évaluations montrent un gain. Le traitement par lots divise le coût par deux si vous n'avez pas besoin des résultats immédiatement |
| Les problèmes de recherche les plus difficiles | max, ou simplement Astra | OpenAI recommande aussi Astra ici |
Les correspondances none et minimal proviennent du guide de migration vers GPT-6 d'OpenAI.
Changer l'effort en cours de conversation
Un schéma courant consiste à planifier en high, exécuter en low, et repasser en high quand quelque chose casse.
Le piège : modifier reasoning.effort dans la requête casse votre cache de prompt. L'effort fait partie du préfixe mis en cache (voir le guide sur la mise en cache des prompts). Sur 6.1 Sol, une lecture du cache coûte 0,10 $ par million de tokens, tandis que la réécriture du cache coûte 2,50 $. Cela représente une différence de 25×.
La famille GPT-6 règle ce problème grâce à un élément d'entrée configuration_update. Laissez le reasoning.effort au niveau de la requête inchangé et insérez une mise à jour avant le prochain message de l'utilisateur. Voici à quoi cela ressemble avec l'API Responses d'AIHubMix :
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["AIHUBMIX_API_KEY"],
base_url="https://aihubmix.com/v1",
)
# Turn 1: plan at high effort
r1 = client.responses.create(
model="gpt-6.1-sol",
reasoning={"effort": "high"},
input="Figure out why this repo's tests are failing and propose a fix plan.",
)
# Turn 2: drop to low for execution, without touching request-level effort
r2 = client.responses.create(
model="gpt-6.1-sol",
reasoning={"effort": "high"}, # unchanged, so the cache survives
previous_response_id=r1.id,
input=[
{"type": "configuration_update", "reasoning": {"effort": "low"}},
{"role": "user", "content": "Carry out step 1 of the plan."},
],
)
La forme deconfiguration_updateci-dessus est illustrative. Consultez le guide sur le raisonnement d'OpenAI pour le schéma exact. La documentation Responses d'AIHubMix liste actuellement quatre niveaux (de minimal à high), donc envoyez une petite requête de test pour confirmer quexhigh,maxetconfiguration_updatesont bien transmis.
Quelques limites à connaître :
- Cela ne fonctionne qu'en mode standard à agent unique, et cela ne modifie que l'effort.
- Deux mises à jour ne peuvent pas se suivre directement.
- Cela n'est pas compatible avec la compaction ou la troncature automatiques. La compaction explicite fonctionne, mais ajoutez une nouvelle mise à jour ensuite.
- Le champ
reasoning.effortde la réponse affiche toujours la valeur au niveau de la requête, donc ne vous y fiez pas trop.
Paramètres liés à l'effort
Laissez de la marge dans max_output_tokens. La limite inclut les tokens de raisonnement. Si elle est trop basse, le modèle peut s'arrêter avant de produire le moindre texte visible. Vous obtenez status: incomplete et vous payez quand même l'entrée et le raisonnement. OpenAI suggère de réserver au moins 25 000 tokens pour commencer, et davantage pour xhigh ou max.
Suivez les tokens de raisonnement. Ils se trouvent dans usage.output_tokens_details.reasoning_tokens. Observer leur répartition par niveau d'effort vaut mieux que de régler à l'intuition.
Activez les résumés si vous avez besoin de visibilité. reasoning.summary: "auto" renvoie un résumé du raisonnement du modèle (il se peut que vous deviez d'abord vérifier votre organisation). Le raisonnement brut n'est jamais exposé.
Le mode Pro est un interrupteur séparé. Il fait travailler le modèle davantage, facturé aux tarifs standard mais avec plus de tokens au total. Utilisez-le pour les problèmes difficiles lorsqu'une latence supplémentaire est acceptable.
Un processus de réglage que vous pouvez réellement appliquer
- Constituez un jeu d'évaluation de 20 à 50 tâches réelles.
- Lancez une référence en
medium. Notez le taux de réussite, la moyenne des tokens de raisonnement et la latence P95. - Essayez
low. Si le taux de réussite baisse à peine, passez à ce niveau. - Essayez
high. Si le taux de réussite s'améliore nettement, utilisez high pour ce type de tâche uniquement. - Ne recourez à
xhighoumaxque lorsque high ne suffit pas, et comparez aussi avec GPT-6 Astra en high. Parfois, un modèle plus grand bat un effort supplémentaire. Sur AIHubMix, il suffit de changer le paramètremodel, et la liste des modèles indique ce qui est disponible. - Répartissez les requêtes par type de tâche plutôt que d'utiliser un réglage global unique.
En résumé : commencez en medium, économisez avec low, utilisez high pour le codage, et faites en sorte que xhigh et max fassent leurs preuves dans vos évaluations.
À suivre : ce que signifie réellement le prix de 2 $ / 10 $ une fois la mise en cache, les contextes longs et les multiplicateurs de facturation pris en compte.
FAQ
Quel est l'effort de raisonnement par défaut pour GPT-6.1 Sol ? medium. Si vous ne le définissez pas, c'est celui qui s'applique.
Pourquoi none renvoie-t-il une erreur ? 6.1 Sol ne prend pas en charge none ni minimal. OpenAI recommande de passer à low. Si vous avez vraiment besoin de none, restez sur GPT-6 Sol ou GPT-6 Luna.
Comment les tokens de raisonnement sont-ils facturés ? Au tarif de sortie (10 $ par million pour 6.1 Sol), et ils comptent dans la fenêtre de contexte. Consultez usage.output_tokens_details.reasoning_tokens pour les chiffres réels.
Le nom du paramètre est-il le même dans Chat Completions et Responses ? Non. Chat Completions utilise un reasoning_effort au niveau racine. Responses utilise un reasoning: {"effort": ...} imbriqué. Les confondre renvoie Unsupported parameter.
Un effort plus élevé donne-t-il toujours de meilleurs résultats ? Non. Sur AutomationBench, dépasser medium n'a fait passer le score que de 35,4 % à environ 36,0 %, tout en coûtant nettement plus cher. Testez sur vos propres tâches.
Puis-je changer l'effort en cours de conversation ? Oui. Utilisez un élément configuration_update et laissez le reasoning.effort de la requête inchangé pour que le cache de prompt reste valide. Cela ne fonctionne pas avec la compaction ou la troncature automatiques.
Pourquoi ai-je obtenu status: incomplete sans sortie ? Très probablement parce que max_output_tokens était trop bas et que le raisonnement l'a entièrement consommé. OpenAI recommande de réserver au moins 25 000 tokens.
À lire ensuite : la série GPT-6.1 Sol
- Quelle part de votre facture représente le raisonnement ? L'effort n'est qu'un levier. La mise en cache, le seuil de 272K et les remises Batch influencent tous le montant final. Voir Ce que GPT-6.1 Sol coûte vraiment : au-delà du prix de 2 $ / 10 $.
- Code qui utilisait
none? Passer àlown'est que le début. Les appels d'outils, les paramètres d'échantillonnage et les réglages de cache doivent aussi être modifiés : Migrer vers GPT-6.1 Sol : 9 choses qui peuvent mal tourner. - Dans quelle mesure 6.1 Sol est-il meilleur que 6 Sol et Astra ? Caractéristiques et benchmarks côte à côte dans GPT-6.1 Sol vs GPT-6 Sol : une mise à niveau d'une semaine qui rattrape presque Astra.
