For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale
Theme

Suggestions

Choisissez un modèle

Texte et code

Rédaction de prompts

Raisonnement

Images

Temps réel et audio

Modèles spécialisés

Tableau de bord de l’API
Essayez ChatGPT

Modèles de raisonnement

Découvrez comment fonctionnent les modèles de raisonnement et comment les utiliser efficacement.

Les modèles de raisonnement utilisent des tokens de raisonnement internes avant de produire une réponse. Ces tokens aident le modèle à planifier son travail, à utiliser efficacement les outils, à examiner différentes approches, à lever les ambiguïtés et à accomplir des tâches plus difficiles en plusieurs étapes. Les modèles de raisonnement sont particulièrement efficaces pour résoudre des problèmes complexes, programmer, mener un raisonnement scientifique et exécuter des workflows agentiques en plusieurs étapes. Ce sont aussi les meilleurs modèles pour Codex CLI, notre agent de programmation léger.

Pour la plupart des tâches de raisonnement, commencez par gpt-6-astra. Pour réduire les coûts, envisagez gpt-5.6-terra, ou choisissez gpt-5.6-luna pour obtenir le coût et la latence les plus faibles. Si vous utilisez un modèle GPT-5.6 ou GPT-6, consultez la section sur le mode de raisonnement pour découvrir l’option pro.

Les modèles de raisonnement fonctionnent mieux avec l’API Responses. L’API Chat Completions reste prise en charge, mais avec Responses, le modèle raisonne mieux et offre de meilleures performances.

Premier appel à un modèle de raisonnement

Appelez l’API Responses en précisant le modèle et l’effort de raisonnement souhaités :

Utilisation d’un modèle de raisonnement avec l’API Responses
from openai import OpenAI

client = OpenAI()

prompt = """
Write a bash script that takes a matrix represented as a string with
format '[1,2],[3,4],[5,6]' and prints the transpose in the same format.
"""

response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "low"},
    input=[{"role": "user", "content": prompt}],
)

print(response.output_text)

Effort de raisonnement

Le paramètre reasoning.effort indique au modèle l’effort de raisonnement à consacrer à une tâche.

Les valeurs prises en charge dépendent du modèle et peuvent inclure none, minimal, low, medium, high, xhigh et max. Un effort faible privilégie la rapidité et réduit la consommation de tokens. Avec un effort plus élevé, le modèle approfondit son raisonnement pour fournir des réponses de meilleure qualité. Quel que soit le niveau d’effort, le modèle adapte aussi son raisonnement à la tâche : il utilise moins de tokens pour les tâches simples et réfléchit davantage pour les tâches complexes.

GPT-6 Astra ne prend pas en charge le niveau d’effort none. Si vous définissez reasoning.effort (Responses) ou reasoning_effort (Chat Completions) sur none, l’API renvoie une erreur HTTP 400. GPT-6.1 Sol ne prend en charge ni none ni minimal et utilise medium par défaut.

Utilisez l’API Responses pour les appels de fonction. Chat Completions ne prend pas en charge les appels de fonction avec GPT-6 Astra ou GPT-6.1 Sol.

Les valeurs par défaut dépendent elles aussi du modèle. gpt-5.5 utilise par défaut le niveau d’effort medium. C’est le meilleur point de départ pour tirer parti de l’équilibre qu’offre gpt-5.5 entre qualité, fiabilité et performances.

Effort Cas d’usage privilégiés
none Tâches pour lesquelles la latence est critique et qui ne tirent aucun bénéfice du raisonnement ni d’une succession d’appels d’outils. Si la latence est importante pour votre application avec gpt-5.5, nous vous recommandons de commencer par low, puis de passer à none si nécessaire.

Exemples courants : applications vocales, recherche rapide d’informations et classification.
low Raisonnement efficace avec une légère augmentation de la latence. Idéal pour les tâches qui nécessitent des outils, de la planification, des recherches ou des décisions en plusieurs étapes, tout en privilégiant la rapidité et la maîtrise des coûts.

Exemples courants : analyse de données, rédaction, programmation axée sur la mise en œuvre et workflows d’assistance client ou d’assistants conversationnels.
medium Tâches où la qualité et la fiabilité comptent et qui font appel à la planification, à un raisonnement complexe et au discernement. C’est le réglage par défaut pour la plupart des tâches. Il offre un bon compromis sur la courbe de Pareto entre latence, performances et coût.

Exemples courants : programmation agentique, recherche, travail sur des feuilles de calcul et des présentations, et délégation de tâches de longue durée.
high Raisonnements difficiles, débogage complexe, planification approfondie et tâches à forte valeur ajoutée pour lesquelles la qualité et les capacités du modèle priment sur la latence. Ce niveau est recommandé pour les workflows complexes et les tâches agentiques.

Exemples courants : programmation agentique, recherches de longue durée et travail intellectuel. Selon la complexité de la tâche, évaluez à la fois medium et high.
xhigh Recherche approfondie, workflows asynchrones et tâches agentiques de longue durée. Utilisez ce niveau uniquement si vos évaluations montrent un gain clair qui justifie la latence et le coût supplémentaires.

Exemples courants : audits de sécurité et revues de code, tâches de productivité en entreprise, recherches plus poussées et workflows de programmation exigeants.
max Effort de raisonnement maximal pour vos tâches les plus complexes. Si vous utilisez actuellement xhigh, vérifiez si max améliore les performances.

Pour afficher le premier token plus rapidement dans les applications sensibles à la latence, demandez au modèle de générer un court préambule avant d’approfondir son raisonnement.

Certains modèles ne prennent en charge qu’une partie de ces valeurs. Consultez la page du modèle concerné avant de choisir un réglage.

Mode de raisonnement

Les modèles GPT-5.6 et GPT-6 prennent en charge les modes de raisonnement standard et pro dans l’API Responses. Le mode standard est activé par défaut. Définissez reasoning.mode sur pro pour les tâches difficiles qui demandent davantage de travail au modèle et pour lesquelles une latence et une consommation de tokens plus élevées sont acceptables.

Le mode et l’effort de raisonnement sont indépendants. Le mode détermine si l’exécution se fait en mode standard ou Pro, tandis que reasoning.effort règle l’effort de raisonnement du modèle dans le mode choisi. Si vous omettez reasoning.effort, GPT-5.6 utilise medium par défaut dans les deux modes. GPT-6.1 Sol, GPT-6 Sol et GPT-6 Luna utilisent également medium par défaut.

Utilisation du mode de raisonnement Pro
curl https://api.openai.com/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-6.1-sol",
    "reasoning": {
      "mode": "pro",
      "effort": "medium"
    },
    "input": "Review this database migration plan and identify potential failure modes."
  }'

Le mode Pro comptabilise l’ensemble du travail effectué par le modèle pour produire la réponse finale et facture les tokens correspondants aux tarifs standard par token du modèle sélectionné. En mode Pro, le modèle effectue davantage de travail qu’en mode standard, ce qui augmente la consommation de tokens et le coût. Les identifiants de modèles Pro existants conservent leur comportement et leur tarification actuels.

Fonctionnement du raisonnement

En plus des tokens d’entrée et de sortie, les modèles de raisonnement utilisent des tokens de raisonnement. Ils s’en servent pour « réfléchir » : ils décomposent le prompt et envisagent plusieurs façons d’y répondre. Nos modèles de raisonnement, comme gpt-5.5 et gpt-5.4, peuvent alterner raisonnement et génération de contenu. Ils peuvent ainsi produire des tokens de sortie visibles avant de commencer à réfléchir et entre deux étapes de raisonnement, mais aussi réfléchir entre deux appels d’outils.

Dans une conversation en plusieurs étapes, les modèles sortis avant GPT-5.6 reprennent par défaut les tokens d’entrée et de sortie de chaque étape sans intégrer le raisonnement des tours précédents au contexte de la génération suivante. Les modèles GPT-5.6 y intègrent par défaut le raisonnement disponible des tours précédents. Utilisez reasoning.context pour choisir l’un ou l’autre comportement sur les modèles qui le permettent.

Tokens de raisonnement dans le contexte du tour en cours

Les tokens de raisonnement ne sont pas visibles via l’API, mais ils occupent de la place dans la fenêtre de contexte du modèle et sont facturés comme des tokens de sortie.

Maîtrise des coûts

Pour maîtriser les coûts des modèles de raisonnement, vous pouvez limiter le nombre total de tokens générés par le modèle à l’aide du paramètre max_output_tokens. Cette limite couvre les tokens de raisonnement, les tokens de sortie visibles et les tokens de mise en forme invisibles. Consultez la section sur le décompte des tokens de sortie pour savoir comment les tokens générés sont pris en compte dans la consommation et les limites de sortie.

Gestion de la fenêtre de contexte

Lors de la création d’une réponse, prévoyez suffisamment d’espace dans la fenêtre de contexte pour les tokens de raisonnement. Selon la complexité du problème, le modèle peut en générer de quelques centaines à plusieurs dizaines de milliers. Le nombre exact de tokens de raisonnement utilisés figure dans l’objet de suivi de la consommation de la réponse, sous output_tokens_details :

{
  "usage": {
    "input_tokens": 75,
    "input_tokens_details": {
      "cached_tokens": 0
    },
    "output_tokens": 1186,
    "output_tokens_details": {
      "reasoning_tokens": 1024
    },
    "total_tokens": 1261
  }
}

La page de référence des modèles indique la taille des fenêtres de contexte. Cette taille varie selon la version du modèle.

Espace à réserver au raisonnement

Si les tokens générés atteignent la limite de la fenêtre de contexte ou la valeur de max_output_tokens que vous avez définie, vous recevez une réponse dont le champ status vaut incomplete. Dans incomplete_details, le champ reason vaut alors max_output_tokens. La limite peut être atteinte avant même la production du premier token de sortie visible. Des tokens d’entrée et de raisonnement peuvent donc vous être facturés sans que vous receviez de réponse visible.

Pour éviter cette situation, vérifiez que la fenêtre de contexte offre suffisamment d’espace ou augmentez la valeur de max_output_tokens. OpenAI recommande de réserver au moins 25 000 tokens au raisonnement et à la sortie lors de vos premiers essais avec ces modèles. Une fois que vous connaissez le nombre de tokens de raisonnement nécessaire pour vos prompts, vous pouvez ajuster cette marge.

Gestion des réponses incomplètes
from openai import OpenAI

client = OpenAI()

prompt = """
Write a bash script that takes a matrix represented as a string with
format '[1,2],[3,4],[5,6]' and prints the transpose in the same format.
"""

response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "medium"},
    input=[{"role": "user", "content": prompt}],
    max_output_tokens=300,
)

if (
    response.status == "incomplete"
    and response.incomplete_details.reason == "max_output_tokens"
):
    print("Ran out of tokens")
    if response.output_text:
        print("Partial output:", response.output_text)
    else:
        print("Ran out of tokens during reasoning")

Conservation du raisonnement entre les appels

L’état de la conversation et l’état du raisonnement remplissent deux fonctions distinctes. En transmettant les messages d’un appel à l’autre, vous donnez au modèle accès à l’historique visible de la conversation. Sur les modèles compatibles, la conservation du raisonnement permet également d’intégrer au contexte suivant les éléments de raisonnement compatibles des tours précédents.

La conservation du raisonnement assure la continuité entre les tours sans exposer le raisonnement brut du modèle. Les éléments de raisonnement restent opaques et l’API ne renvoie pas le texte qu’ils contiennent. Définissez reasoning.context pour choisir les éléments de raisonnement disponibles que le modèle peut utiliser :

La famille de modèles GPT-5.6 prend en charge all_turns et l’utilise par défaut. Les modèles antérieurs utilisent current_turn par défaut. GPT-6.1 Sol prend également en charge all_turns. Omettez reasoning.context ou définissez-le sur auto pour utiliser le réglage par défaut du modèle sélectionné.

Valeur Comportement
auto Utilise le réglage par défaut du modèle sélectionné. Omettre reasoning.context revient à choisir auto.
current_turn Rend disponible le raisonnement du tour en cours sans intégrer celui des tours précédents au contexte de la génération suivante.
all_turns Intègre au contexte de la génération suivante les éléments de raisonnement disponibles et compatibles des tours précédents. Les modèles GPT-5.6 et GPT-6.1 Sol prennent en charge cette valeur.

Le champ reasoning.context de la réponse indique le mode effectivement utilisé : current_turn ou all_turns. Vérifiez ce champ dans chaque réponse pour confirmer le mode utilisé par le modèle. Ce réglage ne crée aucun élément de raisonnement supplémentaire.

all_turns n’a d’effet que si la requête a accès aux éléments des réponses précédentes. Utilisez previous_response_id, associez la réponse à une conversation ou retransmettez manuellement l’historique complet des réponses. Lors de la première requête, current_turn et all_turns ont le même effet puisqu’il n’existe aucun raisonnement antérieur.

Seuls les modèles d’une même famille peuvent réutiliser le raisonnement conservé. Par exemple, gpt-5.6-sol, gpt-5.6-terra et gpt-5.6-luna peuvent chacun réutiliser le raisonnement des deux autres, mais le raisonnement ne se transmet pas entre les familles GPT-5.6 et GPT-5.5.

Lorsque vous changez de famille de modèles, l’API exclut du contexte du modèle les éléments de raisonnement incompatibles, même si reasoning.context vaut all_turns.

Poursuite du raisonnement à partir des réponses stockées

Pour l’intégration avec état la plus simple, utilisez previous_response_id :

Conservation du raisonnement à partir d’une réponse précédente
from openai import OpenAI

client = OpenAI()
model = "gpt-6.1-sol"

first = client.responses.create(
    model=model,
    input="Inspect this repository and identify the likely bug.",
    reasoning={"context": "current_turn"},
)

second = client.responses.create(
    model=model,
    previous_response_id=first.id,
    input="Now patch the bug and explain the change.",
    reasoning={"context": "all_turns"},
)

print(second.output_text)

Utilisez current_turn lorsque vous retransmettez des éléments de réponses antérieures dont le modèle n’a plus besoin. Les éléments de raisonnement correspondants peuvent rester dans le corps de la requête API pour assurer la continuité, mais le service ne les intègre pas au contexte de la nouvelle génération. Vous pouvez ainsi réduire la taille du contexte utilisé dans les workflows de longue durée.

Conservation du raisonnement sans stockage des réponses

Lorsque vous créez une réponse en mode sans état, les éléments de raisonnement du tableau output de la réponse contiennent par défaut une propriété encrypted_content. Le mode sans état s’applique lorsque store vaut false ou que votre organisation applique une politique de non-conservation des données (ZDR). Pour des raisons de compatibilité, l’API accepte toujours l’ancienne valeur reasoning.encrypted_content dans include, mais elle ne l’exige plus.

La requête suivante renvoie le contenu chiffré du raisonnement sans que vous ayez à préciser include :

curl https://api.openai.com/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-6-astra",
    "store": false,
    "reasoning": {"effort": "medium"},
    "input": "What is the weather like today?",
    "tools": [ ... function config here ... ]
  }'

Les éléments de raisonnement du tableau output contiennent une propriété encrypted_content qui regroupe les tokens de raisonnement chiffrés. Vous pouvez les transmettre lors d’appels ultérieurs.

Pour utiliser all_turns avec store: false, conservez chaque élément de sortie, ajoutez le message utilisateur suivant et retransmettez l’historique complet :

Conservation du raisonnement sans stockage des réponses
from openai import OpenAI

client = OpenAI()
model = "gpt-6.1-sol"

history = [
    {
        "role": "user",
        "content": "Inspect this repository and identify the likely bug.",
    }
]

first = client.responses.create(
    model=model,
    store=False,
    input=history,
    reasoning={"context": "current_turn"},
)

# Keep every output item, including encrypted reasoning and assistant phase.
history.extend(item.to_dict() for item in first.output)
history.append(
    {
        "role": "user",
        "content": "Now patch the bug and explain the change.",
    }
)

second = client.responses.create(
    model=model,
    store=False,
    input=history,
    reasoning={"context": "all_turns"},
)

print(second.output_text)

Maintien des éléments de raisonnement dans le contexte

Lorsque vous utilisez l’appel de fonction avec un modèle de raisonnement dans l’API Responses, renvoyez les éléments de raisonnement reçus avec les appels de fonction en même temps que les sorties des outils. Le modèle peut ainsi poursuivre son raisonnement après un appel d’outil.

Pour transmettre les éléments de raisonnement d’un appel à l’autre, utilisez previous_response_id. Si vous gérez vous-même l’historique de la conversation, incluez l’entrée initiale et tous les éléments de sortie de chaque réponse dans l’entrée de la requête suivante. Conservez ces éléments dans leur ordre d’origine et ajoutez les nouveaux éléments à la fin.

Avec les modèles de pointe récents, si vous modifiez l’historique qui précède un élément de raisonnement, l’API peut exclure le raisonnement correspondant du contexte. Consultez le guide Conservez le préfixe intact pour savoir comment modifier les instructions et les sorties des outils et comment gérer les longues conversations.

Modification du raisonnement en cours de conversation

Utilisez configuration_update pour augmenter l’effort de raisonnement lors des tâches difficiles ou le réduire pour les demandes de suivi courantes. Insérez la mise à jour entre deux réponses en conservant la valeur de reasoning.effort définie au niveau de la requête. Vous préservez ainsi le préfixe du prompt initial pour la mise en cache des prompts.

Avec les modèles compatibles de la génération GPT-6 ou d’une génération ultérieure, vous pouvez modifier l’effort de raisonnement et le format de réponse en mode standard avec un seul agent.

Ajoutez l’élément suivant avant le prochain message utilisateur dans le tableau input d’une requête HTTP à l’API Responses ou d’une requête WebSocket response.create :

{
  "type": "configuration_update",
  "reasoning": {
    "effort": "high"
  }
}

Par exemple, si la conversation commence avec un effort réglé sur low au niveau de la requête, cette mise à jour sélectionne high pour la réponse suivante et toutes les réponses ultérieures, jusqu’à ce qu’une autre mise à jour remplace ce réglage.

Augmentation de l’effort de raisonnement pour une demande de suivi
from openai import OpenAI

client = OpenAI()
model = "gpt-6-astra"

response = client.responses.create(
    model=model,
    reasoning={"effort": "low"},
    input="Draft a database migration plan.",
    store=True,
)
print(response.output_text)

response = client.responses.create(
    model=model,
    previous_response_id=response.id,
    reasoning={"effort": "low"},
    input=[
        {
            "type": "configuration_update",
            "reasoning": {"effort": "high"},
        },
        {
            "role": "user",
            "content": "Analyze the failure modes and propose rollback steps.",
        },
    ],
    store=True,
)
print(response.output_text)

Conservez les mises à jour avec previous_response_id ou retransmettez-les à leur position d’origine si vous gérez manuellement l’historique de la conversation. Le champ reasoning.effort de la réponse continue d’indiquer le réglage défini au niveau de la requête, même si la mise à jour a sélectionné un autre niveau d’effort.

Vous pouvez définir reasoning.effort et text.format dans le même élément configuration_update. Si vous modifiez un seul de ces paramètres, l’autre conserve sa valeur.

Ne combinez pas les mises à jour de configuration avec le compactage automatique ou la troncature automatique. Le point de terminaison autonome /responses/compact rejette également les historiques qui contiennent ces mises à jour.

Vous pouvez néanmoins déclencher explicitement le compactage de l’historique en incluant un élément compaction_trigger dans une requête /responses. Après le compactage, ajoutez un nouvel élément configuration_update avant le prochain message utilisateur. Indiquez-y de nouveau la valeur de chaque paramètre que vous avez modifié, y compris le format de réponse si vous l’avez modifié.

Les conditions habituelles de mise en cache des prompts continuent de s’appliquer. Pour envoyer des instructions utilisateur pendant la génération d’une réponse, consultez le guide sur le guidage en cours de tour.

Résumés du raisonnement

Les tokens de raisonnement bruts produits par le modèle ne sont pas accessibles, mais le paramètre summary permet de consulter un résumé de son raisonnement. Consultez la documentation des modèles pour vérifier quels modèles de raisonnement prennent en charge les résumés.

Les réglages disponibles pour les résumés du raisonnement varient selon le modèle. Par exemple, notre modèle d’utilisation de l’ordinateur prend en charge le réglage concise, tandis qu’o4-mini prend en charge detailed. Pour obtenir le résumé le plus détaillé disponible pour un modèle, définissez ce paramètre sur auto. Pour la plupart des modèles de raisonnement actuels, auto équivaut à detailed, mais des réglages plus fins pourraient être proposés à l’avenir.

Le résumé du raisonnement figure dans le tableau summary associé au type reasoning dans l’élément de sortie. L’API ne l’inclut que si vous demandez explicitement un résumé du raisonnement.

L’exemple ci-dessous montre comment demander un résumé du raisonnement dans une requête API.

Inclusion d’un résumé du raisonnement dans la réponse de l’API
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input="What is the capital of France?",
    reasoning={"effort": "low", "summary": "auto"},
)

print(response.output)

Cette requête API renvoie un tableau de sortie qui contient à la fois un message de l’assistant et un résumé du raisonnement suivi par le modèle pour produire cette réponse.

[
  {
    "id": "rs_6876cf02e0bc8192b74af0fb64b715ff06fa2fcced15a5ac",
    "type": "reasoning",
    "summary": [
      {
        "type": "summary_text",
        "text": "**Answering a simple question**\n\nI\u2019m looking at a straightforward question: the capital of France is Paris. It\u2019s a well-known fact, and I want to keep it brief and to the point. Paris is known for its history, art, and culture, so it might be nice to add just a hint of that charm. But mostly, I\u2019ll aim to focus on delivering a clear and direct answer, ensuring the user gets what they\u2019re looking for without any extra fluff."
      }
    ]
  },
  {
    "id": "msg_6876cf054f58819284ecc1058131305506fa2fcced15a5ac",
    "type": "message",
    "status": "completed",
    "content": [
      {
        "type": "output_text",
        "annotations": [],
        "logprobs": [],
        "text": "The capital of France is Paris."
      }
    ],
    "role": "assistant"
  }
]

Avant d’utiliser les fonctions de résumé avec nos derniers modèles de raisonnement, vous devrez peut-être faire vérifier votre organisation pour garantir un déploiement sûr. Lancez la vérification depuis la page des paramètres de la plateforme.

Paramètre phase

Pour les workflows de longue durée ou qui font de nombreux appels d’outils avec GPT-5.5 et GPT-5.4 dans l’API Responses, utilisez le champ phase des messages de l’assistant afin d’éviter les arrêts prématurés et d’autres comportements indésirables. L’API n’exige pas phase, mais OpenAI recommande de l’utiliser. Utilisez phase: "commentary" pour les messages intermédiaires de l’assistant, par exemple les préambules aux appels d’outils, et phase: "final_answer" pour la réponse finale. N’ajoutez pas phase aux messages utilisateur. Le plus simple est généralement d’utiliser previous_response_id, qui préserve l’état antérieur de l’assistant. Si vous retransmettez manuellement l’historique de l’assistant, conservez chaque valeur d’origine de phase. Si le champ phase est absent ou supprimé, les préambules risquent d’être traités comme des réponses finales dans ces workflows. Pour des conseils de rédaction des prompts propres au modèle, consultez le guide Rédaction de prompts pour GPT-5.5.

Retransmission des valeurs de phase de l’assistant

Retransmission des valeurs de phase de l’assistant
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input=[
        {
            "role": "assistant",
            "phase": "commentary",
            "content": "I’ll inspect the logs and then summarize root cause and remediation.",
        },
        {
            "role": "assistant",
            "phase": "final_answer",
            "content": "Root cause: cache invalidation race.",
        },
        {
            "role": "user",
            "content": "Great—now give me a rollout-safe fix plan.",
        },
    ],
)

print(response.output_text)

Conseils de rédaction des prompts

Tenez compte des particularités des modèles de raisonnement lorsque vous rédigez vos prompts. Les modèles GPT-5 capables de raisonner donnent généralement de meilleurs résultats si vous leur fixez un objectif clair, des contraintes précises et des exigences explicites pour la sortie, sans leur dicter chaque étape intermédiaire.

  • Indiquez au modèle la tâche à accomplir, les contraintes à respecter et le format de sortie souhaité.
  • Utilisez reasoning.effort pour affiner le réglage du modèle. Si la qualité est insuffisante, ce paramètre ne doit pas être votre principal levier d’amélioration.
  • Pour les workflows agentiques ou qui nécessitent beaucoup de recherches, définissez les critères d’achèvement et précisez comment le modèle doit vérifier son travail.

Pour en savoir plus sur les bonnes pratiques d’utilisation des modèles de raisonnement, consultez ce guide.

Exemples de prompts

Les modèles de raisonnement peuvent implémenter des algorithmes complexes et générer du code. Ce prompt demande au modèle de refactoriser un composant React selon des critères précis.

Refactorisation de code
import OpenAI from "openai";

const openai = new OpenAI();

const prompt = `
Instructions:
- Given the React component below, change it so that nonfiction books have red
  text.
- Return only the code in your reply
- Do not include any additional formatting, such as markdown code blocks
- For formatting, use four space tabs, and do not allow any lines of code to
  exceed 80 columns

const books = [
  { title: 'Dune', category: 'fiction', id: 1 },
  { title: 'Frankenstein', category: 'fiction', id: 2 },
  { title: 'Moneyball', category: 'nonfiction', id: 3 },
];

export default function BookList() {
  const listItems = books.map(book =>
    <li>
      {book.title}
    </li>
  );

  return (
    <ul>{listItems}</ul>
  );
}
`.trim();

const response = await openai.responses.create({
  model: "gpt-6-astra",
  input: [
    {
      role: "user",
      content: prompt,
    },
  ],
});

console.log(response.output_text);

Exemples de cas d’usage

Vous trouverez dans le Cookbook des exemples concrets d’utilisation des modèles de raisonnement.

Validation de données à l’aide du raisonnement

Examinez un jeu de données médicales synthétiques pour y repérer des incohérences.
Génération de procédures à l’aide du raisonnement

Utilisez les articles du centre d’aide pour générer des actions qu’un agent pourrait exécuter.