Choisir un niveau d'effort de raisonnement pour GPT-6.1 Sol : faible à maximum

GPT-6.1 Sol propose cinq niveaux d'effort de raisonnement : faible, moyen (le par défaut), élevé, très élevé, et maximum. Le grand changement par rapport à GPT-6 Sol est que aucun et minimal sont disparus, donc faible est désormais le niveau de base.

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 l'espace dans la fenêtre de contexte. Choisissez le mauvais niveau et vous pouvez facilement payer plusieurs fois plus que nécessaire.

Ce que chaque niveau représente

Ce tableau combine les descriptions d'OpenAI issues du guide de raisonnement avec nos propres recommandations :

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 des 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, élevé est généralement suffisant. Sur DeepSWE v1.1, 6.1 Sol à élevé obtient 75.2, égalant Astra à é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 $.

Aller au-delà 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 affaires, 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 au-dessus de la plupart des autres charges de travail.

Le faible s'est également amélioré. Le taux d'erreur factuelle à faible est tombé de 11,4 % sur 6 Sol à 7,7 %. Si vous avez augmenté les tâches à moyen sur 6 Sol parce que faible n'était pas assez précis, essayez à nouveau faible.

Points de départ par cas d'utilisation

Les aucun et minimal proviennent de la documentation 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 échoue.

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 à travers 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": "élevé"},
    input="Comprendre pourquoi les tests de ce dépôt échouent et proposer 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": "élevé"},           # inchangé, donc le cache survit
    previous_response_id=r1.id,
    input=[
        {"type": "configuration_update", "reasoning": {"effort": "faible"}},
        {"role": "user", "content": "Réalisez l'étape 1 du plan."},
    ],
)

L'élément configuration_update ci-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 que très élevé, maximum, et configuration_update passent.

Quelques limites à connaître :

• Cela ne fonctionne qu'en mode standard à agent unique, et cela ne change que l'effort.
• Deux mises à jour ne peuvent pas être côte à côte.
• Ça ne se mélange pas avec la compression ou la troncature automatiques. La compression explicite est acceptable, mais ajoutez une nouvelle mise à jour par la suite.
• Le champ reasoning.effort de 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 très élevé ou maximum.

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 instinct.

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 standards 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

1. Rassemblez 20 à 50 tâches réelles dans un ensemble d'évaluation.
2. Exécutez une référence à moyen. Enregistrez le taux de réussite, le nombre moyen de jetons de raisonnement et la latence P95.
3. Essayez faible. Si le succès diminue à peine, changez.
4. Essayez élevé. Si le succès s'améliore clairement, utilisez élevé uniquement pour ce type de tâche.
5. Ne visez très élevé ou maximum que lorsque élevé ne suffit pas, et comparez avec GPT-6 Astra à élevé pendant que vous y êtes. Parfois, un modèle plus grand surpasse un effort plus important. Sur AIHubMix, cela ne nécessite qu'un changement au paramètre model, et la liste des modèles montre ce qui est disponible.
6. Dirigez par type de tâche au lieu d'utiliser un seul paramètre global.

En résumé : commencez par moyen, économisez de l'argent avec faible, utilisez élevé pour le codage, et faites prouver très élevé et maximum dans vos évaluations.

Prochain sujet : ce que signifie vraiment 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 ? moyen. Si vous ne le définissez pas, c'est ce que vous obtenez.

Pourquoi aucun renvoie-t-il une erreur ? 6.1 Sol ne prend pas en charge aucun ou minimal. OpenAI recommande de passer à faible. Si vous avez vraiment besoin de aucun, 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 niveau supérieur. Responses utilise un reasoning: {"effort": ...} nested. 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 visiblement 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é afin que le cache d'invite reste valide. Cela ne fonctionne pas avec la compression ou la troncature automatiques.

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

• Quelle part 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 vraiment GPT-6.1 Sol : Au-delà de l'étiquette de prix de 2 $ / 10 $.
• Code qui utilisait aucun ? Passer à faible n'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.

Sources

• OpenAI : Guide de raisonnement
• OpenAI : Guide de migration GPT-6
• AIHubMix : GPT-6.1 Sol
• AIHubMix : Documentation de l'API des réponses
• Vellum : Explication des benchmarks de GPT-6.1 Sol