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

Réorientation d’une réponse en cours

Transmettez de nouvelles consignes de l’utilisateur pendant la génération d’une réponse.

La réorientation d’une réponse en cours permet aux utilisateurs d’ajouter des exigences ou de changer de direction sans attendre la fin de la réponse.

Les modèles de la famille GPT-6 prennent en charge la réorientation sur une connexion WebSocket à l’API Responses. GPT-5.6 et les modèles antérieurs ne la prennent pas en charge.

La réorientation ne modifie pas le contenu déjà envoyé à votre application. Elle n’annule ni les actions précédentes ni l’exécution des outils déjà lancés.

L’exemple Java nécessite Java 17 ou une version ultérieure. Pour savoir comment établir la connexion et comprendre le fonctionnement général du transport, consultez le guide du mode WebSocket. Pour connaître la définition exacte de chaque événement, consultez la référence des événements WebSocket de l’API Responses.

Envoyez une consigne de réorientation

Lancez une réponse avec response.create. À la réception de son événement response.created, envoyez response.steer sur la même connexion en indiquant l’identifiant de cette réponse dans previous_response_id :

{
  "type": "response.steer",
  "previous_response_id": "resp_1",
  "input": "Keep the scope small enough for one developer to finish in two weeks."
}

L’événement accepte uniquement les champs type, previous_response_id et input. Donnez à input une chaîne de caractères ou un tableau non vide de messages utilisateur dont le contenu est d’un type pris en charge.

L’API confirme la mise en file d’attente de la consigne avec response.steer.accepted :

{
  "type": "response.steer.accepted",
  "sequence_number": 4,
  "steer": {
    "id": "steer_0123456789abcdef0123456789abcdef",
    "previous_response_id": "resp_1"
  }
}

Cette confirmation indique seulement que la consigne est en file d’attente. Le modèle ne l’a pas nécessairement prise en compte. L’API crée automatiquement une nouvelle réponse qui intègre votre consigne, sauf si elle attend de votre application un résultat d’outil ou une approbation.

Avant de créer cette réponse de suivi automatique, le serveur termine l’élément de sortie en cours ainsi que les opérations déjà lancées par les outils hébergés. Continuez à lire les événements pour recevoir la réponse qui intègre votre consigne. N’envoyez pas de nouvel événement response.create.

Si la réorientation interrompt la réponse initiale, celle-ci se termine avec response.incomplete et incomplete_details.reason: "steered". Si la réponse initiale se termine normalement avant la réorientation, elle conserve son statut de réponse terminée et peut tout de même être suivie d’une réponse qui intègre la nouvelle consigne.

Les réponses de suivi automatiques héritent des paramètres de la requête initiale. Les limites de tokens et d’appels d’outils s’appliquent séparément à chaque réponse.

Exécutez un exemple complet

Le SDK .NET ne fournit pas de client WebSocket pour l’API Responses. Cet exemple n’a donc pas de variante utilisant le SDK C#.

Modifiez le plan d’un projet pendant sa génération
import asyncio

from openai import AsyncOpenAI


async def main():
    client = AsyncOpenAI()
    initial_response_id = None
    successor_response_id = None

    async with client.responses.connect() as connection:
        await connection.response.create(
            model="gpt-6-astra",
            store=False,
            reasoning={"effort": "medium"},
            input="Draft a project plan for building a task-tracking app.",
        )
        async for event in connection:
            if event.type == "response.created":
                if initial_response_id is None:
                    initial_response_id = event.response.id
                    # Simulate a user adding instructions while the response runs.
                    await connection.response.steer(
                        previous_response_id=initial_response_id,
                        input="Keep the scope small enough for one developer to finish in two weeks.",
                    )
                else:
                    successor_response_id = event.response.id
            elif event.type in {"response.steer.failed", "response.failed", "error"}:
                raise RuntimeError(event.to_json())
            elif event.type == "response.incomplete":
                response = event.response
                if (
                    response.id != initial_response_id
                    or response.incomplete_details is None
                    or response.incomplete_details.reason != "steered"
                ):
                    raise RuntimeError(event.to_json())
            elif (
                event.type == "response.completed"
                and event.response.id == successor_response_id
            ):
                print(event.response.output_text)
                return
            # Acceptance only queues the input. Keep reading past the first response.
        raise RuntimeError("Connection closed before the steered response finished.")


async def run():
    await asyncio.wait_for(main(), timeout=120)


asyncio.run(run())

L’exemple envoie la nouvelle consigne après le premier événement response.created. Dans votre application, envoyez-la lorsque l’utilisateur la fournit. Pour réorienter la réponse de suivi à son tour, utilisez son identifiant dès la réception de son événement response.created.

Renvoyez les résultats d’outils ou l’approbation

Si la réponse nécessite le résultat d’un outil exécuté côté client ou une approbation, l’API laisse la consigne de réorientation en file d’attente. Poursuivez votre procédure habituelle d’exécution des outils ou d’approbation sur la même connexion.

Par exemple, la réponse initiale peut se terminer par un appel à get_project_status. Seuls les champs pertinents figurent dans les données ci-dessous :

{
  "type": "response.completed",
  "response": {
    "id": "resp_1",
    "status": "completed",
    "output": [
      {
        "type": "function_call",
        "call_id": "call_project",
        "name": "get_project_status",
        "arguments": "{\"project\":\"task-tracker\"}"
      }
    ]
  }
}

Une fois la réponse initiale terminée, l’API envoie response.steer.pending pour signaler qu’une consigne de réorientation acceptée nécessite encore des données. Le champ required_input de cet événement indique les résultats d’outils ou les approbations que l’API doit recevoir avant de pouvoir appliquer la consigne :

{
  "type": "response.steer.pending",
  "sequence_number": 12,
  "steer": {
    "id": "steer_0123456789abcdef0123456789abcdef",
    "previous_response_id": "resp_1"
  },
  "reason": "waiting_for_required_input",
  "required_input": [
    {
      "type": "function_call_output",
      "call_id": "call_project",
      "name": "get_project_status"
    }
  ]
}

Renvoyez les données requises avec response.create sur la même connexion en attribuant à previous_response_id la valeur resp_1. Ne renvoyez pas la consigne de réorientation déjà acceptée. Un événement response.create envoyé explicitement utilise ses propres outils, instructions et autres paramètres.

Les commentaires de cet exemple JSONC indiquent où le serveur insère la consigne en attente :

{
  "type": "response.create",
  "model": "gpt-6-astra",
  "previous_response_id": "resp_1",
  "input": [
    // The server implicitly prepends your accepted steer here:
    // "Keep the scope small enough for one developer to finish in two weeks."
    {
      "type": "function_call_output",
      "call_id": "call_project",
      "output": "Design is complete. Development has not started.",
    },
    {
      "role": "user",
      "content": "Show me the updated plan before starting any work.",
    },
  ],
}

Vous pouvez renvoyer les résultats d’outils sans attendre response.steer.pending. Si le serveur a déjà reçu l’événement response.create correspondant, il peut poursuivre sans envoyer cette notification au préalable.

Gérez les échecs et les déconnexions

response.steer.failed indique que l’API n’a pas appliqué la consigne de réorientation et qu’elle ne l’appliquera pas automatiquement par la suite. L’événement renvoie les valeurs d’origine de input et de previous_response_id dans steer, ainsi qu’un objet error qui décrit l’échec.

Suivez les consignes acceptées à l’aide de steer.id. En cas d’échec ultérieur, l’événement utilise le même identifiant.

Codes d’erreur courants :

  • invalid_input : utilisez uniquement les champs pris en charge par l’événement et fournissez des messages utilisateur en entrée.
  • steering_not_supported : le modèle, les paramètres de la requête ou les deux peuvent être incompatibles avec la réorientation.
  • response_not_found : la réponse ciblée doit encore être disponible sur la même connexion WebSocket.
  • too_many_pending_steers : trop de consignes de réorientation sont en attente. Renvoyez les résultats d’outils ou les approbations requis avec response.create. Si aucun résultat ni aucune approbation ne sont requis, attendez la réponse de suivi automatique avant d’envoyer d’autres consignes. Ne renvoyez pas les consignes déjà acceptées.

Les consignes de réorientation en attente n’existent que sur la connexion en cours. L’API ne les enregistre pas avec la réponse initiale. Consignez les instructions de réorientation que vous envoyez et comparez-les aux événements et à l’historique des réponses avant de les renvoyer. Ne présumez pas que les consignes en attente ont été conservées après la déconnexion. Consultez les consignes de reconnexion et de reprise en mode WebSocket.