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 est désormais le plancher.
Ce seul paramètre influence à la fois la latence et le coût. Vous ne voyez jamais les jetons 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. Choisissez le mauvais niveau et vous pouvez facilement payer plusieurs fois plus que nécessaire.
À quoi sert chaque niveau
Ce tableau combine les descriptions d'OpenAI issues du guide de raisonnement avec nos propres recommandations :
| Niveau | Description d'OpenAI | Bon ajustement | Mauvais ajustement |
|---|---|---|---|
| low | Raisonnement efficace avec une augmentation modeste de la latence | Étapes intermédiaires dans les boucles d'outils, recherche, planification légère, classification, extraction, réponses de support | Débogage difficile, refactorisations multi-fichiers |
| medium (par défaut) | Le réglage équilibré pour la plupart des charges de travail | Codage quotidien, révision de code, rédaction, tâches typiques d'agent | Utilisation interactive critique en termes de latence |
| high | Raisonnement difficile, débogage complexe, planification approfondie | Bugs délicats, travail d'architecture, tâches de style SWE | Trafic en ligne à haut QPS |
| xhigh | Recherche approfondie, travail asynchrone, longues exécutions d'agents | Travaux en arrière-plan, rapports de recherche | Tout ce que vos évaluations n'ont pas justifié |
| max | Raisonnement maximum pour les tâches les plus difficiles | Utilisation informatique, problèmes de niveau recherche, levée de charges lourdes hors ligne | Presque toutes les demandes quotidiennes |
OpenAI appelle l'effort "un bouton de réglage, pas le moyen principal de récupérer la qualité." Lorsque les résultats sont mauvais, examinez d'abord l'invite, les définitions d'outils et le contexte. Augmentez l'effort seulement après cela.
Ce que les benchmarks disent de chaque niveau
Ce sont les propres chiffres d'OpenAI, compilés par Vellum et DataCamp. Considérez-les comme un guide, pas comme une vérité absolue.
Pour le codage, un niveau élevé est généralement suffisant. Sur DeepSWE v1.1, 6.1 Sol à un niveau élevé obtient un score de 75.2, égalant Astra à un niveau élevé (74.8), pour environ 1,50 $ par tâche. Sa courbe de coût atteint 72 % à 75 % pour entre 0,50 $ et 1,50 $ par tâche. GPT-6 Sol a atteint un maximum de 68.8 pour environ 2,60 $.
Augmenter au-dessus de moyen n'aide pas toujours. Sur AutomationBench, 6.1 Sol obtient 35.4 % à moyen et seulement environ 36.0 % à un effort plus élevé. Pour l'automatisation des entreprises, les jetons de raisonnement supplémentaires n'ont presque rien apporté.
Réservez le maximum pour l'utilisation informatique et la recherche. Sur OSWorld 2.0, le maximum obtient 71.4 à environ 1,30 $ par tâche. Terminal-Bench Science au maximum coûte 5,47 $ par tâche : bien moins cher que les 23,80 $ d'Astra, mais d'un ordre de grandeur supérieur à la plupart des autres charges de travail.
Le faible niveau s'est également amélioré. Le taux d'erreur factuelle au niveau faible est passé de 11,4 % sur 6 Sol à 7,7 %. Si vous avez augmenté les tâches à moyen sur 6 Sol parce que le faible n'était pas assez précis, essayez à nouveau le faible.
Points de départ par cas d'utilisation
| Cas d'utilisation | Commencer à | Remarques |
|---|---|---|
| Appels qui utilisaient aucun sur 6 Sol | low | Cartographie officielle d'OpenAI. Si la latence est critique, envisagez GPT-6 Luna, qui prend toujours en charge aucun |
| Appels qui utilisaient minimal | low | Commencez par faible et comparez les résultats |
| Chatbots, support client | low | Demandez au modèle une préface d'une ligne pour obtenir le premier jeton plus tôt |
| RAG Q&A | low → medium | La qualité de récupération compte plus que l'effort |
| Assistant de codage IDE | medium | Le réglage par défaut fonctionne |
| Correction de bugs automatisée, agents SWE | high | DeepSWE montre que le niveau élevé correspond déjà à Astra |
| Utilisation informatique, agents de navigateur | high → max | OSWorld atteint son maximum |
| Recherche en arrière-plan, longues exécutions | xhigh | Seulement lorsque les évaluations montrent un gain. Le traitement par lots divise le coût si vous n'avez pas besoin de résultats tout de suite |
| Les problèmes de recherche les plus difficiles | max, ou utilisez simplement Astra | OpenAI recommande également Astra ici |
Les none et minimal mappings proviennent du guide de migration GPT-6 d'OpenAI.
Changer l'effort en cours de conversation
Un schéma courant consiste à planifier à un niveau élevé, à exécuter à un niveau faible, puis à revenir à un niveau élevé lorsque quelque chose se casse.
Le hic : modifier reasoning.effort dans la requête casse votre cache d'invite. L'effort fait partie du préfixe mis en cache (voir le guide de mise en cache des invites). Sur 6.1 Sol, une lecture du cache coûte 0,10 $ par million de jetons, tandis que réécrire le cache coûte 2,50 $. C'est une différence de 25×.
La famille GPT-6 corrige cela avec 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 via le API des réponses AIHubMix :
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["AIHUBMIX_API_KEY"],
base_url="https://aihubmix.com/v1",
)
# Tour 1 : planifier à un effort élevé
r1 = client.responses.create(
model="gpt-6.1-sol",
reasoning={"effort": "high"},
input="Déterminez pourquoi les tests de ce dépôt échouent et proposez un plan de correction.",
)
# Tour 2 : passer à faible pour l'exécution, sans toucher à l'effort au niveau de la requête
r2 = client.responses.create(
model="gpt-6.1-sol",
reasoning={"effort": "high"}, # inchangé, donc le cache survit
previous_response_id=r1.id,
input=[
{"type": "configuration_update", "reasoning": {"effort": "low"}},
{"role": "user", "content": "Réalisez l'étape 1 du plan."},
],
)
L'élémentconfiguration_updateci-dessus est illustratif. Consultez le guide de raisonnement d'OpenAI pour le schéma exact. La documentation des réponses d'AIHubMix répertorie actuellement quatre niveaux (minimal à élevé), donc envoyez une petite requête de test pour confirmer quexhigh,max, etconfiguration_updatepassent.
Quelques limites à connaître :
- Il ne fonctionne qu'en mode standard à agent unique, et il ne change que l'effort.
- Deux mises à jour ne peuvent pas être côte à côte.
- Il ne se mélange pas avec la compression automatique ou la troncature. La compression explicite est acceptable, mais ajoutez une nouvelle mise à jour par la suite.
- Le champ
reasoning.effortde la réponse montre toujours la valeur au niveau de la requête, donc ne l'interprétez pas trop.
Paramètres qui vont avec l'effort
Laissez de la place dans max_output_tokens. Le plafond inclut les jetons de raisonnement. Si vous le définissez trop bas, le modèle peut s'arrêter avant de produire du texte visible. Vous obtiendrez status: incomplete et paierez toujours pour l'entrée et le raisonnement. OpenAI suggère de réserver au moins 25 000 jetons pour commencer, et plus pour xhigh ou max.
Suivez les jetons de raisonnement. Ils se trouvent dans usage.output_tokens_details.reasoning_tokens. Examiner la distribution par niveau d'effort est plus efficace que de régler par intuition.
Activez les résumés si vous avez besoin de visibilité. reasoning.summary: "auto" renvoie un résumé du raisonnement du modèle (vous devrez peut-être 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 jetons au total. Utilisez-le pour des problèmes difficiles où une latence supplémentaire est acceptable.
Un processus de réglage que vous pouvez réellement exécuter
- Rassemblez 20 à 50 tâches réelles dans un ensemble d'évaluation.
- Exécutez une référence à
medium. Enregistrez le taux de réussite, le nombre moyen de jetons de raisonnement et la latence P95. - Essayez
low. Si le succès diminue à peine, changez. - Essayez
high. Si le succès s'améliore clairement, utilisez le niveau élevé uniquement pour ce type de tâche. - Ne visez
xhighoumaxque lorsque le niveau élevé est insuffisant, et comparez avec GPT-6 Astra à un niveau élevé pendant que vous y êtes. Parfois, un modèle plus grand surpasse un effort plus important. Sur AIHubMix, il suffit de changer le paramètremodel, et la liste des modèles montre ce qui est disponible. - Dirigez par type de tâche au lieu d'utiliser un seul réglage global.
En résumé : commencez par moyen, économisez de l'argent avec faible, utilisez élevé pour le codage, et faites en sorte que xhigh et max prouvent leur valeur dans vos évaluations.
Prochain sujet : ce que signifie réellement l'étiquette de prix de 2 $ / 10 $ une fois que la mise en cache, le long contexte et les multiplicateurs de facturation entrent en jeu.
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 ce que vous obtenez.
Pourquoi none renvoie-t-il une erreur ? 6.1 Sol ne prend pas en charge none ou minimal. OpenAI recommande de passer à low. Si vous avez vraiment besoin de none, restez sur GPT-6 Sol ou GPT-6 Luna.
Comment les jetons de raisonnement sont-ils facturés ? Au tarif de sortie (10 $ par million pour 6.1 Sol), et ils comptent contre la fenêtre de contexte. Vérifiez 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 de premier niveau. Responses utilise un reasoning: {"effort": ...} imbriqué. Les mélanger renvoie Unsupported parameter.
Un effort plus élevé donne-t-il toujours de meilleurs résultats ? Non. Sur AutomationBench, aller au-delà de moyen n'a fait passer le score que de 35,4 % à environ 36,0 %, tout en coûtant sensiblement plus. 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 au niveau de la requête inchangé pour que le cache d'invite reste valide. Cela ne fonctionne pas avec la compression automatique ou la troncature.
Pourquoi ai-je obtenu status: incomplete sans sortie ? Il est très probable que max_output_tokens était trop bas et que le raisonnement l'ait entièrement utilisé. OpenAI recommande de réserver au moins 25 000 jetons.
Continuez à lire : la série GPT-6.1 Sol
- Combien de votre facture est due au raisonnement ? L'effort n'est qu'un levier. La mise en cache, le seuil de 272K et les remises par lots influencent tous le chiffre final. Voir Ce que coûte réellement GPT-6.1 Sol : Au-delà de l'étiquette de 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 paramètres de cache nécessitent également des modifications : Migration vers GPT-6.1 Sol : 9 choses qui peuvent mal tourner. - À quel point 6.1 Sol est-il meilleur que 6 Sol et Astra ? Spécifications 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.
