Los usuarios pueden agregar requisitos o cambiar de rumbo sin esperar a que termine la respuesta.
Puedes ajustar el rumbo de una respuesta con los modelos de la familia GPT-6 mediante una conexión WebSocket a la API de Responses. GPT-5.6 y los modelos anteriores no admiten esta función.
Al ajustar el rumbo de una respuesta, no se modifica la salida que ya se envió a tu aplicación, no se deshacen las acciones anteriores ni se cancelan las herramientas que ya están en ejecución.
El ejemplo en Java requiere Java 17 o una versión posterior. Para obtener información sobre cómo configurar la conexión y cómo funciona el transporte en general, consulta Modo WebSocket. Para conocer la definición exacta de cada evento, consulta la referencia de eventos WebSocket de Responses.
Enviar un mensaje para ajustar el rumbo
Inicia una respuesta con response.create. Cuando recibas el evento response.created de esa respuesta, envía response.steer por la misma conexión y usa el ID de la respuesta como valor de 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."
}
El evento solo acepta los campos type, previous_response_id e input. Asigna a input una cadena de texto o un arreglo no vacío de mensajes de usuario con tipos de contenido admitidos.
La API confirma que puso la entrada en cola mediante response.steer.accepted:
{
"type": "response.steer.accepted",
"sequence_number": 4,
"steer": {
"id": "steer_0123456789abcdef0123456789abcdef",
"previous_response_id": "resp_1"
}
}
La confirmación solo indica que la entrada está en cola. El modelo podría no haberla aplicado todavía. La API crea automáticamente una nueva respuesta con tu actualización, salvo que necesite que tu aplicación le envíe el resultado de una herramienta o una aprobación.
Antes de crear esta continuación automática, el servidor termina el elemento de salida actual y espera a que las herramientas alojadas terminen las tareas que ya están en curso. Sigue leyendo los eventos para recibir la respuesta que incorpora tu actualización. No envíes otro response.create.
Si la actualización interrumpe la respuesta original, esta termina con response.incomplete e incomplete_details.reason: "steered". Si la respuesta original termina normalmente antes de que se aplique la actualización, conserva su estado de respuesta completada y aún puede tener una continuación que incorpore la actualización.
Las continuaciones automáticas heredan la configuración de la solicitud original. Los límites de tokens y de llamadas a herramientas se aplican por separado a cada respuesta.
Ejecutar un ejemplo completo
El SDK de .NET no incluye un cliente WebSocket para la API de Responses, por lo que este ejemplo no tiene una variante que use el SDK de C#.
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())El ejemplo envía la actualización después del primer evento response.created. En tu aplicación, envíala cuando el usuario la proporcione. Una vez que recibas el evento response.created de la continuación, usa el ID de esa continuación para enviar nuevas actualizaciones.
Devolver resultados de herramientas o una aprobación
Si la respuesta requiere el resultado de una herramienta del cliente o una aprobación, la API mantiene la actualización en cola. Continúa con el flujo habitual de ejecución de herramientas o de aprobación en la misma conexión.
Por ejemplo, la respuesta original puede completarse con una llamada a get_project_status. En los siguientes mensajes se muestran solo los campos pertinentes:
{
"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\"}"
}
]
}
}
Cuando se completa la respuesta original, la API envía response.steer.pending si aún necesita datos para aplicar una actualización aceptada. El campo required_input indica qué resultados de herramientas o aprobaciones necesita la API para poder aplicar la actualización:
{
"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"
}
]
}
Envía los datos requeridos con response.create por la misma conexión y asigna a previous_response_id el valor resp_1. No repitas la actualización aceptada. Si envías response.create de forma explícita, la solicitud usa sus propias herramientas, instrucciones y demás parámetros de configuración.
Los comentarios de este ejemplo en JSONC muestran dónde agrega el servidor la actualización en cola:
{
"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.",
},
],
}
Puedes devolver los resultados de las herramientas sin esperar a recibir response.steer.pending. Si el servidor ya recibió el evento response.create correspondiente, puede continuar sin enviar antes esta notificación.
Gestionar errores y desconexiones
response.steer.failed indica que la API no aplicó la entrada como actualización de la respuesta en curso ni la aplicará automáticamente más adelante. El evento devuelve los valores originales de input y previous_response_id dentro de steer, junto con un objeto error que describe el fallo.
Usa steer.id para hacer un seguimiento de las actualizaciones aceptadas. Si una actualización falla más adelante, el evento de error usa el mismo ID.
Códigos de error comunes:
invalid_input: usa solo los campos admitidos del evento y envía únicamente mensajes de usuario como entrada.steering_not_supported: es posible que el modelo, los parámetros de la solicitud o ambos sean incompatibles con las actualizaciones durante la generación de una respuesta.response_not_found: la respuesta que quieres actualizar debe seguir disponible en la misma conexión WebSocket.too_many_pending_steers: hay demasiadas actualizaciones pendientes. Si se requieren resultados de herramientas o aprobaciones, envíalos conresponse.create. De lo contrario, espera a que se genere la continuación automática antes de enviar más actualizaciones. No vuelvas a enviar las que ya se aceptaron.
Las actualizaciones en cola solo existen en la conexión actual. No se guardan con la respuesta original. Registra las actualizaciones que envíes y compáralas con los eventos y el historial de respuestas antes de volver a enviarlas. No des por hecho que las actualizaciones pendientes se conservaron tras la desconexión. Consulta la guía de recuperación de conexiones WebSocket.