Cómo usar GPT-6

Introducción

GPT-5.6 establece un nuevo nivel de referencia en calidad y eficiencia para flujos de trabajo complejos en producción. GPT-5.6 aprovecha los tokens con especial eficiencia y mejora el diseño visual del frontend, tanto en la distribución de los elementos y la jerarquía visual como en las decisiones de diseño.

GPT-5.6 también introduce una nueva nomenclatura. El alias gpt-5.6 dirige las solicitudes a gpt-5.6-sol, el modelo con las capacidades más avanzadas de la familia. Usa gpt-5.6-terra para obtener un buen rendimiento a un precio menor y gpt-5.6-luna para procesar cargas de trabajo de gran volumen con eficiencia.

Al migrar desde GPT-5.5 o GPT-5.4, comienza con el nivel de razonamiento que ya usas en GPT-5.5 o GPT-5.4. Luego prueba ese nivel y el inmediatamente inferior en tareas representativas. GPT-5.6 suele mantener o mejorar la calidad con menos tokens, pero el nivel más adecuado depende de tu carga de trabajo.

Novedades

• Llamadas programáticas a herramientas: GPT-5.6 puede escribir código JavaScript para llamar a las herramientas compatibles, pasar resultados de una llamada a otra y procesar salidas intermedias en un entorno de ejecución alojado. Usa las llamadas programáticas a herramientas en flujos de trabajo de alcance definido que hagan un uso intensivo de herramientas y en los que el modelo no tenga que tomar una nueva decisión entre un paso y el siguiente. Las llamadas programáticas a herramientas son compatibles con la retención cero de datos (ZDR) y no generan costos adicionales por el uso de contenedores.
• Coordinación multiagente [beta]: la coordinación multiagente permite que una instancia de GPT-5.6 coordine varios subagentes en paralelo y sintetice sus resultados. Al igual que el modo Ultra de Codex, esta función puede reducir el tiempo total de ejecución y mejorar el rendimiento en tareas complejas que se pueden dividir en partes independientes. La coordinación multiagente está disponible como función beta en la API de Responses mientras la perfeccionamos a partir de los comentarios de los desarrolladores.
• Almacenamiento en caché de prompts en modo explícito: GPT-5.6 te permite indicar exactamente qué prefijos reutilizables de los prompts guarda OpenAI en caché. También puedes seguir usando el almacenamiento automático en caché en modo implícito. OpenAI cobra por las escrituras en caché 1,25 veces la tarifa de entrada sin caché. Las lecturas de caché siguen teniendo descuento. Aprende a configurar el almacenamiento en caché de prompts.
• Razonamiento persistente: GPT-5.6 puede reutilizar los elementos de razonamiento disponibles entre turnos para mejorar la calidad de las conversaciones de varios turnos y la eficiencia de la caché. Usa reasoning.context para elegir el comportamiento. Aprende a conservar el razonamiento entre llamadas.
• Esfuerzo de razonamiento máximo: GPT-5.6 admite el nivel de esfuerzo de razonamiento max para tareas exigentes que requieren más exploración y verificación. Si actualmente usas xhigh, compara ambos niveles con cargas de trabajo representativas.
• Modo pro: GPT-5.6 puede dedicar más procesamiento a una solicitud para mejorar la fiabilidad en tareas difíciles y devolver una sola respuesta final. Activa este modo con reasoning.mode: "pro" cuando la calidad importe más que la latencia y el consumo de tokens. Aprende a usar el modo pro.
• Eficiencia en el uso de tokens: GPT-5.6 alcanza un rendimiento propio de un modelo insignia con menos tokens de salida.
• Diseño de frontend: GPT-5.6 crea sitios web y aplicaciones más pulidos y fáciles de usar, con una mejor distribución de los elementos, una jerarquía visual más clara y decisiones de diseño más acertadas.
• Comprensión de la intención: GPT-5.6 puede inferir mejor, a partir del contexto, qué quiere lograr el usuario y cuánto trabajo espera. Por eso, a menudo no necesitas indicar cada paso. Sigue proporcionando contexto del ámbito de trabajo, restricciones obligatorias, límites de aprobación y criterios de éxito. Indícale al modelo cuándo debe hacer una pregunta para aclarar una ambigüedad importante.
• Nivel de detalle original de las imágenes: GPT-5.6 conserva las dimensiones de las imágenes con el nivel de detalle original o auto, salvo si el ancho o el alto supera los 65 535 píxeles. En ese caso, reduce las dimensiones hasta ajustarlas a ese límite. Si la imagen aún supera el límite de 30 000 parches, la API la rechaza en lugar de volver a reducirla. Las imágenes grandes pueden consumir más tokens de entrada y aumentar la latencia. Aprende a elegir el nivel de detalle de una imagen.

Medidas de protección

Al usar los modelos GPT-5.6, es posible que algunas solicitudes se bloqueen o se rechacen. Estas medidas de protección utilizan clasificadores que detectan usos indebidos en ciberseguridad y biología en tiempo real, a medida que el modelo genera la salida. Otras solicitudes pueden tardar más porque la generación se interrumpe durante varios segundos mientras los clasificadores revisan la salida de forma síncrona. En ocasiones, las medidas de protección pueden intervenir en trabajos legítimos, sobre todo en ámbitos de doble uso en los que, a primera vista, las actividades defensivas y ofensivas pueden parecer similares.

Si tu aplicación atiende a usuarios finales individuales, envía con cada solicitud un safety_identifier estable que proteja la privacidad del usuario. Para obtener orientación, consulta Cómo implementar identificadores de seguridad.

Mejoramos continuamente estas medidas de protección para que resistan los intentos de eludirlas y sigan siendo eficaces, a la vez que preservamos el acceso para trabajos legítimos como la revisión de código, la investigación de vulnerabilidades, el desarrollo de parches, la depuración, la educación en seguridad y las pruebas defensivas.

Guía rápida de migración

Migrar con Codex

Codex puede aplicar los cambios recomendados en esta guía con la habilidad OpenAI Docs.

$openai-docs migra este proyecto a la familia de modelos GPT-5.6

Para usar esta habilidad en otros agentes de programación, descárgala del repositorio de habilidades de OpenAI.

Actualizar los parámetros de la API y del modelo

• Elige el modelo de destino según la carga de trabajo. Usa gpt-5.6-sol si necesitas las capacidades más avanzadas de la familia, gpt-5.6-terra para equilibrar inteligencia y costo, o gpt-5.6-luna para procesar cargas de trabajo de gran volumen con eficiencia. El alias gpt-5.6 dirige las solicitudes a gpt-5.6-sol.
• Usa la API de Responses para flujos de trabajo que requieran razonamiento, llamadas a herramientas o varios turnos.
• Elige el valor de reasoning.effort según la tarea. GPT-5.6 admite none, low, medium, high, xhigh y max.
  • Si migras desde GPT-5.5 o GPT-5.4, conserva tu nivel de esfuerzo de razonamiento actual como referencia y compáralo con el nivel inmediatamente inferior.
  • Si usas none, consérvalo como referencia de latencia y prueba también low cuando el flujo de trabajo se beneficie del razonamiento o del uso de herramientas.
  • Usa medium como punto de partida equilibrado y low para cargas de trabajo sensibles a la latencia.
  • Usa high o xhigh cuando tus mediciones indiquen que dedicar más esfuerzo al razonamiento mejora la calidad.
  • Reserva max para las cargas de trabajo más difíciles en las que la calidad sea prioritaria. Compara max y xhigh para encontrar el mejor equilibrio entre calidad, latencia y costo para tu caso de uso.
• Para usar el modo pro, conserva el modelo GPT-5.6 que elegiste y establece reasoning.mode en pro en la API de Responses. No cambies al slug de un modelo Pro distinto. Elige reasoning.effort de forma independiente. Si lo omites, GPT-5.6 usa medium de forma predeterminada tanto en el modo estándar como en el modo pro. Consulta la sección sobre el modo de razonamiento para ver un ejemplo de solicitud y los detalles de facturación.
• Configura el razonamiento persistente según qué parte del razonamiento anterior siga siendo pertinente. Los modelos GPT-5.6 usan all_turns de forma predeterminada y los modelos anteriores usan current_turn.
  • Omite reasoning.context o establécelo en auto para usar all_turns, el valor predeterminado de GPT-5.6. Revisa el campo reasoning.context de la respuesta para confirmar qué modo se aplicó.
  • Establece reasoning.context en all_turns cuando los objetivos, los supuestos y las prioridades de la tarea se mantengan estables entre turnos.
  • Con all_turns, continúa con previous_response_id para que el modelo tenga acceso al razonamiento de las respuestas anteriores.
  • Si administras el historial manualmente, conserva y reenvía las entradas anteriores del usuario y todos los elementos de salida de cada respuesta. Si usas store: false o la retención cero de datos, vuelve a enviar los elementos de razonamiento cifrados que la API devuelve de forma predeterminada.
  • Establece reasoning.context en current_turn cuando el razonamiento anterior ya no sea pertinente.
• Revisa el almacenamiento en caché de prompts. Puedes seguir usando el almacenamiento implícito en caché sin cambiar el código. Como las escrituras en caché de GPT-5.6 cuestan 1,25 veces la tarifa de entrada sin caché, monitorea cached_tokens y cache_write_tokens para conocer el costo neto. Usa puntos de corte explícitos o prompt_cache_options.mode: "explicit" para evitar escrituras innecesarias y reemplaza prompt_cache_retention por prompt_cache_options.ttl.
• Para usar llamadas programáticas a herramientas, agrega la herramienta programmatic_tool_calling y habilita las herramientas compatibles mediante allowed_callers. Actualiza tu aplicación para que procese los elementos program, las llamadas a funciones que realiza el programa y los elementos program_output, y conserve en cada llamada el call_id y el vínculo con caller. Consulta la guía de llamadas programáticas a herramientas para ver ejemplos de solicitudes y de cómo continuarlas.
  • Mide el rendimiento del flujo de trabajo con las llamadas programáticas a herramientas (PTC) habilitadas en tareas representativas. Compara el éxito de la tarea, qué tan completa es la respuesta final, la evidencia requerida, el total de tokens, la latencia y el costo. Reducir la cantidad de llamadas, turnos o salidas intermedias solo supone una mejora si la respuesta final sigue cumpliendo el nivel de calidad requerido.

Prácticas recomendadas para redactar prompts

Preferir prompts más concisos

Eliminar instrucciones y ejemplos repetidos y simplificar las descripciones de las herramientas puede mejorar el desempeño en las tareas y la eficiencia en el uso de tokens. En una muestra de evaluaciones internas de agentes de programación, las configuraciones con prompts de sistema más concisos mejoraron las puntuaciones aproximadamente entre un 10 % y un 15 %, a la vez que redujeron el total de tokens entre un 41 % y un 66 % y el costo entre un 33 % y un 67 %. Los resultados varían según la carga de trabajo, así que toma estos rangos como referencia y valida los cambios con tareas representativas de tu propia aplicación.

Para simplificar los prompts sin perder indicaciones importantes:

• Empieza con un prompt y un conjunto de herramientas que ya funcionen. Elimina un solo grupo de instrucciones, ejemplos o herramientas a la vez y vuelve a ejecutar las mismas evaluaciones.
• Da cada instrucción una sola vez.
• Pon a disposición del modelo solo las herramientas pertinentes para la tarea y descríbelas de forma concisa y precisa.
• Conserva los ejemplos y las pautas de estilo cuando expresen un requisito del producto o corrijan una deficiencia detectada en las evaluaciones.
• Monitorea el contexto tanto al inicio de la ejecución como a medida que avanza la conversación. En sesiones largas, el contenido repetido de los prompts y las herramientas puede acumularse.

Definir los límites de autonomía y aprobación

GPT-5.6 puede tomar la iniciativa y perseverar al realizar tareas de varios pasos. Define qué acciones autoriza cada solicitud para que el modelo pueda continuar sin pausas innecesarias con el trabajo seguro dentro del alcance acordado y se detenga antes de realizar acciones externas, destructivas, costosas o que amplíen ese alcance.

Por lo general, basta con una política breve:

Si el usuario te pide una respuesta, una explicación, una revisión, un diagnóstico
o un plan, examina los materiales pertinentes y comunica el resultado. Haz cambios
solo si el usuario también los solicita.

Si el usuario te pide cambiar, crear o corregir algo, haz los cambios locales
solicitados dentro del alcance de la tarea y ejecuta las validaciones no destructivas
pertinentes. Puedes realizar ambas acciones sin pedir confirmación previa.

Obtén la confirmación del usuario antes de escribir en sistemas externos, realizar
acciones destructivas, hacer compras o ampliar de forma significativa el alcance
de la tarea.

Indica explícitamente qué acciones locales son seguras, como leer archivos, inspeccionar registros, editar código dentro del alcance acordado y ejecutar pruebas. Mantén la política en un solo lugar y enuncia cada regla una sola vez. Repetir instrucciones como “pregunta primero”, “no modifiques nada” o “espera la aprobación” puede generar solicitudes de aprobación innecesarias para acciones seguras y previstas.

Establecer la extensión y el estilo de las respuestas

De forma predeterminada, GPT-5.6 tiende a ser más conciso que GPT-5.5. Al migrar, comprueba si siguen siendo útiles las instrucciones generales de brevedad, como “Sé conciso” o “Responde en pocas palabras”. En algunas tareas pueden ser innecesarias y, a veces, pueden dar lugar a respuestas demasiado breves. Consérvalas cuando produzcan de forma consistente el tipo de salida que necesita tu aplicación.

Para controlar el nivel de detalle de forma más uniforme entre solicitudes, usa text.verbosity para establecer el nivel predeterminado y especifica en el prompt los requisitos de cada tarea.

Establecer un nivel predeterminado con text.verbosity

Elige low, medium o high como nivel de detalle predeterminado para una solicitud. Especifica en el prompt los requisitos de extensión, estructura o contenido propios de la tarea. Consulta Cómo configurar text.verbosity para ver un ejemplo de uso de la API.

Especificar qué debe incluir una respuesta breve

Cuando una tarea requiera una respuesta más breve, indica qué información debe conservar el modelo y qué detalles puede omitir. Por ejemplo:

Empieza por la conclusión. Incluye la evidencia necesaria para sustentarla,
cualquier salvedad importante y la siguiente acción. Omite los detalles secundarios
y las repeticiones.

Conserva todos los datos, las decisiones, las salvedades y los próximos pasos
que deban figurar en la respuesta. Recorta primero las introducciones, las
repeticiones, las frases genéricas para tranquilizar al usuario y el contexto opcional.

Así, el modelo tiene un orden de prioridades claro: primero conserva el contenido necesario para completar la tarea y luego elimina los detalles menos importantes.

Definir el tono

Los calificativos generales como “amigable” o “empático” pueden ser ambiguos. Describe las decisiones de redacción que definen el tono de tu producto, como qué tan directa debe ser la respuesta, cuándo reconocer un problema y si conviene tranquilizar al usuario o incluir una despedida.

Responde directamente. Si el usuario señala un problema, reconoce la dificultad
concreta que describe antes de indicarle el siguiente paso. Tranquilízalo solo
cuando sea pertinente. Omite los elogios genéricos y las despedidas innecesarias.

Modo pro

Elegir el modo pro cuando la calidad sea prioritaria

El modo pro es un modo de ejecución de la API de Responses en el que el modelo dedica más procesamiento a una solicitud antes de devolver una sola respuesta final. Puede mejorar la fiabilidad en tareas difíciles, pero aumenta la latencia. El consumo reportado incluye la suma de los tokens utilizados en ese procesamiento. Esos tokens se facturan a las tarifas estándar por token del modelo seleccionado.

Usa el modo pro cuando una pequeña mejora de calidad influya de forma significativa en el resultado y la tarea sea lo bastante difícil como para beneficiarse de ella. Algunos ejemplos son los problemas de optimización complejos, la programación o revisión de código de alto valor y los análisis en profundidad con criterios de evaluación claros. Da preferencia al modo estándar para el trabajo rutinario, sensible a la latencia o de gran volumen, y siempre que tus evaluaciones no muestren una mejora significativa con el modo pro.

El modo de razonamiento y el esfuerzo de razonamiento son independientes. El modo pro funciona con cualquier modelo GPT-5.6 y con los niveles de esfuerzo de razonamiento que ese modelo admite. Empieza con el mismo modelo y el mismo nivel de esfuerzo que usas como referencia en el modo estándar. Luego compara las configuraciones en tareas representativas, sin dar por hecho que el mayor esfuerzo siempre ofrece el mejor equilibrio.

Configurar el modo pro en la API

Activa el modo pro en la solicitud a la API. Usa el mismo prompt centrado en el resultado que usas en el modo estándar: indica el objetivo, el contexto pertinente, las restricciones, la evidencia requerida, los criterios de éxito y el formato de salida. No necesitas darle al modelo instrucciones como “usa el modo pro” o “piensa más”, ni pedirle que genere varias respuestas posibles.

Por ejemplo:

Revisa este plan de migración de la base de datos e identifica las fallas que
podrían causar pérdida de datos o una interrupción prolongada del servicio.
Para cada hallazgo, cita el paso correspondiente, estima la probabilidad de que
ocurra la falla y su impacto, y recomienda una medida concreta para mitigarla.
Presenta los cinco riesgos más importantes, del más grave al menos grave.

Comparar la calidad y el costo

Compara los modos estándar y pro en las mismas tareas representativas. Mide el éxito de la tarea, qué tan completa es la respuesta, si incluye la evidencia requerida, el total de tokens, la latencia y el costo. Usa el modo pro de forma selectiva cuando la mejora en calidad o fiabilidad justifique el procesamiento adicional del modelo.

Obtén más información en la guía del modo de razonamiento.

Llamadas programáticas a herramientas

Elegir las llamadas programáticas a herramientas según la tarea

Las llamadas programáticas a herramientas (PTC) funcionan mejor en flujos de trabajo de alcance definido en los que el código puede procesar varios resultados de herramientas o grandes volúmenes de salida intermedia y devolver un resultado estructurado mucho más pequeño. Úsalas para filtrar, combinar, clasificar, eliminar duplicados, agregar o validar datos, o para otras operaciones de procesamiento predecibles.

La necesidad de hacer varias llamadas, en paralelo o con dependencias entre ellas, no justifica por sí sola el uso de llamadas programáticas a herramientas. Da preferencia a las llamadas directas a herramientas, sin PTC, cuando:

• Baste con una sola llamada
• Las salidas intermedias ya sean pequeñas
• Cada resultado pueda cambiar la siguiente decisión del modelo
• Una acción requiera aprobación
• La salida final deba conservar citas o artefactos nativos

Especificar el tipo de llamada según la tarea

Para que el modelo elija el tipo de llamada adecuado, no te limites a poner las herramientas a su disposición ni a darle instrucciones genéricas como “usa las llamadas programáticas a herramientas de manera eficiente”. Si están disponibles tanto las llamadas directas como las programáticas, indica explícitamente:

• En qué etapa de alcance definido debe usar las llamadas programáticas a herramientas.
• A qué herramientas puede llamar.
• Qué esquema de salida debe seguir exactamente y qué evidencia debe incluir.
• Qué límites de concurrencia y reintentos debe respetar y cuándo debe detenerse.
• Qué parte del trabajo debe seguir haciendo mediante llamadas directas.

Las descripciones de las herramientas deben documentar los campos que devuelven, sus tipos y el comportamiento previsto en caso de error. Si el modelo no puede determinar la estructura del resultado antes de escribir el programa, da preferencia a las llamadas directas para que pueda inspeccionar el resultado antes de decidir cómo usarlo.

Si necesitas ambos tipos de llamada, define un único punto de transición e indica al modelo que no alterne entre ellos ni repita trabajo ya completado.

Por ejemplo:

<tool_orchestration>
Usa llamadas programáticas a herramientas para [bounded stage] y utiliza solo
[eligible tools]. Ejecuta las llamadas independientes en paralelo cuando sea
seguro hacerlo. Usa únicamente los campos de entrada y salida documentados de
las herramientas.

Procesa y reduce los resultados intermedios. Luego devuelve un resultado que
se ajuste exactamente a [output schema] e incluya la evidencia necesaria para
la respuesta final.

Detente cuando se cumpla [condition]. Si una llamada falla por un problema
transitorio, vuelve a intentarla como máximo [R] veces. No repitas llamadas ya
completadas ni realices acciones que tengan efectos secundarios. Si aún falta
un resultado obligatorio, devuelve un error estructurado que indique claramente
el problema.

Usa llamadas directas a herramientas para [semantic judgment, approval, or final validation].
</tool_orchestration>

Evaluar la respuesta final

El elemento program_output y el message final del asistente son salidas independientes. Asegúrate de probar ambas. En principio, un programa puede devolver los registros correctos aunque el mensaje omita un campo obligatorio, una cita o una salvedad importante.

Compara las llamadas directas y las programáticas en las mismas tareas representativas. Comprueba si la respuesta final es correcta, está completa e incluye la evidencia requerida. Luego compara el total de tokens, la latencia, el costo y la cantidad de llamadas, turnos y reintentos. Considera que un menor consumo de recursos supone una mejora solo si la respuesta sigue superando tus evaluaciones actuales.

Obtén más información en la guía de llamadas programáticas a herramientas.