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

Mid-turn steering

Send user updates while a response is running.

Mid-turn steering lets users add requirements or change direction without waiting for a response to finish.

Mid-turn steering is available with GPT-6 Astra (gpt-6-astra) over a WebSocket connection to the Responses API. GPT-5.6 and earlier models do not support steering.

Steering does not rewrite output already sent to your application, undo earlier actions, or cancel tools that have already started.

For connection setup and general transport behavior, see WebSocket mode. For exact event definitions, see the Responses WebSocket events reference.

Send a steering message

Start a response with response.create. After receiving its response.created event, send response.steer on the same connection, using that response’s ID as 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."
}

The event accepts only type, previous_response_id, and input. Set input to a string or a nonempty array of user messages with supported content types.

The API acknowledges queued input with response.steer.accepted:

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

Acceptance means the input is queued, not that the model has acted on it. The API automatically creates a new response with your update unless it needs a tool result or approval from your application.

Before creating this automatic continuation, the server finishes the current output item and any hosted tool work already running. Keep reading events to receive the response with your update; do not send another response.create.

If steering interrupts the original response, it ends with response.incomplete and incomplete_details.reason: "steered". If the original response finishes normally first, it keeps its completed status and can still have a steering continuation.

Automatic continuations inherit the original request settings. Token and tool-call limits apply separately to each response.

Run a complete example

Update a project plan while it runs
# Set OPENAI_API_KEY before running this example.
# Install the WebSocket client: pip install websocket-client

import json
import os
import time

from websocket import create_connection

ws = create_connection(
    "wss://api.openai.com/v1/responses",
    header=[f"Authorization: Bearer {os.environ['OPENAI_API_KEY']}"],
    timeout=10,
)
initial_response_id = None
successor_response_id = None
deadline = time.monotonic() + 120

try:
    ws.send(
        json.dumps(
            {
                "type": "response.create",
                "model": "gpt-6-astra",
                "reasoning": {"effort": "medium"},
                "input": "Draft a project plan for building a task-tracking app.",
            }
        )
    )
    while True:
        remaining = deadline - time.monotonic()
        if remaining <= 0:
            raise TimeoutError("Timed out waiting for the steered response.")
        ws.settimeout(remaining)
        message = ws.recv()
        if not message:
            raise RuntimeError(
                "Connection closed before the steered response finished."
            )
        event = json.loads(message)
        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.
                ws.send(
                    json.dumps(
                        {
                            "type": "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(json.dumps(event))
        elif event["type"] == "response.incomplete":
            response = event["response"]
            if (
                response["id"] != initial_response_id
                or response.get("incomplete_details", {}).get("reason") != "steered"
            ):
                raise RuntimeError(json.dumps(event))
        elif (
            event["type"] == "response.completed"
            and event["response"]["id"] == successor_response_id
        ):
            print(
                "".join(
                    part["text"]
                    for item in event["response"]["output"]
                    if item["type"] == "message"
                    for part in item["content"]
                    if part["type"] == "output_text"
                )
            )
            break
        # Acceptance only queues the input. Keep reading past the first response.
finally:
    ws.close()

The example sends the update after the first response.created event. In your application, send it when a user supplies an update. Use the continuation’s ID for new steering once its response.created event arrives.

Return tool results or approval

If the response needs a client tool result or approval, the API keeps the steering queued. Continue your normal tool or approval flow on the same connection.

For example, the original response can complete with a call to get_project_status. The following payloads show only the relevant fields:

{
  "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\"}"
      }
    ]
  }
}

After the original response completes, the API sends response.steer.pending for accepted steering that still needs input. Its required_input field identifies the tool results or approvals the API needs before it can apply the update:

{
  "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"
    }
  ]
}

Return the required input with response.create on the same connection, setting previous_response_id to resp_1. Do not repeat the accepted steering. An explicit response.create uses its own tools, instructions, and other settings.

The comments in this JSONC example show where the server adds the queued update:

{
  "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.",
    },
  ],
}

You do not need to wait for response.steer.pending before returning tool results. If the server has already received a matching response.create, it can proceed without sending this notification first.

Handle failures and disconnects

response.steer.failed means the API did not apply the input through steering and will not apply it automatically later. The event returns the original input and previous_response_id under steer, with an error object describing the failure.

Track accepted submissions by steer.id. A later failure uses the same ID.

Common error codes:

  • invalid_input: Use only the supported event fields and user message input.
  • steering_not_supported: The model, request parameters, or both may be incompatible with steering.
  • response_not_found: The target response must still be available on the same WebSocket connection.
  • too_many_pending_steers: Too much steering input is pending. Return any required tool results or approvals using response.create; otherwise, wait for the automatic continuation before submitting more. Do not resend already accepted steering.

Queued steering input exists only on the current connection; it isn’t stored with the original response. Record the steering inputs you send, and compare them with response events and history before replaying them. Do not assume pending steering survived the disconnect. See WebSocket recovery guidance.