Guía de modelos

Introducción

GPT-6 Astra es nuestro modelo más inteligente hasta la fecha, con un rendimiento de vanguardia en uso de la computadora, navegación, ingeniería de software, ciencia y trabajo profesional. Se destaca por ejecutar flujos de trabajo de varios pasos que abarcan código, navegadores y software profesional. En varias evaluaciones, Astra logra mejores resultados con una cantidad considerablemente menor de tokens de salida, lo que supone un costo estimado de la API por tarea inferior al de modelos anteriores, a pesar de su mayor precio por token.

GPT-6 Astra también es nuestro modelo más alineado hasta la fecha. Se destaca por actuar con cuidado, respetar los límites de las tareas y comunicarse con transparencia. Cuando las instrucciones dejan margen de interpretación, usa el contexto disponible para completar detalles rutinarios que faltan y hace preguntas específicas cuando la respuesta podría cambiar el resultado. Incorpora nuevos requisitos, cambia de rumbo cuando se le pide y responde preguntas secundarias sin perder de vista la tarea general.

Para desarrollar con Astra, establece model en gpt-6-astra en una solicitud a la API Responses.

Novedades

• Llamada asíncrona a herramientas: GPT-6 Astra puede seguir razonando, llamar a otras herramientas o responder partes independientes de una solicitud mientras tu aplicación ejecuta una herramienta. Configura async: true en una función o herramienta personalizada y devuelve su resultado cuando esté listo usando el call_id original. Tu aplicación sigue ejecutando la herramienta y gestionando el trabajo pendiente. Consulta Llamada asíncrona a herramientas para conocer el uso básico y un patrón con una herramienta de espera definida por el desarrollador.
• Orientación durante el turno: envía instrucciones adicionales del usuario mientras GPT-6 Astra está trabajando, como una corrección o un cambio en los requisitos. A través de una conexión WebSocket, la API Responses conserva el trabajo completado e incluye la actualización en una continuación. Consulta Orientación durante el turno para conocer el flujo de eventos y el manejo de los resultados de herramientas.
• Cambiar el razonamiento durante la conversación sin perder la caché: agrega un elemento de entrada configuration_update para aumentar el esfuerzo de razonamiento en tareas difíciles o reducirlo en seguimientos rutinarios sin reescribir el prefijo original del prompt. El esfuerzo de razonamiento actualizado se aplica hasta que otro elemento de entrada configuration_update lo reemplace. Consulta Cambiar el razonamiento durante la conversación para ver ejemplos y detalles de compatibilidad.
• Monitoreo de desalineación: como parte de nuestras medidas de protección reforzadas para GPT-6 Astra, nuestros sistemas monitorean de forma asíncrona la desalineación y activan alertas cuando es necesario. Consulta Monitoreo de desalineación para obtener más información.
• Limitaciones: GPT-6 Astra no admite el esfuerzo de razonamiento none. El modo rápido no está disponible para GPT-6 Astra con residencia de datos en la UE.

GPT-6 Astra también admite las capacidades existentes de la API disponibles con GPT-5.6, como uso de la computadora, resultados estructurados, streaming, llamada programática a herramientas, orquestación multiagente, almacenamiento de prompts en caché, razonamiento persistente, compactación y modo Pro.

Prácticas recomendadas para el diseño de prompts

GPT-6 Astra es más inteligente y capaz que modelos anteriores como GPT-5.6 Sol, y también presenta patrones de comportamiento que se pueden optimizar mediante prompts adaptados a tu caso de uso.

Comportamiento de GPT-6 Astra

• Iniciativa y persistencia – El modelo está diseñado para colaborar de forma más eficaz, por lo que es más probable que le haga una pregunta al usuario cuando la información adicional podría cambiar considerablemente el resultado. Esto puede hacer que se detenga cuando el usuario quizá espere que haga suposiciones razonables y continúe.
• Seguimiento de instrucciones – GPT-6 Astra sigue las instrucciones generales mejor que nuestros modelos anteriores, lo que te da mayor control sobre su comportamiento. Puede ser más sensible a las instrucciones contenidas en habilidades y otros archivos, como AGENTS.md. Recomendamos encarecidamente auditar las habilidades y otros archivos a los que tiene acceso tu modelo para detectar instrucciones que podrían influir en su comportamiento.
• Personalidad y estilo de escritura – El modelo tiende a dar respuestas detalladas y con formato, y puede usar frases recurrentes entre sesiones. Especifica el estilo de escritura y la estructura que necesita tu aplicación.
• Delegación a subagentes – Es posible que el modelo delegue con menos frecuencia de la deseada para tu flujo de trabajo. Especifica cuándo y en qué medida debe usar subagentes para trabajar en paralelo.
• Pruebas y verificación – En las tareas de programación, el modelo tiende a realizar pruebas exhaustivas antes de considerar que una tarea está completa. Para tareas más pequeñas, esto puede dar lugar a pruebas más amplias de lo necesario.

Iniciativa y persistencia

En general, GPT-6 Astra mantiene la coherencia durante tareas largas mejor que GPT-5.6 Sol y modelos anteriores. También es más probable que pida aclaraciones en situaciones en las que los modelos anteriores harían suposiciones.

Para fomentar un trabajo más autónomo, comienza con este prompt:

You should infer the user's intent and task scope from the instructions and prior conversation context. Your job is to bias towards action and carry the user's intended task to completion.

When the user expresses intent to perform new work or fix an existing issue, persist until the user's intended goal is complete. Progress autonomously towards the user's goal (e.g. creating isolated worktrees / checkouts if needed, resolving merge conflicts, read-only actions, creating draft PRs etc.) unless they are clearly destructive or irreversible.

Cuando la intención del usuario no está clara, es más probable que el modelo le pida aclaraciones para continuar. Indícale al modelo que siga adelante si el prompt del usuario implica autorización:

When the user's prompt indicates a request for action, such as "can you...", "I want to...", "help me..." and similar expressions, treat these as instructions to do the work and take action. Do not stop at acknowledging capability (e.g. "Yes…"), proposing a plan, or offering to continue. Do not settle for a partial or "helpful enough" solution that does not fully satisfy the user's task to save time, effort or tokens. If a task requires sustained work, complete all the necessary work until the intended outcome is fulfilled.

Indícale al modelo que solicite aprobación solo después de preparar un resultado concreto que se pueda revisar. Esto evita bloquear la tarea antes de que el modelo haya realizado el trabajo que puede hacer y suele permitir completarla más rápido.

Before asking the user clarifying questions, you should complete the work that is already authorized from context and necessary to make the proposed action concrete and reviewable. The user should be approving a concrete, reviewable result. For example, before deploying a change, writing to an external application, merging a PR or publishing a site, do all the required work first so that user approval is the final step. You don't need user permission for reversible tasks, read-only actions, reviews or fixes, or anything for which authorization is provided earlier in the session or strongly implied from the task instruction.

Do not introduce unsolicited warnings, disclaimers, approval flows, or safety/compliance checklists due to hypothetical risk.

De forma predeterminada, el modelo también tiende a hacer preguntas sin detener el trabajo, así que ajusta estos prompts al nivel de autonomía que necesita tu aplicación.

Seguimiento de instrucciones

GPT-6 Astra tiene mayor capacidad para seguir instrucciones más largas, pero también puede ser más sensible a la información del contexto. Por ejemplo, las indicaciones poco claras o contradictorias en un archivo de habilidad pueden hacer que el modelo se detenga y bloquee el trabajo antes de tiempo. Define explícitamente la prioridad de las instrucciones del usuario y de las habilidades.

The user's instructions take precedence over guidelines provided in a skill. If explicit user instructions conflict with a skill's instructions, prioritize the user's instructions.

Pedirle al modelo que identifique la habilidad y la instrucción que lo hicieron detenerse o cambiar de rumbo también puede ayudar a entender su comportamiento con mayor transparencia.

If a skill causes you to ask for permission or confirmation, pause, leave requested work unfinished, or diverge from the user's intent, name and link to the exact SKILL.md file you read, quote the relevant instruction, and briefly explain how it applies. Distinguish explicit skill requirements from your interpretation of guidelines.

Usa este prompt para encontrar indicaciones que pasan inadvertidas o entran en conflicto cuando tu aplicación carga muchas habilidades y archivos de instrucciones como AGENTS.md.

Personalidad y estilo de escritura

GPT-6 Astra tiende a usar listas, tablas y Markdown para facilitar la lectura rápida de las respuestas. Si tu aplicación necesita prosa con menos formato, especifica esa preferencia.

Default to using clear, concise paragraphs, each developing one main idea. Use lists only when the information is genuinely parallel, sequential, or easier to compare, and avoid nested lists unless the hierarchy cannot be expressed clearly in prose. Use plain, simple language: familiar words, concrete examples, and precise verbs. Prefer active voice and direct statements.

Make sure to state the main point clearly and early, then develop it with the explanation and detail the reader needs. Let each sentence build on what came before. Develop the points that matter and provide enough support to be useful.

Para la comunicación técnica, el siguiente prompt ayuda a usar un lenguaje claro y coherente que también sea adecuado para el campo:

Use plain language over jargon, and reference technical details only to the degree that it helps illustrate an idea or your work to the user. Communicate complex concepts in a clear and cohesive manner, and calibrate your writing to the level of background knowledge assumed from the user's prompt and context.

Para reducir la jerga y las frases hechas en la escritura, comienza con este prompt:

Avoid using slop words or phrases like "Bottom Line:" in conclusions, "delve," "foster," "leverage," "it's worth noting," "importantly," "Question? Answer." or "This isn't about X. It's about Y.", "genuinely" or hyphenated compound descriptions and adjectives. Do not use concluding summary statements such as "In short:..", "The simplest mental model is:...".

State the intended action directly. Avoid adding what you won't do, what will remain unchanged, or how you'll separate or categorize results. Do not use contrastive framing such as "X, not Y" or "X—not Y" that introduces an unprompted alternative that the user didn't ask about. Avoid invented compound labels like "exact-head checks" and "editorial-row layouts", vague qualifiers, and canned transitions; use plain verbs and prepositions to state the actual relationship directly.

Delegación a subagentes

GPT-6 Astra está entrenado para dividir el trabajo y delegarlo a subagentes que trabajan en paralelo. Si estás implementando un sistema multiagente en tu arnés de ejecución, usa el siguiente prompt para ajustar cuánto trabajo debe delegar GPT-6 Astra:

If at any point you can parallelize work by delegating tasks to another agent (no matter if you are the root or subagent), you should do so using collaboration tools if it could save time or improve quality.

Los mensajes entre agentes pueden contener errores gramaticales o de espaciado. Usa este prompt para facilitar la lectura de los mensajes entre agentes:

Messages that you send to other agents and your final answer may be read by a human, so ensure they are legible. Always put proper spaces between words and/or numbers.

El modelo suele responder bien a los prompts que indican cómo y cuándo debe delegar trabajo a subagentes, así que ajusta este comportamiento a tu arnés de ejecución y a tu implementación multiagente.

Pruebas y verificación

Para las tareas de programación, ajusta el alcance de las pruebas y la verificación a lo que requiere cada cambio. Esto puede ayudar a evitar pruebas innecesarias o verificaciones repetidas para cambios pequeños.

Do not write tests for reversible, low-impact changes that mirror the implementation. If you do choose to verify your work with tests, make sure that the tests are meaningful and necessary to verify implementation.

Run tests appropriate to the change and complete required checks. Once those pass, broaden or repeat testing only when new changes, failures, or unresolved concerns justify it; otherwise, continue toward completing the task.

Inicio rápido de migración

Migra con Codex

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

$openai-docs migrate this project to GPT-6 Astra

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

Actualiza los parámetros de la API y del modelo

Establece model en gpt-6-astra y luego revisa lo siguiente:

• Esfuerzo de razonamiento: si actualmente usas none o minimal, comienza con low y compara los resultados. De lo contrario, conserva el esfuerzo de razonamiento efectivo actual. Usa reasoning.effort en Responses o reasoning_effort en Chat Completions.
• Llamada a herramientas: usa la API Responses. GPT-6 Astra admite Chat Completions, pero las llamadas a herramientas requieren Responses.
• Parámetros no admitidos: elimina temperature, top_p y top_logprobs. Para Chat Completions, elimina también logprobs. Para Responses, elimina message.output_text.logprobs de include.
• Modo rápido: para la residencia de datos en la UE, usa el procesamiento estándar. GPT-6 Astra no admite service_tier: "fast" ni service_tier: "priority" con residencia de datos en la UE. El modo rápido de GPT-6 Astra no incluye un SLA de latencia. Consulta Compatibilidad del modo rápido.
• Cambiar el esfuerzo de razonamiento: si tu aplicación cambia el esfuerzo entre respuestas, usa elementos configuration_update en solicitudes estándar de un solo agente. Mantén reasoning.effort sin cambios a nivel de solicitud para conservar el prefijo del prompt para el almacenamiento en caché. Revisa los límites de compatibilidad antes de adoptar esta función.
• Almacenamiento de prompts en caché: al migrar desde GPT-5.5 o modelos anteriores, reemplaza prompt_cache_retention por prompt_cache_options.ttl con el valor "30m". Revisa los cambios en el almacenamiento de prompts en caché, incluidos los límites de la caché y la facturación de las escrituras en caché.
• Pausas innecesarias para solicitar aprobación: si el modelo te pide aprobación repetidamente antes de continuar, usa las recomendaciones sobre iniciativa y persistencia para solicitar una ejecución más autónoma mediante prompts. Consulta el resto de las Prácticas recomendadas para el diseño de prompts para obtener recomendaciones sobre seguimiento de instrucciones, estilo de escritura, delegación a subagentes y pruebas.

Introducción

GPT-5.6 establece un nuevo nivel de referencia de calidad y eficiencia para flujos de trabajo complejos en producción. GPT-5.6 es especialmente eficiente en el uso de tokens y mejora la estética del frontend, incluidos la distribución de los elementos, la jerarquía visual y el criterio de diseño.

GPT-5.6 también introduce un nuevo esquema de nombres. El alias gpt-5.6 dirige las solicitudes a gpt-5.6-sol, el modelo con capacidades de nivel insignia. Usa gpt-5.6-terra para obtener un rendimiento sólido a un precio menor y gpt-5.6-luna para procesar cargas de trabajo de gran volumen con eficiencia.

Al migrar de GPT-5.5 o GPT-5.4, parte de la configuración de razonamiento que usas actualmente con GPT-5.5 o GPT-5.4 y luego prueba esa misma configuración y un nivel inferior en tareas representativas. GPT-5.6 a menudo puede mantener o mejorar la calidad con menos tokens, pero la mejor configuración depende de tu carga de trabajo.

Novedades

• Llamada programática a herramientas: GPT-5.6 puede escribir JavaScript para llamar a herramientas compatibles, pasar resultados entre llamadas y procesar resultados intermedios en un entorno de ejecución alojado. Usa la llamada programática a herramientas para flujos de trabajo acotados que usan muchas herramientas y no requieren una nueva decisión del modelo entre cada paso. La llamada programática a herramientas es compatible con ZDR y no tiene costos adicionales de contenedores.
• Multiagente [beta]: la funció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 en Codex, esto puede reducir el tiempo total transcurrido y mejorar el rendimiento en tareas complejas que se pueden dividir claramente en líneas de trabajo independientes. La función multiagente está disponible en versión beta en la API Responses mientras seguimos mejorándola a partir de los comentarios de los desarrolladores.
• Almacenamiento explícito de prompts en caché: GPT-5.6 permite indicar exactamente qué prefijos reutilizables de prompts almacena OpenAI en caché. Puedes seguir usando el almacenamiento automático en caché en modo implícito. OpenAI cobra las escrituras en caché a 1,25× la tarifa de entrada sin caché, mientras que las lecturas de caché mantienen su descuento. Aprende a configurar el almacenamiento de prompts en caché.
• Razonamiento persistente: GPT-5.6 puede reutilizar los elementos de razonamiento disponibles entre turnos para mejorar la calidad en interacciones de varios turnos y la eficiencia de la caché. Usa reasoning.context para seleccionar el comportamiento. Aprende a conservar el razonamiento entre llamadas.
• Esfuerzo de razonamiento Max: GPT-5.6 admite el esfuerzo de razonamiento max para tareas exigentes que necesitan más exploración y verificación. Si actualmente usas xhigh, compara ambas configuraciones en cargas de trabajo representativas.
• Modo Pro: GPT-5.6 puede realizar más trabajo de procesamiento para mejorar la confiabilidad en tareas difíciles y devolver una única respuesta final. Actívalo con reasoning.mode: "pro" cuando la calidad importe más que la latencia y el uso de tokens. Aprende a usar el modo Pro.
• Eficiencia en el uso de tokens: GPT-5.6 alcanza un rendimiento de nivel 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 un mejor criterio de diseño.
• Comprensión de la intención: GPT-5.6 puede inferir mejor, a partir del contexto, el objetivo de fondo del usuario y cuánto trabajo espera que se realice, por lo que a menudo no necesitas indicar cada paso. Sigue proporcionando contexto del dominio, restricciones estrictas, límites de aprobación y criterios de éxito. Indica al modelo cuándo una ambigüedad importante debe dar lugar a una pregunta.
• Detalle de imagen original: GPT-5.6 conserva las dimensiones de las imágenes con el nivel de detalle original o auto, excepto cuando superan los 65 535 píxeles en cualquiera de sus lados; en ese caso, se reducen para ajustarse a ese límite. La API rechaza las imágenes que aún superan el límite de 30 000 parches, en lugar de cambiar su tamaño para ajustarlas. Las imágenes grandes pueden usar más tokens de entrada y aumentar la latencia. Aprende a elegir un nivel de detalle de imagen.

Salvaguardas

Al usar los modelos GPT-5.6, los usuarios pueden encontrarse con salvaguardas que bloquean o rechazan algunas solicitudes debido a clasificadores de uso indebido en ciberseguridad y biología que se ejecutan en tiempo real mientras se generan las salidas del modelo. Otras solicitudes pueden tardar más porque la generación se pausa durante varios segundos en medio de la transmisión mientras estos clasificadores revisan las salidas de forma síncrona. En ocasiones, las salvaguardas pueden intervenir en trabajos legítimos, en particular en áreas de doble uso donde las actividades defensivas y ofensivas pueden parecer similares al principio.

Si tu aplicación atiende a usuarios finales individuales, envía un safety_identifier estable que proteja la privacidad con cada solicitud. Consulta Implementar identificadores de seguridad para obtener orientación.

Mejoramos continuamente estas salvaguardas para que sean robustas y eficaces frente a intentos de vulnerarlas, a la vez que preservamos el acceso a trabajos legítimos como la revisión de código, la investigación de vulnerabilidades, el desarrollo de parches, la depuración, la formación en seguridad y las pruebas defensivas.

Inicio rápido para la migración

Migra con Codex

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

$openai-docs migrate this project to the GPT-5.6 model family

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

Actualiza los parámetros de la API y del modelo

• Elige el modelo de destino para la carga de trabajo. Usa gpt-5.6-sol para obtener capacidades de nivel insignia, gpt-5.6-terra para lograr un equilibrio entre 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 Responses para flujos de trabajo de razonamiento, llamadas a herramientas e interacciones de varios turnos.
• Elige el valor de reasoning.effort de forma deliberada. GPT-5.6 admite none, low, medium, high, xhigh y max.
  • Si migras de GPT-5.5 o GPT-5.4, conserva tu esfuerzo de razonamiento actual como referencia y luego compáralo con un nivel 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 un mayor razonamiento produzca una mejora medible en la calidad.
  • Reserva max para las cargas de trabajo más difíciles en las que la calidad sea la prioridad. 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 seleccionaste y establece reasoning.mode en pro en la API Responses; no cambies a un slug de modelo Pro independiente. Elige reasoning.effort por separado. Si lo omites, GPT-5.6 usa medium de forma predeterminada tanto en el modo estándar como en el modo Pro. Consulta modo de razonamiento para ver un ejemplo de solicitud y los detalles de facturación.
• Configura el razonamiento persistente en función de cuánto del razonamiento previo siga siendo relevante. Los modelos GPT-5.6 usan all_turns de forma predeterminada; 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 el modo aplicado.
  • 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 usando previous_response_id para que el modelo tenga acceso al razonamiento de respuestas anteriores.
  • Cuando administres el historial manualmente, conserva y reenvía las entradas anteriores del usuario y todos los elementos de salida de cada respuesta. Con store: false o 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 relevante.
• Revisa el almacenamiento de prompts en caché. No necesitas cambiar el código para seguir usando el almacenamiento implícito en caché. Como las escrituras en caché de GPT-5.6 cuestan 1,25× la tarifa de entrada sin caché, monitorea cached_tokens y cache_write_tokens para entender 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 la llamada programática a herramientas, agrega la herramienta programmatic_tool_calling y habilita las herramientas compatibles mediante allowed_callers. Actualiza tu aplicación para manejar elementos program, llamadas a funciones emitidas por el programa y elementos program_output, conservando el call_id y la vinculación caller de cada llamada. Consulta la guía de llamada programática a herramientas para ver ejemplos de solicitudes y continuaciones.
  • Evalúa el rendimiento del flujo de trabajo con PTC habilitada en tareas representativas. Compara el éxito de las tareas, 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 resultados intermedios solo constituye una mejora si la respuesta final sigue cumpliendo el nivel de calidad requerido.

Prácticas recomendadas para el diseño de prompts

Prioriza prompts más simples

Eliminar instrucciones y ejemplos repetidos y simplificar las descripciones de las herramientas puede mejorar el rendimiento en las tareas y la eficiencia en el uso de tokens. En una muestra de ejecuciones de evaluaciones internas de agentes de programación, las configuraciones con prompts del sistema más simples mejoraron las puntuaciones de evaluación aproximadamente entre un 10 y un 15 %, al tiempo que redujeron el total de tokens entre un 41 y un 66 % y el costo entre un 33 y un 67 %. Los resultados variarán según la carga de trabajo, así que considera estos rangos como orientativos y valida los cambios con tareas representativas de tu propia aplicación.

Para simplificar los prompts sin perder indicaciones importantes:

• Parte de un prompt y un conjunto de herramientas que ya funcionen. Elimina un grupo de instrucciones, ejemplos o herramientas a la vez y luego vuelve a ejecutar las mismas evaluaciones.
• Indica cada instrucción una sola vez.
• Pon a disposición solo las herramientas relevantes para la tarea y mantén sus descripciones concisas y precisas.
• Conserva los ejemplos y las pautas de estilo cuando reflejen un requisito del producto o corrijan una deficiencia detectada mediante mediciones.
• Monitorea el contexto tanto al inicio de una ejecución como a medida que crece la conversación. Las sesiones largas pueden amplificar el contenido repetido de los prompts y las herramientas.

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

GPT-5.6 puede ser proactivo y persistente al realizar tareas de varios pasos. Define qué nivel de acción autoriza cada solicitud para que el modelo pueda continuar con el trabajo seguro dentro del alcance, sin pausas innecesarias, y detenerse antes de realizar acciones externas, destructivas, costosas o que amplíen el alcance.

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

For requests to answer, explain, review, diagnose, or plan, inspect the relevant
materials and report the result. Do not implement changes unless the request also
asks for them.

For requests to change, build, or fix, make the requested in-scope local changes
and run relevant non-destructive validation without asking first.

Require confirmation for external writes, destructive actions, purchases, or a
material expansion of scope.

Indica explícitamente las acciones locales seguras, como leer archivos, inspeccionar registros, editar código dentro del alcance 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 hagas modificaciones” o “espera la aprobación” puede generar solicitudes de aprobación innecesarias para acciones seguras y esperadas.

Establece la extensión y el estilo de las respuestas

GPT-5.6 tiende a ser más conciso de forma predeterminada que GPT-5.5. Al migrar, verifica si las instrucciones generales de brevedad, como “Sé conciso” o “Responde brevemente”, siguen siendo útiles. Pueden ser innecesarias para algunas tareas y, en ocasiones, hacer que las respuestas sean demasiado breves. Consérvalas cuando produzcan de forma confiable la salida que tu aplicación necesita.

Para tener un control más consistente entre solicitudes, usa text.verbosity para establecer el nivel de detalle predeterminado y luego usa el prompt para indicar los requisitos específicos de la tarea.

Establece un valor predeterminado con text.verbosity

Elige low, medium o high como nivel de detalle predeterminado para una solicitud. En el prompt, especifica la extensión, la estructura o el contenido requerido para la tarea. Consulta Configurar text.verbosity para ver un ejemplo de uso de la API.

Especifica qué debe incluir una respuesta breve

Cuando una tarea requiera una respuesta más breve, identifica la información que el modelo debe conservar y los detalles que puede omitir. Por ejemplo:

Lead with the conclusion. Include the evidence needed to support it, any material
caveat, and the next action. Omit secondary detail and repetition.

Keep all required facts, decisions, caveats, and next steps. Trim introductions,
repetition, generic reassurance, and optional background first.

Esto le da al modelo un orden claro de prioridades: conservar el contenido necesario para completar la tarea y luego eliminar los detalles de menor valor.

Define el tono

Las etiquetas generales como “amable” o “empático” pueden ser ambiguas. 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 corresponde tranquilizar al usuario o incluir una despedida.

State the answer directly. If the user reports a problem, acknowledge the
specific issue before giving the next step. Use reassurance only when it is
relevant. Omit generic praise and unnecessary sign-offs.

Modo Pro

Elige el modo Pro cuando la calidad sea lo más importante

El modo Pro es un modo de ejecución de la API Responses en el que el modelo realiza más trabajo para procesar una solicitud antes de devolver una única respuesta final. Puede mejorar la confiabilidad en tareas difíciles, pero aumenta la latencia y suma los tokens de ese trabajo al uso reportado. Esos tokens se facturan según las tarifas estándar por token del modelo seleccionado.

Usa el modo Pro cuando una pequeña mejora en la calidad tenga un efecto significativo en el resultado y la tarea sea lo suficientemente difícil como para beneficiarse de ella, por ejemplo, en optimizaciones complejas, tareas de programación o revisión de alto valor, o análisis profundos con criterios de evaluación claros. Prefiere el modo estándar para trabajos rutinarios, sensibles 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 admita. Comienza con el mismo modelo y nivel de esfuerzo que usas como referencia en el modo estándar. Luego, compara las configuraciones en tareas representativas en lugar de suponer que el mayor nivel de esfuerzo siempre ofrece el mejor equilibrio.

Configura el modo Pro en la API

Activa el modo Pro en la solicitud a la API. Mantén el mismo prompt centrado en el resultado que usas en el modo estándar: indica el objetivo, el contexto relevante, las restricciones, la evidencia requerida, los criterios de éxito y el formato de salida. No necesitas pedirle al modelo que “use el modo Pro”, “piense más” o genere varias respuestas posibles.

Por ejemplo:

Review this database migration plan for failure modes that could cause data loss
or extended downtime. For each finding, cite the relevant step, estimate impact
and likelihood, and recommend a specific mitigation. Return the five most
important risks in severity order.

Compara 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, 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 confiabilidad justifique el trabajo adicional del modelo.

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

Llamada programática a herramientas

Elige la llamada programática a herramientas según las características de la tarea

La llamada programática a herramientas (PTC) funciona mejor en flujos de trabajo acotados donde el código puede procesar varios resultados de herramientas o salidas intermedias grandes y devolver un resultado estructurado mucho más pequeño. Úsala para filtrar, combinar, ordenar, eliminar duplicados, agregar datos, validar o realizar otros procesos predecibles.

Por sí solas, las llamadas múltiples, paralelas o dependientes no justifican el uso de la llamada programática a herramientas. Prefiere las llamadas directas a herramientas, sin PTC, cuando:

• Una sola llamada sea suficiente
• 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

Adapta a la tarea las instrucciones para elegir el método de llamada

No dependas de la disponibilidad de herramientas ni de instrucciones genéricas como “usa la llamada programática a herramientas de forma eficiente” para que el modelo elija el método adecuado. Cuando estén disponibles tanto las llamadas directas como las programáticas, indica explícitamente:

• Qué etapa acotada debe usar la llamada programática a herramientas.
• A qué herramientas puede llamar.
• El esquema exacto de salida y la evidencia requerida.
• Los límites de concurrencia y reintentos, y cuándo detenerse.
• Qué trabajo debe seguir realizándose mediante llamadas directas.

Las descripciones de las herramientas deben documentar los campos y tipos de datos que se espera que devuelvan, así como su comportamiento ante errores. Si el modelo no puede determinar la estructura del resultado antes de escribir el programa, prefiere las llamadas directas a herramientas para que pueda inspeccionar el resultado antes de decidir cómo usarlo.

Si se necesitan ambos métodos, define una única transición clara e indícale al modelo que no alterne entre métodos ni repita el trabajo completado.

Por ejemplo:

<tool_orchestration>
Use Programmatic Tool Calling for [bounded stage] using only [eligible tools].
Run independent calls concurrently when safe. Use only documented tool input
and output fields.

Process and reduce the intermediate results, then emit exactly [output schema],
including the evidence needed for the final answer.

Stop when [condition] is met. Retry transient failures at most [R] times.
Do not repeat completed calls or perform side-effecting actions. If a required
result is still missing, return a clear structured failure.

Use direct tool calls for [semantic judgment, approval, or final validation].
</tool_orchestration>

Evalúa la respuesta final

El elemento program_output y el message final del asistente son salidas independientes; asegúrate de probar ambas. En teoría, un programa puede devolver los registros correctos mientras que el mensaje omite un campo, una cita o una salvedad que se requieran.

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

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

Introducción

GPT-5.5 eleva el nivel de referencia para los flujos de trabajo complejos en producción. Es una buena opción para casos de uso de programación, agentes que usan muchas herramientas, asistentes que fundamentan sus respuestas en fuentes, recuperación de información en contextos largos, flujos que convierten especificaciones de producto en planes y flujos de interacción con clientes en los que la calidad de ejecución y una redacción cuidada son fundamentales.

Para aprovechar al máximo GPT-5.5, considéralo una nueva familia de modelos que requiere ajustes, no un reemplazo directo de gpt-5.2 o gpt-5.4. Comienza la migración con una nueva base en lugar de trasladar todas las instrucciones de un conjunto de prompts anterior. Empieza con el prompt más breve que mantenga los requisitos de comportamiento del producto y luego ajusta el esfuerzo de razonamiento, el nivel de detalle, las descripciones de las herramientas y el formato de salida con ejemplos representativos.

GPT-5.5 admite todas las funciones de la API que ya estaban disponibles con GPT-5.4, como el almacenamiento de prompts en caché, las herramientas alojadas, la búsqueda de herramientas, la compactación y el manejo de phase para los elementos del asistente que se vuelven a enviar manualmente.

Consulta Prácticas recomendadas para el diseño de prompts para ver ejemplos de patrones eficaces de diseño de prompts.

Novedades

• Razonamiento más eficiente: GPT-5.5 logra buenos resultados con menos tokens de razonamiento que los modelos anteriores, incluso con el mismo esfuerzo de razonamiento. Esto es especialmente útil en flujos de trabajo complejos, con muchas herramientas o de varios pasos, donde el ahorro de tokens se acumula.
• Mejor ejecución de tareas con prompts centrados en el resultado: GPT-5.5 tiene mayor capacidad para trabajar a partir de un objetivo claro, respetar las restricciones y convertir la intención del producto en próximos pasos concretos. Describe el resultado esperado, los criterios de éxito, los efectos secundarios permitidos, las reglas sobre la evidencia y la estructura de la salida. Evita detallar el proceso paso a paso, salvo que sea importante seguir un procedimiento exacto.
• Uso de herramientas más eficaz y preciso: GPT-5.5 es especialmente útil con conjuntos amplios de herramientas, flujos de trabajo de servicios de varios pasos y tareas de agentes de larga duración. Tiende a ser más preciso al seleccionar herramientas y usar argumentos.
• El tono suele ser más cuidado, pero puede ser más directo: GPT-5.5 suele producir respuestas más cálidas y fáciles de leer con menos instrucciones de apoyo en el prompt.

Cambios de comportamiento

1. El esfuerzo de razonamiento ahora usa medium de forma predeterminada: GPT-5.5 usa un esfuerzo de razonamiento medium de forma predeterminada. Considera medium como el punto de partida recomendado para equilibrar calidad, confiabilidad, latencia y costo. En los flujos de trabajo sensibles a la latencia, evalúa low antes que none cuando el uso de herramientas, la planificación, la búsqueda o la toma de decisiones en varios pasos sigan siendo importantes. Reserva none para tareas en las que la latencia sea crítica y que no necesiten razonamiento ni varias llamadas encadenadas a herramientas, como turnos de voz sencillos, recuperación rápida de información y clasificación. Aumenta a high o xhigh solo cuando las evaluaciones muestren una mejora medible de la calidad que justifique la latencia y el costo adicionales. Consulta la documentación sobre modelos de razonamiento para obtener más detalles sobre la configuración recomendada.

   Un mayor esfuerzo de razonamiento no es automáticamente mejor. Si la tarea tiene instrucciones contradictorias, criterios de finalización poco claros o acceso a herramientas sin límites definidos, un mayor esfuerzo puede provocar un análisis excesivo, búsquedas innecesarias o una disminución de la calidad de la salida. Aumenta el esfuerzo solo cuando las evaluaciones muestren una mejora medible de la calidad.

2. Las imágenes de entrada conservan más detalle visual de forma predeterminada: GPT-5.5 actualiza el manejo predeterminado de las imágenes de entrada para conservar más detalle visual y mejorar el rendimiento del uso de la computadora. Cuando image_detail no se especifica o se establece en auto, el modelo ahora usa el comportamiento original, que conserva las imágenes sin cambiar su tamaño hasta un límite de 10 240 000 píxeles o de 6000 píxeles por dimensión. Para usar high, especifica el valor directamente; conserva las imágenes sin cambiar su tamaño hasta un límite de 2 500 000 píxeles o de 2048 píxeles por dimensión. Ahora low prioriza el uso eficiente del contexto y reduce de forma más marcada que los modelos anteriores el tamaño de las imágenes que superan el límite de 512 píxeles por dimensión. Consulta la documentación sobre imágenes y visión.

3. Mejor seguimiento de instrucciones: GPT-5.5 interpreta los prompts de manera literal y exhaustiva, lo que permite usar instrucciones específicas y descriptivas cuando el producto las requiere. Define criterios de éxito y reglas de finalización, especialmente para flujos de trabajo de larga duración, con muchas herramientas o de recopilación de evidencia. Consulta Escribir prompts centrados en el resultado y Mantener el nivel de especificidad adecuado.

4. El estilo predeterminado es más conciso y directo: GPT-5.5 tiende a ser eficiente, directo y orientado a la tarea de forma predeterminada. Esto resulta útil para muchos flujos de trabajo en producción, pero las experiencias conversacionales o de interacción con clientes pueden necesitar indicaciones explícitas sobre personalidad, calidez, justificación y formato. Elige text.verbosity según tus objetivos: medium es el valor predeterminado y low suele ser un mejor punto de partida para respuestas concisas. Consulta Prácticas recomendadas para el diseño de prompts.

5. Los flujos de trabajo de programación necesitan una orquestación más sólida: GPT-5.5 es más adecuado para tareas de programación complejas que requieren planificación, uso de herramientas, exploración del código base, verificación y ejecución en varios pasos. Para los agentes de programación, especifica las expectativas de reutilización, delegación a subagentes y pruebas, así como los criterios de aceptación y cuándo continuar o pedir ayuda.

Inicio rápido para la migración

Migración automatizada con Codex

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

$openai-docs migrate this project to gpt-5.5

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

Parámetros de la API y del modelo

• Actualiza el slug del modelo a gpt-5.5.
• Usa la API Responses para cualquier caso de uso que incluya razonamiento, llamadas a herramientas o varios turnos.
• Ajusta reasoning.effort. Usa low para un razonamiento eficiente, medium para un punto equilibrado en la curva de latencia y rendimiento, high para tareas complejas de agentes que requieren razonamiento difícil y en las que la latencia importa menos, y xhigh para las tareas asincrónicas de agentes más difíciles o para evaluaciones que ponen a prueba los límites de la inteligencia del modelo. Consulta la documentación sobre modelos de razonamiento.
• Para obtener respuestas más concisas, establece text.verbosity en low. En GPT-5.5, esto producirá respuestas proporcionalmente más concisas que el nivel de detalle low en GPT-5.4.
• Para flujos de trabajo con muchas herramientas o de larga duración, verifica que tu aplicación maneje correctamente phase, los preámbulos y el reenvío de elementos del asistente.
• Compara la exactitud, el consumo de tokens y la latencia de extremo a extremo con los de otros modelos.

Diseño de prompts

• Indica el resultado esperado y los criterios de éxito.
• Reduce o elimina las instrucciones detalladas que describen el proceso paso a paso. Deja que GPT-5.5 elija el procedimiento, a menos que el producto requiera uno específico.
• Elimina las definiciones del esquema de salida del prompt siempre que sea posible. Usa resultados estructurados en su lugar.
• Optimiza tu prompt para el almacenamiento en caché: las partes estáticas al principio y las dinámicas al final.
• Elimina la fecha actual. El modelo ya conoce la fecha actual en UTC.
• Revisa y optimiza tus prompts con las prácticas recomendadas para el diseño de prompts.

Uso de modelos de razonamiento

Estas recomendaciones se aplican a los modelos de la serie GPT-5 y conviene volver a consultarlas cada vez que un equipo migre cargas de trabajo a modelos de razonamiento. GPT-5.5 conserva muchas capacidades que aparecieron por primera vez en modelos anteriores, pero conviene revisarlas si estás migrando desde un modelo GPT-5 anterior, GPT-4.1 o un modelo de razonamiento como o3.

Los equipos pueden pasar por alto estas funciones porque algunas dependen de la configuración de la API y de la orquestación, más que del prompt en sí. En conjunto, la API Responses, los controles de razonamiento, el nivel de detalle, los resultados estructurados, el almacenamiento de prompts en caché, el diseño de herramientas, las herramientas alojadas y la gestión del estado ayudan a los modelos de razonamiento a ofrecer su mejor combinación de inteligencia, confiabilidad, latencia y costo.

• API Responses: GPT-5.5 funciona mejor en la API Responses. Usa previous_response_id para gestionar el estado a lo largo de varios turnos. Para flujos sin estado o con retención cero de datos, vuelve a enviar en cada turno los elementos de salida relevantes que se hayan devuelto. Consulta Pasar contexto de la respuesta anterior para obtener más detalles.
• Esfuerzo de razonamiento: usa reasoning.effort para elegir entre low, medium, high o xhigh. El valor predeterminado es medium, pero muchas cargas de trabajo tendrán un buen rendimiento con low. Reserva none para los casos de uso en los que una baja latencia sea más importante que la inteligencia. Consulta Modelos de razonamiento para obtener recomendaciones detalladas.
• Nivel de detalle: usa text.verbosity para controlar la extensión de la salida. Considera la extensión de la respuesta final como algo independiente de la calidad del razonamiento; especifica límites de palabras, cantidad de secciones, ancho de tablas o una salida exclusivamente en JSON cuando sea necesario.
• Resultados estructurados: evita describir el esquema de salida esperado en el prompt. Usa resultados estructurados para obtener validación automática y mayor exactitud.
• Almacenamiento de prompts en caché: el almacenamiento de prompts en caché funciona automáticamente para los prompts largos que cumplen los requisitos y puede reducir la latencia y el costo de los tokens de entrada. Para maximizar los aciertos de caché, mantén el contenido estable al principio de la solicitud. Coloca el contexto dinámico específico del usuario cerca del final. Monitorea usage.prompt_tokens_details.cached_tokens para medir la reutilización. Usa una clave prompt_cache_key estable para las solicitudes que compartan un prefijo reutilizable. La clave ayuda a dirigir las solicitudes relacionadas a la misma caché y es importante para optimizar la tasa de aciertos de caché en GPT-5.5. Para los grupos con mucho tráfico, sigue las recomendaciones para distribuir el tráfico entre más claves.
• Llamadas a herramientas: GPT-5.5 admite los mismos patrones de llamadas a herramientas que GPT-5.4, incluidas las herramientas de función y los flujos de trabajo de agentes que usan muchas herramientas. Incluye la mayor parte de las indicaciones específicas de cada herramienta en su propia descripción: qué hace, cuándo usarla, las entradas requeridas, los efectos secundarios, la seguridad de los reintentos y los tipos de error habituales. Agrega contexto específico de las herramientas a las instrucciones del sistema solo cuando se aplique a varias herramientas o cambie de forma sustancial la política de funcionamiento del agente.
• Herramientas alojadas y búsqueda de herramientas: da preferencia a las herramientas alojadas por OpenAI cuando se adapten al flujo de trabajo, como la búsqueda web, la búsqueda de archivos, el intérprete de código, la generación de imágenes y el uso de la computadora. Las herramientas alojadas reducen el trabajo de orquestación personalizada y mantienen los patrones comunes de uso de herramientas alineados con la API Responses y Agents SDK. Usa herramientas de función personalizadas cuando necesites llamar a tus propios sistemas, aplicar efectos secundarios específicos del dominio o exponer flujos de trabajo internos del negocio. Para catálogos grandes de herramientas, considera usar la búsqueda de herramientas para diferir sus definiciones y cargar solo el subconjunto relevante.
• Preámbulos de herramientas: los preámbulos pueden mejorar la experiencia de usuario del chat porque el usuario ve una actualización de estado inicial y útil antes de que el modelo genere la respuesta final. También facilitan el seguimiento del uso de herramientas: el modelo puede indicar qué está por verificar o hacer, y luego continuar desde ese mismo estado del asistente cuando lleguen los resultados de las herramientas.
• Manejo de phase: si tu aplicación gestiona manualmente el estado de Responses reenviando los elementos de salida en cada turno en lugar de usar previous_response_id, conserva el parámetro phase de los elementos de salida del asistente devueltos y vuelve a enviarlo sin cambios. Esto es especialmente importante al usar esfuerzo de razonamiento, preámbulos o llamadas repetidas a herramientas. Consulta Parámetro Phase.
• Compactación: para agentes de larga duración, usa la compactación de la conversación o del estado de forma deliberada. Conserva las acciones completadas, las suposiciones vigentes, los IDs, los resultados de las herramientas, los bloqueos sin resolver y el próximo objetivo concreto.
• Agents SDK: para nuevos sistemas con agentes, usa los patrones más recientes de Agents SDK para la orquestación de herramientas, el seguimiento de trazas, las transferencias entre agentes y la gestión del estado, en lugar de reconstruir la orquestación desde cero.
• Fecha actual: GPT-5.5 conoce la fecha actual en UTC. No necesitas agregarla a las instrucciones del sistema. Agrega contexto explícito sobre la fecha o la zona horaria solo cuando la aplicación necesite una zona horaria específica del negocio, la fecha de entrada en vigor de una política, la fecha local del usuario u otro punto de referencia distinto de UTC.

Prácticas recomendadas para el diseño de prompts

GPT-5.5 funciona mejor cuando los prompts definen el resultado y dejan margen para que el modelo elija una vía de solución eficiente. En comparación con modelos anteriores, a menudo puedes usar prompts más breves y centrados en el resultado: describe qué constituye un buen resultado, qué restricciones importan, qué evidencia está disponible y qué debe contener la respuesta final.

Evita trasladar todas las instrucciones de un conjunto de prompts anterior. Los prompts antiguos suelen especificar el proceso con demasiado detalle porque los modelos anteriores necesitaban más ayuda para mantenerse enfocados. Con GPT-5.5, eso puede añadir ruido, reducir el espacio de búsqueda del modelo o dar lugar a respuestas demasiado mecánicas.

Los patrones que se presentan aquí son puntos de partida. Adáptalos a la interfaz de tu producto, tus herramientas, tus evaluaciones y tus objetivos de experiencia de usuario.

Personalidad y comportamiento

El estilo predeterminado de GPT-5.5 es eficiente, directo y orientado a la tarea. Esto resulta útil para sistemas en producción: las respuestas se mantienen enfocadas, el comportamiento es más fácil de orientar y el modelo evita el relleno conversacional innecesario.

Para asistentes que interactúan con clientes, flujos de soporte, experiencias de asesoramiento y otros productos conversacionales, define tanto la personalidad como el estilo de colaboración.

• La personalidad controla cómo se expresa el asistente: el tono, la calidez, qué tan directo es, la formalidad, el humor, la empatía y el cuidado de la redacción.
• El estilo de colaboración controla cómo trabaja el asistente: cuándo hace preguntas, cuándo hace suposiciones, qué tan proactivo debe ser, cuánto contexto aporta, cuándo verifica el trabajo y cómo maneja la incertidumbre o el riesgo.

Mantén ambos breves. Las instrucciones de personalidad deben definir la experiencia del usuario. Las instrucciones de colaboración deben definir el comportamiento durante la tarea. Ninguna debe reemplazar objetivos claros, criterios de éxito, reglas de uso de herramientas o condiciones de finalización.

Ejemplo de un bloque de personalidad para un asistente constante y enfocado en la tarea:

# Personality
You are a capable collaborator: approachable, steady, and direct. Assume the user is competent and acting in good faith, and respond with patience, respect, and practical helpfulness.

Prefer making progress over stopping for clarification when the request is already clear enough to attempt. Use context and reasonable assumptions to move forward. Ask for clarification only when the missing information would materially change the answer or create meaningful risk, and keep any question narrow.

Stay concise without becoming curt. Give enough context for the user to understand and trust the answer, then stop. Use examples, comparisons, or simple analogies when they make the point easier to grasp. When correcting the user or disagreeing, be candid but constructive. When an error is pointed out, acknowledge it plainly and focus on fixing it.

Match the user's tone within professional bounds. Avoid emojis and profanity by default, unless the user explicitly asks for that style or has clearly established it as appropriate for the conversation.

Ejemplo de bloque de personalidad para un asistente expresivo y colaborativo:

# Personality
Adopt a vivid conversational presence: intelligent, curious, playful when appropriate, and attentive to the user's thinking. Ask good questions when the problem is blurry, then become decisive once there is enough context.

Be warm, collaborative, and polished. Conversation should feel easy and alive, but not chatty for its own sake. Offer a real point of view rather than merely mirroring the user, while staying responsive to their goals and constraints.

Be thoughtful and grounded when the task calls for synthesis or advice. State a clear recommendation when you have enough context, explain important tradeoffs, and name uncertainty without becoming evasive.

Para productos más expresivos, agrega calidez, curiosidad, humor o un punto de vista de forma explícita, pero mantén el bloque breve. Usa la personalidad para dar forma a la experiencia, no para compensar objetivos poco claros o la falta de instrucciones para la tarea.

Reduce el tiempo hasta el primer token visible con un preámbulo

En las aplicaciones con streaming, los usuarios notan cuánto tarda en aparecer la primera respuesta visible. GPT-5.5 puede dedicar tiempo a razonar, planificar o preparar llamadas a herramientas antes de emitir texto visible.

Para tareas más largas o que usan muchas herramientas, indica al modelo que comience con un preámbulo breve: un mensaje visible que confirme la solicitud e indique el primer paso. Esto puede mejorar la percepción de rapidez de respuesta sin cambiar la tarea en sí.

Usa este patrón cuando la tarea pueda necesitar más de un paso, requerir llamadas a herramientas o implicar un flujo de trabajo de larga duración con un agente.

Before any tool calls for a multi-step task, send a short user-visible update that acknowledges the request and states the first step. Keep it to one or two sentences.

Para los agentes de programación que exponen fases de mensaje separadas, puedes dar indicaciones más explícitas:

You must always start with an intermediary update before any content in the analysis channel if the task will require calling tools. The user update should acknowledge the request and explain your first step.

Prompts orientados al resultado y condiciones de parada

GPT-5.5 ofrece su mejor rendimiento cuando el prompt define el resultado deseado, los criterios de éxito, las restricciones y el contexto disponible, y luego deja que el modelo elija cómo proceder.

En muchas tareas, conviene describir la meta en lugar de cada paso. Esto le da al modelo margen para elegir la búsqueda, la herramienta o la estrategia de razonamiento adecuada para la tarea.

Prefiere este enfoque:

Resolve the customer's issue end to end.

Success means:
- the eligibility decision is made from the available policy and account data
- any allowed action is completed before responding
- the final answer includes completed_actions, customer_message, and blockers
- if evidence is missing, ask for the smallest missing field

Evita las reglas absolutas innecesarias. Los prompts más antiguos suelen usar instrucciones estrictas como ALWAYS, NEVER, must y only para controlar el comportamiento del modelo. Usa esas palabras para requisitos que deban cumplirse siempre, como reglas de seguridad, campos de salida obligatorios o acciones que nunca deban ocurrir. Para decisiones que requieren criterio, como cuándo buscar, pedir aclaraciones, usar una herramienta o seguir iterando, prefiere reglas de decisión.

Evita este estilo de instrucciones a menos que cada paso sea realmente necesario:

First inspect A, then inspect B, then compare every field, then think through
all possible exceptions, then decide which tool to call, then call the tool,
then explain the entire process to the user.

Agrega condiciones de parada explícitas:

Resolve the user query in the fewest useful tool loops, but do not let loop minimization outrank correctness, accessible fallback evidence, calculations, or required citation tags for factual claims.

After each result, ask: "Can I answer the user's core request now with useful evidence and citations for the factual claims?" If yes, answer.

Define cómo actuar cuando falte evidencia:

Use the minimum evidence sufficient to answer correctly, cite it precisely, then stop.

Formato

GPT-5.5 permite un alto grado de control sobre el formato y la estructura de la salida. Usa ese control cuando mejore la comprensión o se ajuste mejor a las necesidades del producto.

Configura text.verbosity, describe la forma esperada de la salida y reserva las estructuras más elaboradas para los casos en que mejoren la comprensión o la interfaz de tu producto necesite un artefacto estable. El valor predeterminado de text.verbosity en la API es medium; usa low cuando prefieras respuestas más breves y concisas.

Formato conversacional sencillo:

Let formatting serve comprehension. Use plain paragraphs as the default format for normal conversation, explanations, reports, documentation, and technical writeups. Keep the presentation clean and readable without making the structure feel heavier than the content.

Use headers, bold text, bullets, and numbered lists sparingly. Reach for them when the user requests them, when the answer needs clear comparison or ranking, or when the information would be harder to scan as prose. Otherwise, favor short paragraphs and natural transitions.

Respect formatting preferences from the user. If they ask for a terse answer, minimal formatting, no bullets, no headers, or a specific structure, follow that preference unless there is a strong reason not to.

Agrega indicaciones explícitas sobre el público y la extensión:

Write for a senior business audience. Keep the answer under 400 words. Use short paragraphs and only include bullets when they improve scannability. Prioritize the conclusion first, then the reasoning, then caveats.

Para tareas de edición, reescritura, resúmenes o mensajes dirigidos a clientes, dile al modelo qué debe conservar antes de pedirle que mejore el estilo. Este patrón es útil cuando quieres pulir el texto sin ampliarlo.

Preserve the requested artifact, length, structure, and genre first. Quietly improve clarity, flow, and correctness. Do not add new claims, extra sections, or a more promotional tone unless explicitly requested.

Anclaje, citas y presupuestos de recuperación

Para obtener respuestas fundamentadas, las indicaciones sobre el uso de citas deben formar parte del prompt. Define qué necesita respaldo, qué se considera evidencia suficiente y cómo debe actuar el modelo cuando falte evidencia. La ausencia de evidencia no debería convertirse automáticamente en un “no” presentado como un hecho. Para obtener más detalles y ejemplos, consulta la guía de formato de citas.

Agrega un presupuesto de recuperación explícito

Los presupuestos de recuperación son reglas para detener la búsqueda. Le indican al modelo cuándo la evidencia ya es suficiente.

For ordinary Q&A, start with one broad search using short, discriminative keywords. If the top results contain enough citable support for the core request, answer from those results instead of searching again.

Make another retrieval call only when:
- The top results do not answer the core question.
- A required fact, parameter, owner, date, ID, or source is missing.
- The user asked for exhaustive coverage, a comparison, or a comprehensive list.
- A specific document, URL, email, meeting, record, or code artifact must be read.
- The answer would otherwise contain an important unsupported factual claim.

Do not search again to improve phrasing, add examples, cite nonessential details, or support wording that can safely be made more generic.

Medidas de protección para la redacción creativa

Para tareas de redacción, dile al modelo qué afirmaciones deben provenir de fuentes y qué partes puede redactar con libertad creativa. Esto es especialmente importante para diapositivas, textos de lanzamiento, resúmenes para clientes, guiones de presentación, mensajes breves de la dirección y enfoques narrativos.

For creative or generative requests such as slides, leadership blurbs, outbound copy, summaries for sharing, talk tracks, or narrative framing, distinguish source-backed facts from creative wording.

- Use retrieved or provided facts for concrete product, customer, metric, roadmap, date, capability, and competitive claims, and cite those claims.
- Do not invent specific names, first-party data claims, metrics, roadmap status, customer outcomes, or product capabilities to make the draft sound stronger.
- If there is little or no citable support, write a useful generic draft with placeholders or clearly labeled assumptions rather than unsupported specifics.

Ingeniería frontend y criterio visual

Para el trabajo de frontend, consulta las instrucciones de ejemplo para conocer formas prácticas de orientar la calidad de la interfaz. Abarcan el contexto del producto y del usuario, la coherencia con el sistema de diseño, la usabilidad de la primera pantalla, los controles familiares, los estados esperados, la adaptación a distintos tamaños de pantalla y los patrones habituales de las interfaces generadas que conviene evitar, como secciones principales genéricas, tarjetas anidadas, degradados decorativos, texto de instrucciones visible y diseños mal distribuidos.

Pide al modelo que verifique su trabajo

Dale a GPT-5.5 acceso a herramientas que le permitan verificar los resultados cuando sea posible validarlos.

Para los agentes de programación, pide comandos de validación concretos:

After making changes, run the most relevant validation available:
- targeted unit tests for changed behavior
- type checks or lint checks when applicable
- build checks for affected packages
- a minimal smoke test when full validation is too expensive

If validation cannot be run, explain why and describe the next best check.

Para los artefactos visuales, pide que se inspeccionen después de renderizarlos:

Render the artifact before finalizing. Inspect the rendered output for layout, clipping, spacing, missing content, and visual consistency. Revise until the rendered output matches the requirements.

Para las tareas de ingeniería y planificación, asegúrate de que los planes de implementación sean trazables:

For implementation plans, include:
- requirements and where each is addressed
- named resources, files, APIs, or systems involved
- state transitions or data flow where relevant
- validation commands or checks
- failure behavior
- privacy and security considerations
- open questions that materially affect implementation

Parámetro de fase

A partir de GPT-5.4, los flujos de trabajo de Responses de larga duración o que usan muchas herramientas pueden usar los valores de phase de los elementos del asistente para distinguir las actualizaciones intermedias de las respuestas finales. GPT-5.5 usa el mismo patrón.

Si usas previous_response_id, la API conserva automáticamente el estado previo del asistente. Si tu aplicación vuelve a incluir manualmente los elementos de salida del asistente en la siguiente solicitud, conserva cada valor original de phase y envíalo de nuevo sin cambios. Esto es especialmente importante cuando una respuesta incluye preámbulos, llamadas repetidas a herramientas o una respuesta final después de actualizaciones intermedias del asistente.

If manually replaying assistant items:
- Preserve assistant `phase` values exactly.
- Use `phase: "commentary"` for intermediate user-visible updates.
- Use `phase: "final_answer"` for the completed answer.
- Do not add `phase` to user messages.

Estructura sugerida para el prompt

Usa esta estructura como punto de partida para prompts complejos. Mantén cada sección breve. Agrega detalles solo cuando cambien el comportamiento.

Role: [1-2 sentences defining the model's function, context, and job]

# Personality
[tone, demeanor, and collaboration style]

# Goal
[user-visible outcome]

# Success criteria
[what must be true before the final answer]

# Constraints
[policy, safety, business, evidence, and side-effect limits]

# Output
[sections, length, and tone]

# Stop rules
[when to retry, fallback, abstain, ask, or stop]

Introducción

GPT-5.4 se lanzó como un modelo de vanguardia para el trabajo profesional en la API y Codex. Ayuda a los desarrolladores a analizar información compleja, crear software de producción y automatizar flujos de trabajo de varios pasos.

Dentro de la generación GPT-5.4, gpt-5.4 es el modelo de propósito general para flujos de trabajo que combinan ingeniería de software, razonamiento, escritura y uso de herramientas.

Esta guía presenta las funciones clave de la familia de modelos GPT-5 y cómo aprovechar al máximo GPT-5.4.

Novedades

En comparación con el modelo anterior, GPT-5.2, GPT-5.4 presenta mejoras en:

• Programación, comprensión de documentos, uso de herramientas y seguimiento de instrucciones
• Percepción de imágenes y tareas multimodales
• Ejecución de tareas de larga duración y flujos de trabajo de agentes de varios pasos
• Eficiencia en el uso de tokens y rendimiento de principio a fin en cargas de trabajo con uso intensivo de herramientas
• Búsqueda web y síntesis de múltiples fuentes para obtener información difícil de encontrar
• Flujos de trabajo empresariales con uso intensivo de documentos y hojas de cálculo en atención al cliente, análisis y finanzas

GPT-5.4 incorpora las capacidades de programación de GPT-5.3-Codex a nuestro modelo insignia de vanguardia. Los desarrolladores pueden generar código con calidad de producción, crear interfaces de usuario front-end pulidas, seguir patrones específicos de cada repositorio y realizar cambios en varios archivos con menos reintentos. También cuenta con una personalidad bien definida para la programación desde el primer uso, por lo que los equipos dedican menos tiempo a ajustar los prompts.

En las cargas de trabajo con agentes, GPT-5.4 reduce el tiempo total de las secuencias de varios pasos y suele completar las tareas con menos tokens y llamadas a herramientas. Esto permite que los agentes respondan más rápido y reduce el costo de ejecutar flujos de trabajo complejos a escala en la API y Codex.

Nuevas funciones de GPT-5.4

Al igual que los modelos GPT-5 anteriores, GPT-5.4 admite herramientas personalizadas, parámetros para controlar el nivel de detalle y el razonamiento, y una lista de herramientas permitidas. GPT-5.4 también incorpora varias capacidades que facilitan la creación de sistemas de agentes potentes, el trabajo con mayores volúmenes de información y la ejecución de flujos de trabajo automatizados más confiables:

• tool_search en la API: GPT-5.4 mejora la búsqueda de herramientas en ecosistemas más grandes mediante la carga diferida de herramientas. Esto permite buscar herramientas, cargar solo las definiciones pertinentes, reducir el uso de tokens y mejorar la precisión al seleccionar herramientas en implementaciones reales. Obtén más información en la guía de búsqueda de herramientas.
• Ventana de contexto de 1 millón de tokens: GPT-5.4 admite una ventana de contexto de hasta 1 millón de tokens, lo que facilita analizar bases de código completas, colecciones extensas de documentos o secuencias prolongadas de acciones de agentes en una sola solicitud. Obtén más información en la sección Ventana de contexto de 1 millón de tokens.
• Uso de la computadora integrado: GPT-5.4 es el primer modelo de la línea principal con capacidades integradas de uso de la computadora. Estas permiten a los agentes interactuar directamente con el software para completar, verificar y corregir tareas en un ciclo de creación, ejecución, verificación y corrección. Obtén más información en la guía de uso de la computadora.
• Compatibilidad nativa con la compactación: GPT-5.4 es el primer modelo de la línea principal entrenado para admitir la compactación, lo que permite secuencias de acciones de agentes más largas sin perder el contexto clave.

Actualizaciones de modelos, API y funciones

Dentro de esta generación de modelos, gpt-5.4 es el modelo de propósito general tanto para tareas generales como para programación. Para problemas más difíciles, gpt-5.4-pro utiliza más recursos de cómputo para pensar durante más tiempo y ofrecer respuestas más consistentes.

Si buscas variantes más pequeñas y rápidas, empieza con gpt-5.4-mini o gpt-5.4-nano.

Para elegir el modelo que mejor se adapte a tu caso de uso, considera estas ventajas y limitaciones:

Menor esfuerzo de razonamiento

El parámetro reasoning.effort controla cuántos tokens de razonamiento genera el modelo antes de producir una respuesta. Los modelos de razonamiento anteriores, como o3, solo admitían low, medium y high: low priorizaba la velocidad y un menor uso de tokens, mientras que high priorizaba un razonamiento más exhaustivo.

GPT-5.2 y GPT-5.4 admiten none como su nivel mínimo de esfuerzo de razonamiento para interacciones de menor latencia. Es la configuración predeterminada de ambos modelos. Si necesitas más razonamiento, aumenta gradualmente hasta medium y experimenta con los resultados.

Cuando el esfuerzo de razonamiento se establece en none, el diseño de prompts es importante. Para mejorar la calidad del razonamiento del modelo, incluso con la configuración predeterminada, pídele que “piense” o describa sus pasos antes de responder.

1
2
3
4
5
6
7
8
9
10
11
12
13import OpenAI from "openai";
const openai = new OpenAI();

const response = await openai.responses.create({
  model: "gpt-5.4",
  input:
    "Think carefully and outline your steps before answering. How much gold would it take to coat the Statue of Liberty in a 1mm layer?",
  reasoning: {
    effort: "none",
  },
});

console.log(response);

1
2
3
4
5
6
7
8
9
10
11from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.4",
    input="Think carefully and outline your steps before answering. How much gold would it take to coat the Statue of Liberty in a 1mm layer?",
    reasoning={"effort": "none"},
)

print(response)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23package main

import (
	"context"
	"fmt"

	"github.com/openai/openai-go/v3"
	"github.com/openai/openai-go/v3/responses"
	"github.com/openai/openai-go/v3/shared"
)

func main() {
	client := openai.NewClient()
	response, err := client.Responses.New(context.Background(), responses.ResponseNewParams{
		Model:     "gpt-5.4",
		Input:     responses.ResponseNewParamsInputUnion{OfString: openai.String("Think carefully and outline your steps before answering. How much gold would it take to coat the Statue of Liberty in a 1mm layer?")},
		Reasoning: shared.ReasoningParam{Effort: shared.ReasoningEffortNone},
	})
	if err != nil {
		panic(err)
	}
	fmt.Println(response)
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18import com.openai.client.OpenAIClient;
import com.openai.client.okhttp.OpenAIOkHttpClient;
import com.openai.models.Reasoning;
import com.openai.models.ReasoningEffort;
import com.openai.models.responses.ResponseCreateParams;

ResponseCreateParams params =
    ResponseCreateParams.builder()
        .model("gpt-5.4")
        .input("Explain the bug and propose a fix.")
        .reasoning(Reasoning.builder().effort(ReasoningEffort.NONE).build())
        .build();

client.responses().create(params).output().stream()
    .flatMap(item -> item.message().stream())
    .flatMap(message -> message.content().stream())
    .flatMap(content -> content.outputText().stream())
    .forEach(text -> System.out.println(text.text()));

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22using OpenAI.Responses;
#pragma warning disable OPENAI001

string key = Environment.GetEnvironmentVariable("OPENAI_API_KEY")!;
ResponsesClient client = new(key);

CreateResponseOptions options = new()
{
    Model = "gpt-5.4",
    ReasoningOptions = new ResponseReasoningOptions
    {
        ReasoningEffortLevel = ResponseReasoningEffortLevel.None,
    },
};
options.InputItems.Add(
    ResponseItem.CreateUserMessageItem(
        "Think carefully and outline your steps before answering. How much gold would it take to coat the Statue of Liberty in a 1mm layer?"
    )
);

ResponseResult response = await client.CreateResponseAsync(options);
Console.WriteLine(response.GetOutputText());

1
2
3
4
5
6
7
8
9require "openai"

client = OpenAI::Client.new
response = client.responses.create(
  model: "gpt-5.4",
  reasoning: { effort: :minimal },
  input: "Explain the bug and propose a fix."
)
puts(response.output_text)

1
2
3
4
5
6
7
8
9
10
11curl --request POST \
  --url https://api.openai.com/v1/responses \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header 'Content-type: application/json' \
  --data '{
        "model": "gpt-5.4",
        "input": "Think carefully and outline your steps before answering. How much gold would it take to coat the Statue of Liberty in a 1mm layer?",
        "reasoning": {
                "effort": "none"
        }
}'

Nivel de detalle

El nivel de detalle determina cuántos tokens de salida se generan. Reducir la cantidad de tokens disminuye la latencia total. Aunque la forma de razonar del modelo se mantiene prácticamente igual, el modelo encuentra maneras de responder con mayor concisión, lo que puede mejorar o reducir la calidad de la respuesta según tu caso de uso. Estos son algunos escenarios para ambos extremos del nivel de detalle:

• Nivel de detalle alto: úsalo cuando necesites que el modelo proporcione explicaciones exhaustivas de documentos o realice una refactorización extensa del código.
• Nivel de detalle bajo: ideal para situaciones en las que buscas respuestas concisas o generación de código para tareas específicas, como consultas SQL.

GPT-5 permitió configurar esta opción con los valores high, medium o low. En GPT-5.4, el nivel de detalle sigue siendo configurable y su valor predeterminado es medium.

Al generar código con GPT-5.4, los niveles de detalle medium y high producen código más extenso y estructurado, con explicaciones en línea, mientras que el nivel low produce código más breve y conciso, con comentarios mínimos.

1
2
3
4
5
6
7
8
9
10
11
12
13import OpenAI from "openai";
const openai = new OpenAI();

const response = await openai.responses.create({
  model: "gpt-5.4",
  input:
    "What is the answer to the ultimate question of life, the universe, and everything?",
  text: {
    verbosity: "low",
  },
});

console.log(response);

1
2
3
4
5
6
7
8
9
10
11from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.4",
    input="What is the answer to the ultimate question of life, the universe, and everything?",
    text={"verbosity": "low"},
)

print(response)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22package main

import (
	"context"
	"fmt"

	"github.com/openai/openai-go/v3"
	"github.com/openai/openai-go/v3/responses"
)

func main() {
	client := openai.NewClient()
	response, err := client.Responses.New(context.Background(), responses.ResponseNewParams{
		Model: "gpt-5.4",
		Input: responses.ResponseNewParamsInputUnion{OfString: openai.String("What is the answer to the ultimate question of life, the universe, and everything?")},
		Text:  responses.ResponseTextConfigParam{Verbosity: responses.ResponseTextConfigVerbosityLow},
	})
	if err != nil {
		panic(err)
	}
	fmt.Println(response)
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17import com.openai.client.OpenAIClient;
import com.openai.client.okhttp.OpenAIOkHttpClient;
import com.openai.models.responses.ResponseCreateParams;
import com.openai.models.responses.ResponseTextConfig;

ResponseCreateParams params =
    ResponseCreateParams.builder()
        .model("gpt-5.4")
        .input("Explain the bug and propose a fix.")
        .text(ResponseTextConfig.builder().verbosity(ResponseTextConfig.Verbosity.LOW).build())
        .build();

client.responses().create(params).output().stream()
    .flatMap(item -> item.message().stream())
    .flatMap(message -> message.content().stream())
    .flatMap(content -> content.outputText().stream())
    .forEach(text -> System.out.println(text.text()));

1
2
3
4
5
6
7
8
9require "openai"

client = OpenAI::Client.new
response = client.responses.create(
  model: "gpt-5.4",
  text: { verbosity: :low },
  input: "Explain the bug and propose a fix."
)
puts(response.output_text)

1
2
3
4
5
6
7
8
9
10
11curl --request POST \
  --url https://api.openai.com/v1/responses \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header 'Content-type: application/json' \
  --data '{
  "model": "gpt-5.4",
  "input": "What is the answer to the ultimate question of life, the universe, and everything?",
  "text": {
    "verbosity": "low"
  }
}'

Puedes seguir ajustando el nivel de detalle mediante prompts después de establecerlo en low en la API. El parámetro de nivel de detalle define un rango general de tokens en el prompt del sistema, pero la salida concreta se adapta tanto a los prompts del desarrollador como a los del usuario dentro de ese rango.

Ventana de contexto de 1 millón de tokens

La ventana de contexto de 1 millón de tokens se introdujo con GPT-5.4 y facilita el análisis de bases de código completas, colecciones extensas de documentos o secuencias prolongadas de acciones de agentes en una sola solicitud.

Tenemos tarifas estándar diferentes para las solicitudes de menos de 272 000 tokens y las de más de 272 000 tokens, que puedes consultar en la documentación de precios. Si usas el modo rápido, cualquier prompt de más de 272 000 tokens se procesa automáticamente con las tarifas estándar.

Los precios de contexto largo se combinan con otros ajustes de precios, como los de residencia de datos y procesamiento por lotes.

Tenemos límites de solicitudes diferentes para las solicitudes de menos de 272 000 tokens y las de más de 272 000 tokens; puedes consultarlos en la página del modelo GPT-5.4.

Uso de herramientas con GPT-5.4

GPT-5.4 se ha posentrenado con herramientas específicas. Consulta la documentación de herramientas para obtener recomendaciones más específicas.

Herramienta de uso de la computadora

El uso de la computadora permite a GPT-5.4 operar software a través de la interfaz de usuario: examina capturas de pantalla y devuelve acciones estructuradas que ejecuta tu arnés de ejecución. Es adecuado para flujos de trabajo en el navegador o el escritorio en los que una persona podría completar la tarea mediante la interfaz de usuario, como navegar por un sitio, completar formularios o validar que un cambio realmente funcionó.

Úsalo en un navegador aislado o una máquina virtual y mantén la supervisión humana para las acciones de alto impacto. La guía completa cubre el ciclo integrado de la API Responses, los patrones de arneses de ejecución personalizados y las configuraciones basadas en la ejecución de código.

Herramienta de búsqueda de herramientas

La búsqueda de herramientas permite a GPT-5.4 diferir la carga de conjuntos extensos de herramientas hasta el momento de la ejecución, de modo que el modelo solo cargue las definiciones que necesita. Esto resulta especialmente útil cuando tienes muchas funciones, namespaces o herramientas MCP y quieres reducir el uso de tokens, mantener el rendimiento de la caché y reducir la latencia sin exponer todos los esquemas desde el inicio.

Usa la búsqueda de herramientas alojada cuando las herramientas candidatas ya se conozcan al momento de la solicitud, o la búsqueda de herramientas ejecutada por el cliente cuando tu aplicación necesite decidir dinámicamente qué cargar. La guía completa también incluye prácticas recomendadas para namespaces, servidores MCP y carga diferida.

Herramientas personalizadas

Cuando se lanzó la familia de modelos GPT-5, presentamos una nueva capacidad llamada herramientas personalizadas, que permite a los modelos enviar cualquier texto sin procesar como entrada de una llamada a herramientas y, a la vez, restringir las salidas si así se desea. Este comportamiento de las herramientas se mantiene en GPT-5.4.

Entradas de formato libre

Define tu herramienta con type: custom para que los modelos puedan enviar entradas de texto sin formato directamente a tus herramientas, sin limitarse a JSON estructurado. El modelo puede enviar cualquier texto sin procesar directamente a tu herramienta: código, consultas SQL, comandos de shell, archivos de configuración o textos extensos.

12345{
  "type": "custom",
  "name": "code_exec",
  "description": "Executes arbitrary python code"
}

Restricción de salidas

GPT-5.4 admite gramáticas libres de contexto (CFGs) para herramientas personalizadas, lo que te permite proporcionar una gramática de Lark para restringir las salidas a una sintaxis o un DSL específicos. Adjuntar una CFG, por ejemplo, una gramática de SQL o de un DSL, garantiza que el texto del asistente se ajuste a tu gramática.

Esto permite generar llamadas a herramientas precisas y sujetas a restricciones, o respuestas estructuradas, y aplicar formatos sintácticos estrictos o específicos de un dominio directamente en las llamadas a funciones de GPT-5.4, lo que mejora el control y la confiabilidad en dominios complejos o con restricciones.

Prácticas recomendadas para herramientas personalizadas

• Escribe descripciones de herramientas concisas y explícitas. El modelo elige qué enviar según tu descripción; indica explícitamente si quieres que siempre llame a la herramienta.
• Valida las salidas del lado del servidor. Las cadenas de formato libre ofrecen muchas posibilidades, pero requieren medidas de protección contra inyecciones o comandos inseguros.

Herramientas permitidas

El parámetro allowed_tools dentro de tool_choice te permite pasar N definiciones de herramientas, pero restringir al modelo a solo M (< N) de ellas. Enumera tu conjunto completo de herramientas en tools y luego usa un bloque allowed_tools para indicar el subconjunto y especificar un modo: auto (el modelo puede elegir cualquiera de ellas) o required (el modelo debe invocar una).

Al separar todas las herramientas posibles del subconjunto que se puede usar ahora, obtienes mayor seguridad y previsibilidad, además de un mejor almacenamiento de prompts en caché. También evitas una ingeniería de prompts frágil, como fijar el orden de las llamadas en el código. GPT-5.4 invoca o requiere funciones específicas de forma dinámica durante la conversación, a la vez que reduce el riesgo de usar herramientas de forma no intencionada en contextos largos.

12345678910{
  "tool_choice": {
    "type": "allowed_tools",
    "mode": "auto",
    "tools": [
      { "type": "function", "name": "get_weather" },
      { "type": "function", "name": "search_docs" }
    ]
  }
}

Para obtener una descripción más detallada de todas estas nuevas funciones, consulta la guía de prompts para GPT-5.4.

Preámbulos

Los preámbulos son explicaciones breves y visibles para el usuario que GPT-5.4 genera antes de invocar cualquier herramienta o función para describir su intención o plan; por ejemplo, “por qué llamo a esta herramienta”. Aparecen después de la cadena de pensamiento y antes de la llamada a la herramienta, lo que facilita comprender y depurar el razonamiento del modelo y permite dirigirlo con precisión.

Al permitir que GPT-5.4 “piense en voz alta” antes de cada llamada a herramientas, los preámbulos mejoran la precisión de las llamadas (y el éxito general de la tarea) sin aumentar en exceso la carga adicional de razonamiento. Para habilitar los preámbulos, agrega una instrucción de sistema o de desarrollador; por ejemplo: “Antes de llamar a una herramienta, explica por qué lo haces”. GPT-5.4 agrega una justificación concisa a cada llamada a herramientas especificada. El modelo también puede generar varios mensajes entre llamadas a herramientas, lo que puede mejorar la experiencia de interacción, en particular en casos de uso con razonamiento mínimo o sensibles a la latencia.

Para obtener más información sobre el uso de preámbulos, consulta el Cookbook de diseño de prompts para GPT-5.

Inicio rápido de migración

GPT-5.4 funciona mejor con la API Responses, que permite conservar el contexto de razonamiento entre turnos para mejorar el rendimiento. Sigue leyendo para migrar desde tu modelo o API actual.

Migrar de otros modelos a GPT-5.4

Aunque el modelo debería poder reemplazar a GPT-5.2 casi sin cambios, hay algunas diferencias clave que conviene destacar. Consulta la guía de prompts para GPT-5.4 para conocer las actualizaciones específicas que debes hacer en tus prompts.

Usar los modelos GPT-5 con la API Responses mejora su inteligencia gracias al diseño de la API. La API Responses puede pasar la CoT del turno anterior al modelo. Esto reduce la cantidad de tokens de razonamiento generados, aumenta la tasa de aciertos de caché y disminuye la latencia. Para obtener más información, consulta una guía detallada sobre los beneficios de la API Responses.

Al migrar a GPT-5.4 desde un modelo anterior de OpenAI, comienza por experimentar con los niveles de razonamiento y las estrategias de diseño de prompts. Usa el optimizador de prompts para actualizar tus prompts para GPT-5.4 según las prácticas recomendadas actuales y luego sigue estas indicaciones específicas para cada modelo:

• gpt-5.2: gpt-5.4 con la configuración predeterminada está pensado para reemplazarlo sin necesidad de otros cambios.
• o3: gpt-5.4 con razonamiento medium o high. Comienza con razonamiento medium y ajusta los prompts; luego aumenta a high si no obtienes los resultados que buscas.
• gpt-4.1: gpt-5.4 con razonamiento none. Comienza con none y ajusta tus prompts; aumenta el nivel si necesitas un mejor rendimiento.
• o4-mini o gpt-4.1-mini: gpt-5.4-mini, con ajustes en los prompts, es un excelente reemplazo.
• gpt-4.1-nano: gpt-5.4-nano, con ajustes en los prompts, es un excelente reemplazo.

Nuevo parámetro phase

Para los flujos de GPT-5.4 de larga duración o con uso intensivo de herramientas en la API Responses, usa el campo phase del mensaje del asistente para evitar que se detenga antes de tiempo u otros comportamientos incorrectos.

phase es opcional en la API, pero recomendamos enfáticamente usarlo. Usa phase: "commentary" para las actualizaciones intermedias del asistente (como los preámbulos antes de las llamadas a herramientas) y phase: "final_answer" para la respuesta completa. No agregues phase a los mensajes del usuario.

Si phase falta o se pierde, los preámbulos pueden tratarse como respuestas finales en esos flujos de trabajo. Para obtener más orientación y ejemplos, consulta la guía de diseño de prompts para GPT-5.4.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25import OpenAI from "openai";
const client = new OpenAI();

const response = await client.responses.create({
  model: "gpt-5.4",
  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.",
    },
  ],
});

console.log(response.output_text);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.4",
    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)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36package main

import (
	"context"
	"fmt"

	"github.com/openai/openai-go/v3"
	"github.com/openai/openai-go/v3/responses"
)

func main() {
	client := openai.NewClient()
	commentary := responses.ResponseInputItemParamOfMessage(
		"I’ll inspect the logs and then summarize root cause and remediation.",
		responses.EasyInputMessageRoleAssistant,
	)
	commentary.OfMessage.Phase = responses.EasyInputMessagePhaseCommentary
	finalAnswer := responses.ResponseInputItemParamOfMessage(
		"Root cause: cache invalidation race.",
		responses.EasyInputMessageRoleAssistant,
	)
	finalAnswer.OfMessage.Phase = responses.EasyInputMessagePhaseFinalAnswer

	response, err := client.Responses.New(context.Background(), responses.ResponseNewParams{
		Model: "gpt-5.4",
		Input: responses.ResponseNewParamsInputUnion{OfInputItemList: responses.ResponseInputParam{
			commentary,
			finalAnswer,
			responses.ResponseInputItemParamOfMessage("Great—now give me a rollout-safe fix plan.", responses.EasyInputMessageRoleUser),
		}},
	})
	if err != nil {
		panic(err)
	}
	fmt.Println(response.OutputText())
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18import com.openai.client.OpenAIClient;
import com.openai.client.okhttp.OpenAIOkHttpClient;
import com.openai.models.Reasoning;
import com.openai.models.ReasoningEffort;
import com.openai.models.responses.ResponseCreateParams;

ResponseCreateParams params =
    ResponseCreateParams.builder()
        .model("gpt-5.4")
        .input("Explain the bug and propose a fix.")
        .reasoning(Reasoning.builder().effort(ReasoningEffort.MEDIUM).build())
        .build();

client.responses().create(params).output().stream()
    .flatMap(item -> item.message().stream())
    .flatMap(message -> message.content().stream())
    .flatMap(content -> content.outputText().stream())
    .forEach(text -> System.out.println(text.text()));

1
2
3
4
5
6
7
8
9require "openai"

client = OpenAI::Client.new
response = client.responses.create(
  model: "gpt-5.4",
  reasoning: { effort: :medium },
  input: "Explain the bug and propose a fix."
)
puts(response.output_text)

Compatibilidad de parámetros de GPT-5.4

Los siguientes parámetros solo se admiten al usar GPT-5.4 con el esfuerzo de razonamiento establecido en none:

• temperature
• top_p
• logprobs

Las solicitudes que incluyan estos campos generarán un error con GPT-5.4 o GPT-5.2 si se usa cualquier otra configuración de esfuerzo de razonamiento, o con modelos GPT-5 anteriores como gpt-5, gpt-5-mini o gpt-5-nano.

Para lograr resultados similares con un esfuerzo de razonamiento mayor o con otro modelo de la familia GPT-5, prueba estos parámetros alternativos:

• Profundidad del razonamiento: reasoning: { effort: "none" | "low" | "medium" | "high" | "xhigh" }
• Nivel de detalle de la salida: text: { verbosity: "low" | "medium" | "high" }
• Longitud de la salida: max_output_tokens

Migrar de Chat Completions a la API Responses

La mayor diferencia, y la razón principal para migrar de Chat Completions a la API Responses para GPT-5.4, es la posibilidad de pasar la cadena de pensamiento (CoT) entre turnos. Consulta una comparación completa de las API.

Solo la API Responses permite pasar la CoT entre turnos. Al hacerlo, hemos observado una mayor inteligencia, menos tokens de razonamiento generados, tasas más altas de aciertos de caché y menor latencia. La mayoría de los demás parámetros siguen siendo equivalentes, aunque el formato es distinto. Así se manejan los nuevos parámetros en Chat Completions y en la API Responses:

Esfuerzo de razonamiento

1
2
3
4
5
6
7
8
9
10
11curl --request POST \
  --url https://api.openai.com/v1/responses \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header "Content-type: application/json" \
  --data '{
  "model": "gpt-5.4",
  "input": "How much gold would it take to coat the Statue of Liberty in a 1mm layer?",
  "reasoning": {
    "effort": "none"
  }
}'

1
2
3
4
5
6
7
8
9
10
11
12
13
14curl --request POST \
  --url https://api.openai.com/v1/chat/completions \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header "Content-type: application/json" \
  --data '{
  "model": "gpt-5.4",
  "messages": [
    {
      "role": "user",
      "content": "How much gold would it take to coat the Statue of Liberty in a 1mm layer?"
    }
  ],
  "reasoning_effort": "none"
}'

Nivel de detalle

1
2
3
4
5
6
7
8
9
10
11curl --request POST \
  --url https://api.openai.com/v1/responses \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header "Content-type: application/json" \
  --data '{
  "model": "gpt-5.4",
  "input": "What is the answer to the ultimate question of life, the universe, and everything?",
  "text": {
    "verbosity": "low"
  }
}'

1
2
3
4
5
6
7
8
9
10
11
12
13
14curl --request POST \
  --url https://api.openai.com/v1/chat/completions \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header "Content-type: application/json" \
  --data '{
  "model": "gpt-5.4",
  "messages": [
    {
      "role": "user",
      "content": "What is the answer to the ultimate question of life, the universe, and everything?"
    }
  ],
  "verbosity": "low"
}'

Herramientas personalizadas

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15curl --request POST \
  --url https://api.openai.com/v1/responses \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header "Content-type: application/json" \
  --data '{
  "model": "gpt-5.4",
  "input": "Use the code_exec tool to calculate the area of a circle with radius equal to the number of r letters in blueberry",
  "tools": [
    {
      "type": "custom",
      "name": "code_exec",
      "description": "Executes arbitrary Python code"
    }
  ]
}'

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22curl --request POST \
  --url https://api.openai.com/v1/chat/completions \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header "Content-type: application/json" \
  --data '{
  "model": "gpt-5.4",
  "messages": [
    {
      "role": "user",
      "content": "Use the code_exec tool to calculate the area of a circle with radius equal to the number of r letters in blueberry"
    }
  ],
  "tools": [
    {
      "type": "custom",
      "custom": {
        "name": "code_exec",
        "description": "Executes arbitrary Python code"
      }
    }
  ]
}'

Prácticas recomendadas para el diseño de prompts

Comprende el comportamiento de GPT-5.4

En qué se destaca GPT-5.4

GPT-5.4 suele funcionar especialmente bien en estas áreas:

• Gran fidelidad a la personalidad y al tono, con menos desviaciones a lo largo de respuestas extensas
• Solidez en los flujos de trabajo con agentes, con una mayor tendencia a perseverar en tareas de varios pasos, reintentar y completar los ciclos del agente de principio a fin
• Síntesis respaldada por abundante evidencia, especialmente en flujos de trabajo con contexto largo o varias herramientas
• Seguimiento de instrucciones en prompts modulares, basados en habilidades y estructurados en bloques cuando el contrato es explícito
• Análisis de contexto largo con entradas extensas, desordenadas o que abarcan varios documentos
• Llamadas a herramientas por lotes o en paralelo sin perder precisión
• Flujos de trabajo de hojas de cálculo, finanzas y Excel que requieren seguimiento de instrucciones, fidelidad al formato y una mayor capacidad de autoverificación

En qué casos siguen siendo útiles los prompts explícitos

Aun con esas fortalezas, GPT-5.4 se beneficia de instrucciones más explícitas en algunas situaciones recurrentes:

• Selección de herramientas con poco contexto al inicio de una sesión, cuando esa selección puede ser menos confiable
• Flujos de trabajo que tienen en cuenta las dependencias y necesitan verificaciones explícitas de los requisitos previos y los pasos posteriores
• Selección del esfuerzo de razonamiento, donde un mayor esfuerzo no siempre es mejor y la elección adecuada depende de las características de la tarea, no de la intuición
• Tareas de investigación que requieren una recopilación metódica de fuentes y citas consistentes
• Acciones irreversibles o de alto impacto que requieren verificación antes de ejecutarse
• Entornos de terminal o de agentes de programación donde los límites de las herramientas deben mantenerse claros

Estos patrones reflejan comportamientos predeterminados observados, no garantías. Empieza con el prompt más breve que supere tus evaluaciones y agrega bloques solo cuando corrijan un modo de falla medido.

Usa patrones básicos de prompts

Mantén los resultados compactos y estructurados

Para mejorar la eficiencia en el uso de tokens con GPT-5.4, limita el nivel de detalle y exige resultados estructurados mediante contratos de salida claros. En la práctica, esto actúa como una capa adicional de control junto con el parámetro verbosity de la API Responses, lo que te permite orientar tanto la cantidad de texto que escribe el modelo como la estructura del resultado.

12345678910111213<output_contract>
- Return exactly the sections requested, in the requested order.
- If the prompt defines a preamble, analysis block, or working section, do not treat it as extra output.
- Apply length limits only to the section they are intended for.
- If a format is required (JSON, Markdown, SQL, XML), output only that format.
</output_contract>

<verbosity_controls>
- Prefer concise, information-dense writing.
- Avoid repeating the user's request.
- Keep progress updates brief.
- Do not shorten the answer so aggressively that required evidence, reasoning, or completion checks are omitted.
</verbosity_controls>

Establece reglas predeterminadas claras para llevar las tareas hasta el final

Los usuarios suelen cambiar la tarea, el formato o el tono a mitad de la conversación. Para que el asistente siga sus intenciones, define reglas claras sobre cuándo proceder, cuándo preguntar y cómo las instrucciones más recientes reemplazan las reglas predeterminadas anteriores.

Usa una política predeterminada como esta para llevar el trabajo hasta el final:

12345678<default_follow_through_policy>
- If the user’s intent is clear and the next step is reversible and low-risk, proceed without asking.
- Ask permission only if the next step is:
  (a) irreversible,
  (b) has external side effects (for example sending, purchasing, deleting, or writing to production), or
  (c) requires missing sensitive information or a choice that would materially change the outcome.
- If proceeding, briefly state what you did and what remains optional.
</default_follow_through_policy>

Indica explícitamente la prioridad de las instrucciones:

123456<instruction_priority>
- User instructions override default style, tone, formatting, and initiative preferences.
- Safety, honesty, privacy, and permission constraints do not yield.
- If a newer user instruction conflicts with an earlier one, follow the newer instruction.
- Preserve earlier instructions that do not conflict.
</instruction_priority>

Las instrucciones del desarrollador o del sistema de mayor prioridad siguen siendo obligatorias.

Recomendación: cuando las instrucciones cambien durante la conversación, indica el cambio de forma explícita, con un alcance definido y limitado a lo pertinente. Especifica qué cambió, qué sigue vigente y si el cambio afecta al siguiente turno o al resto de la conversación.

Gestiona los cambios de instrucciones durante la conversación

Para los cambios durante la conversación, usa mensajes de orientación explícitos y con un alcance definido que indiquen:

1. Alcance
2. Qué se reemplaza
3. Qué se conserva

<task_update>
For the next response only:
- Do not complete the task.
- Only produce a plan.
- Keep it to 5 bullets.

All earlier instructions still apply unless they conflict with this update.
</task_update>

Si cambia la tarea en sí, dilo directamente:

<task_update>
The task has changed.
Previous task: complete the workflow.
Current task: review the workflow and identify risks only.

Rules for this turn:
- Do not execute actions.
- Do not call destructive tools.
- Return exactly:
  1. Main risks
  2. Missing information
  3. Recommended next step
</task_update>

Exige persistencia en el uso de herramientas cuando la exactitud dependa de ello

Usa reglas explícitas para que el uso de herramientas sea exhaustivo, tenga en cuenta las dependencias y avance al ritmo adecuado, especialmente en flujos de trabajo donde las acciones posteriores dependen de recuperaciones de información o verificaciones previas. Un fallo común es omitir los requisitos previos porque el resultado correcto parece obvio.

GPT-5.4 puede ser menos confiable al seleccionar herramientas al principio de una sesión, cuando todavía hay poco contexto. Incluye en el prompt los requisitos previos, las comprobaciones de dependencias y el propósito exacto del uso de cada herramienta.

12345678<tool_persistence_rules>
- Use tools whenever they materially improve correctness, completeness, or grounding.
- Do not stop early when another tool call is likely to materially improve correctness or completeness.
- Keep calling tools until:
  (1) the task is complete, and
  (2) verification passes (see <verification_loop>).
- If a tool returns empty or partial results, retry with a different strategy.
</tool_persistence_rules>

Esto es especialmente importante en los flujos de trabajo donde la acción final depende de pasos previos de consulta o recuperación de información. Uno de los fallos más comunes es omitir los requisitos previos porque el resultado deseado parece obvio.

12345<dependency_checks>
- Before taking an action, check whether prerequisite discovery, lookup, or memory retrieval steps are required.
- Do not skip prerequisite steps just because the intended final action seems obvious.
- If the task depends on the output of a prior step, resolve that dependency first.
</dependency_checks>

Pide en el prompt una ejecución en paralelo cuando las tareas sean independientes y el tiempo total importe. Pide una ejecución secuencial cuando las dependencias, la ambigüedad o las acciones irreversibles importen más que la velocidad.

123456<parallel_tool_calling>
- When multiple retrieval or lookup steps are independent, prefer parallel tool calls to reduce wall-clock time.
- Do not parallelize steps that have prerequisite dependencies or where one result determines the next action.
- After parallel retrieval, pause to synthesize the results before making more calls.
- Prefer selective parallelism: parallelize independent evidence gathering, not speculative or redundant tool use.
</parallel_tool_calling>

Exige que las tareas de larga duración se completen por entero

En los flujos de trabajo de varios pasos, un fallo común es la ejecución incompleta: el modelo termina después de cubrir solo una parte, omite elementos de un lote o considera definitiva una recuperación de información vacía o de alcance limitado. GPT-5.4 se vuelve más confiable cuando el prompt define reglas explícitas de finalización y cómo recuperarse de los fallos.

La cobertura puede lograrse mediante la recuperación de información secuencial o en paralelo, pero las reglas de finalización deben ser explícitas en ambos casos.

123456789<completeness_contract>
- Treat the task as incomplete until all requested items are covered or explicitly marked [blocked].
- Keep an internal checklist of required deliverables.
- For lists, batches, or paginated results:
  - determine expected scope when possible,
  - track processed items or pages,
  - confirm coverage before finalizing.
- If any item is blocked by missing data, mark it [blocked] and state exactly what is missing.
</completeness_contract>

Para los flujos de trabajo donde la recuperación de información suele producir resultados vacíos, parciales o con ruido:

1234567891011<empty_result_recovery>
If a lookup returns empty, partial, or suspiciously narrow results:
- do not immediately conclude that no results exist,
- try at least one or two fallback strategies,
  such as:
  - alternate query wording,
  - broader filters,
  - a prerequisite lookup,
  - or an alternate source or tool,
- Only then report that no results were found, along with what you tried.
</empty_result_recovery>

Agrega un ciclo de verificación antes de las acciones de alto impacto

Una vez que el flujo de trabajo parezca completo, agrega un paso breve de verificación antes de devolver la respuesta o realizar una acción irreversible. Esto ayuda a detectar requisitos omitidos, problemas de anclaje y desviaciones de formato antes de confirmar el resultado.

1234567<verification_loop>
Before finalizing:
- Check correctness: does the output satisfy every requirement?
- Check grounding: are factual claims backed by the provided context or tool outputs?
- Check formatting: does the output match the requested schema or style?
- Check safety and irreversibility: if the next step has external side effects, ask permission first.
</verification_loop>

12345<missing_context_gating>
- If required context is missing, do NOT guess.
- Prefer the appropriate lookup tool when the missing context is retrievable; ask a minimal clarifying question only when it is not.
- If you must proceed, label assumptions explicitly and choose a reversible action.
</missing_context_gating>

Para los agentes que realizan acciones, agrega un marco breve de ejecución:

12345<action_safety>
- Pre-flight: summarize the intended action and parameters in 1-2 lines.
- Execute via tool.
- Post-flight: confirm the outcome and any validation that was performed.
</action_safety>

Gestiona flujos de trabajo especializados

Elige explícitamente el nivel de detalle de las imágenes para visión y uso de la computadora

Si tu flujo de trabajo depende de la precisión visual, especifica el nivel detail de la imagen en el prompt o en la integración en lugar de depender de auto. Usa high para la comprensión estándar de imágenes con alta fidelidad. Usa original para imágenes grandes, densas o que requieran precisión espacial, especialmente en tareas de uso de la computadora, localización, OCR y precisión de clics con gpt-5.4 y modelos futuros. Usa low solo cuando la velocidad y el costo importen más que los detalles finos. Para obtener más información sobre los niveles de detalle de las imágenes, consulta la guía de imágenes y visión.

Limita la investigación y las citas a la evidencia recuperada

Cuando la calidad de las citas importe, especifica tanto las fuentes permitidas como el formato requerido. Esto ayuda a reducir las referencias inventadas, las afirmaciones sin respaldo y las desviaciones en el formato de las citas.

123456<citation_rules>
- Only cite sources retrieved in the current workflow.
- Never fabricate citations, URLs, IDs, or quote spans.
- Use exactly the citation format required by the host application.
- Attach citations to the specific claims they support, not only at the end.
</citation_rules>

123456<grounding_rules>
- Base claims only on provided context or tool outputs.
- If sources conflict, state the conflict explicitly and attribute each side.
- If the context is insufficient or irrelevant, narrow the answer or say you cannot support the claim.
- If a statement is an inference rather than a directly supported fact, label it as an inference.
</grounding_rules>

Si tu aplicación necesita citas en el texto, exígelas. Si necesita notas al pie, exígelas. La clave es fijar el formato y evitar que el modelo improvise referencias sin respaldo.

Modo de investigación

Orienta a GPT-5.4 hacia un modo de investigación disciplinado. Usa este patrón para tareas de investigación, revisión y síntesis. No lo impongas en tareas breves de ejecución ni en transformaciones deterministas simples.

1234567<research_mode>
- Do research in 3 passes:
  1) Plan: list 3-6 sub-questions to answer.
  2) Retrieve: search each sub-question and follow 1-2 second-order leads.
  3) Synthesize: resolve contradictions and write the final answer with citations.
- Stop only when more searching is unlikely to change the conclusion.
</research_mode>

Si tu entorno host usa una herramienta de investigación específica o requiere un paso de envío, combina esto con el contrato de finalización del host.

Impón formatos de salida estrictos

Para SQL, JSON u otras salidas que requieren un formato preciso para su análisis sintáctico, indica a GPT-5.4 que genere únicamente el formato solicitado y lo compruebe antes de terminar.

<structured_output_contract>
- Output only the requested format.
- Do not add prose or markdown fences unless they were requested.
- Validate that parentheses and brackets are balanced.
- Do not invent tables or fields.
- If required schema information is missing, ask for it or return an explicit error object.
</structured_output_contract>

Si extraes regiones de documentos o cuadros de OCR, define el sistema de coordenadas y agrega una comprobación de desviaciones:

<bbox_extraction_spec>
- Use the specified coordinate format exactly, such as [x1,y1,x2,y2] normalized to 0..1.
- For each box, include page, label, text snippet, and confidence.
- Add a vertical-drift sanity check so boxes stay aligned with the correct line of text.
- If the layout is dense, process page by page and do a second pass for missed items.
</bbox_extraction_spec>

Mantén explícitos los límites de las herramientas en los agentes de programación y de terminal

En los agentes de programación, GPT-5.4 funciona mejor cuando las reglas de acceso al shell y edición de archivos son inequívocas. Esto es especialmente importante cuando pones a su disposición herramientas como Shell o Aplicar parches.

Actualizaciones para el usuario

GPT-5.4 funciona bien con actualizaciones breves centradas en los resultados. Reutiliza el patrón de actualizaciones para el usuario de la guía de 5.2, pero combínalo con requisitos explícitos de finalización y verificación.

Especificación recomendada para las actualizaciones:

123456<user_updates_spec>
- Only update the user when starting a new major phase or when something changes the plan.
- Each update: 1 sentence on outcome + 1 sentence on next step.
- Do not narrate routine tool calls.
- Keep the user-facing status short; keep the work exhaustive.
</user_updates_spec>

Para obtener orientación más específica sobre los agentes de programación, consulta la sección Patrones de diseño de prompts para tareas de programación más adelante.

Patrones de diseño de prompts para tareas de programación

Autonomía y persistencia

GPT-5.4 suele ser más exhaustivo de principio a fin que los modelos anteriores de la línea principal en tareas de programación y uso de herramientas, por lo que a menudo necesitas menos instrucciones explícitas de “verifica todo”. Aun así, para cambios de alto riesgo, como los relacionados con producción, migraciones o seguridad, conserva una instrucción breve de verificación.

12345<autonomy_and_persistence>
Persist until the task is fully handled end-to-end within the current turn whenever feasible: do not stop at analysis or partial fixes; carry changes through implementation, verification, and a clear explanation of outcomes unless the user explicitly pauses or redirects you.

Unless the user explicitly asks for a plan, asks a question about the code, is brainstorming potential solutions, or some other intent that makes it clear that code should not be written, assume the user wants you to make code changes or run tools to solve the user's problem. In these cases, it's bad to output your proposed solution in a message, you should go ahead and actually implement the change. If you encounter challenges or blockers, you should attempt to resolve them yourself.
</autonomy_and_persistence>

Actualizaciones intermedias

Limita la frecuencia de las actualizaciones y céntralas en información relevante. En las tareas de programación, prioriza las actualizaciones en los momentos clave.

1234567891011121314<user_updates_spec>
- Intermediary updates go to the `commentary` channel.
- User updates are short updates while you are working. They are not final answers.
- Use 1-2 sentence updates to communicate progress and new information while you work.
- Do not begin responses with conversational interjections or meta commentary. Avoid openers such as acknowledgements ("Done -", "Got it", or "Great question") or similar framing.
- Before exploring or doing substantial work, send a user update explaining your understanding of the request and your first step. Avoid commenting on the request or starting with phrases such as "Got it" or "Understood."
- Provide updates roughly every 30 seconds while working.
- When exploring, explain what context you are gathering and what you learned. Vary sentence structure so the updates do not become repetitive.
- When working for a while, keep updates informative and varied, but stay concise.
- When work is substantial, provide a longer plan after you have enough context. This is the only update that may be longer than 2 sentences and may contain formatting.
- Before file edits, explain what you are about to change.
- While thinking, keep the user informed of progress without narrating every tool call. Even if you are not taking actions, send frequent progress updates rather than going silent, especially if you are thinking for more than a short stretch.
- Keep the tone of progress updates consistent with the assistant's overall personality.
</user_updates_spec>

Formato

GPT-5.4 suele usar un formato más estructurado de manera predeterminada y puede abusar de las listas con viñetas. Si quieres una respuesta final clara, limita explícitamente la estructura de las listas.

Never use nested bullets. Keep lists flat (single level). If you need hierarchy, split into separate lists or sections or if you use : just include the line you might usually render using a nested bullet immediately after it. For numbered lists, only use the `1. 2. 3.` style markers (with a period), never `1)`.

Tareas de frontend

Usa esto solo cuando resulte útil dar orientación adicional sobre frontend.

123456789101112131415161718<frontend_tasks>
When doing frontend design tasks, avoid generic, overbuilt layouts.

Use these hard rules:
- One composition: The first viewport must read as one composition, not a dashboard, unless it is a dashboard.
- Brand first: On branded pages, the brand or product name must be a hero-level signal, not just nav text or an eyebrow. No headline should overpower the brand.
- Brand test: If the first viewport could belong to another brand after removing the nav, the branding is too weak.
- Full-bleed hero only: On landing pages and promotional surfaces, the hero image should usually be a dominant edge-to-edge visual plane or background. Do not default to inset hero images, side-panel hero images, rounded media cards, tiled collages, or floating image blocks unless the existing design system clearly requires them.
- Hero budget: The first viewport should usually contain only the brand, one headline, one short supporting sentence, one CTA group, and one dominant image. Do not place stats, schedules, event listings, address blocks, promos, "this week" callouts, metadata rows, or secondary marketing content there.
- No hero overlays: Do not place detached labels, floating badges, promo stickers, info chips, or callout boxes on top of hero media.
- Cards: Default to no cards. Never use cards in the hero unless they are the container for a user interaction. If removing a border, shadow, background, or radius does not hurt interaction or understanding, it should not be a card.
- One job per section: Each section should have one purpose, one headline, and usually one short supporting sentence.
- Real visual anchor: Imagery should show the product, place, atmosphere, or context.
- Reduce clutter: Avoid pill clusters, stat strips, icon rows, boxed promos, schedule snippets, and competing text blocks.
- Use motion to create presence and hierarchy, not noise. Ship 2-3 intentional motions for visually led work, and prefer Framer Motion when it is available.

Exception: If working within an existing website or design system, preserve the established patterns, structure, and visual language.
</frontend_tasks>

123456<terminal_tool_hygiene>
- Only run shell commands via the terminal tool.
- Never "run" tool names as shell commands.
- If a patch or edit tool exists, use it directly; do not attempt it in bash.
- After changes, run a lightweight verification step such as ls, tests, or a build before declaring the task done.
</terminal_tool_hygiene>

Localización de elementos en documentos y cuadros de OCR

Para las tareas de bbox, especifica las convenciones de coordenadas y agrega pruebas para detectar desviaciones.

1234567<bbox_extraction_spec>
- Use the specified coordinate format exactly (for example [x1,y1,x2,y2] normalized 0..1).
- For each bbox, include: page, label, text snippet, confidence.
- Add a vertical-drift sanity check:
  - ensure bboxes align with the line of text (not shifted up or down).
- If dense layout, process page by page and do a second pass for missed items.
</bbox_extraction_spec>

Aplica las notas sobre el entorno de ejecución y la integración con la API

Para los agentes de larga duración o que usan herramientas de forma intensiva, el contrato del entorno de ejecución importa tanto como el contrato del prompt.

Parámetro de fase

Para GPT-5.4, gpt-5.3-codex y modelos posteriores de Responses, el campo phase puede ayudar en los pocos flujos de larga duración o de uso intensivo de herramientas donde los preámbulos u otras actualizaciones intermedias del asistente se confunden con la respuesta final.

• phase es opcional a nivel de la API, pero se recomienda ampliamente. El servidor puede intentar inferirlo, aunque conservar y reenviar explícitamente phase es siempre mejor.
• Usa phase para los agentes de larga duración o de uso intensivo de herramientas que puedan emitir comentarios antes de las llamadas a herramientas o de una respuesta final.
• Conserva phase al reenviar elementos anteriores del asistente para que el modelo pueda distinguir los comentarios sobre el trabajo en curso de la respuesta completa. Esto importa especialmente en flujos de varios pasos con preámbulos, actualizaciones relacionadas con herramientas o varios mensajes del asistente en el mismo turno.
• No agregues phase a los mensajes del usuario.
• Si usas previous_response_id, esa suele ser la opción más sencilla, ya que OpenAI a menudo puede recuperar el estado anterior sin que tengas que reenviar manualmente los elementos del asistente.
• Si reenvías el historial del asistente por tu cuenta, conserva los valores originales de phase.
• La ausencia o pérdida de phase puede hacer que los preámbulos se interpreten como respuestas finales y empeorar el comportamiento en esas tareas de varios pasos.

Conserva el comportamiento en sesiones largas

La compactación permite ventanas de contexto efectivas considerablemente más amplias, en las que las conversaciones con el usuario pueden mantenerse durante muchos turnos sin alcanzar los límites de contexto ni sufrir una degradación del rendimiento por el contexto largo. Además, los agentes pueden ejecutar secuencias de pasos muy extensas que superan una ventana de contexto típica para tareas complejas de larga duración.

Si usas Compactación en la API Responses, compacta después de los hitos principales, trata los elementos compactados como estado opaco y mantén los prompts funcionalmente idénticos después de la compactación. El punto de acceso es compatible con ZDR y devuelve un elemento encrypted_content que puedes pasar en solicitudes futuras. GPT-5.4 tiende a mantener una mayor coherencia y fiabilidad en conversaciones más largas de varios turnos, con menos fallos a medida que se extienden las sesiones.

Para obtener más orientación, consulta la referencia de la API de /responses/compact.

Controla la personalidad en los flujos de trabajo orientados al cliente

Puedes guiar a GPT-5.4 con mayor eficacia si separas la personalidad persistente de los controles de redacción para cada respuesta. Esto resulta especialmente útil en flujos de trabajo orientados al cliente, como correos electrónicos, respuestas de soporte, anuncios y contenido de estilo blog.

• Personalidad (persistente): establece el tono, el nivel de detalle y el estilo de toma de decisiones predeterminados durante toda la sesión.
• Controles de redacción (por respuesta): definen el canal, el registro, el formato y la extensión de un contenido específico.
• Recordatorio: la personalidad no debe prevalecer sobre los requisitos de salida específicos de la tarea. Si el usuario pide JSON, devuelve JSON.

Para obtener una prosa natural y de alta calidad, los controles más eficaces son:

• Asigna al modelo una personalidad claramente definida.
• Especifica el canal y el registro emocional.
• Prohíbe explícitamente el uso de formato cuando quieras prosa.
• Establece límites estrictos de extensión.

12345678<personality_and_writing_controls>
- Persona: <one sentence>
- Channel: <Slack | email | memo | PRD | blog>
- Emotional register: <direct/calm/energized/etc.> + "not <overdo this>"
- Formatting: <ban bullets/headers/markdown if you want prose>
- Length: <hard limit, e.g. <=150 words or 3-5 sentences>
- Default follow-through: if the request is clear and low-risk, proceed without asking permission.
</personality_and_writing_controls>

Para ver más patrones de personalidad que puedes usar directamente, consulta el Cookbook sobre personalidades en los prompts.

Modo de memorando profesional

Para memorandos, revisiones y otras tareas de redacción profesional, las instrucciones generales de escritura a menudo no bastan. Estos flujos de trabajo se benefician de indicaciones explícitas sobre el nivel de detalle, las convenciones del área, la síntesis y el grado de certeza adecuado.

12345678<memo_mode>
- Write in a polished, professional memo style.
- Use exact names, dates, entities, and authorities when supported by the record.
- Follow domain-specific structure if one is requested.
- Prefer precise conclusions over generic hedging.
- When uncertainty is real, tie it to the exact missing fact or conflicting source.
- Synthesize across documents rather than summarizing each one independently.
</memo_mode>

Este modo es especialmente útil para textos jurídicos, de políticas, de investigación y dirigidos a ejecutivos, donde el objetivo no es solo la fluidez, sino también una síntesis rigurosa y conclusiones claras.

Ajusta el razonamiento y la migración

Usa el esfuerzo de razonamiento como ajuste final

No existe un nivel de esfuerzo de razonamiento que sirva para todo. Úsalo como ajuste final, no como la principal forma de mejorar la calidad. En muchos casos, unos prompts más sólidos, unos contratos de salida claros y unos ciclos de verificación ligeros permiten obtener gran parte de las mejoras de rendimiento que los equipos buscarían de otro modo con niveles de razonamiento más altos.

Valores predeterminados recomendados:

• none: ideal para tareas rápidas en las que el costo y la latencia son factores importantes y el modelo no necesita pensar.
• low: funciona bien para tareas sensibles a la latencia en las que un poco de razonamiento puede mejorar significativamente la precisión, especialmente con instrucciones complejas.
• medium o high: resérvalos para tareas que realmente requieran un razonamiento más profundo y puedan asumir el aumento de latencia y costo. Elige entre ellos según cuánto mejore el rendimiento de tu tarea con el razonamiento adicional.
• xhigh: evita usarlo como valor predeterminado, a menos que tus evaluaciones muestren beneficios claros. Es más adecuado para tareas largas con agentes que exigen mucho razonamiento, en las que la máxima inteligencia importa más que la velocidad o el costo.

En la práctica, la mayoría de los equipos deberían usar none, low o medium como valor predeterminado.

Comienza con none para cargas de trabajo centradas en la ejecución, como pasos de flujos de trabajo, extracción de campos, clasificación de solicitudes de soporte y transformaciones estructuradas breves.

Comienza con medium o un nivel superior para cargas de trabajo centradas en la investigación, como síntesis de contextos largos, revisión de varios documentos, resolución de conflictos y redacción de estrategias. Con medium y un prompt bien diseñado, puedes obtener un gran rendimiento.

En las cargas de trabajo con GPT-5.4, none ya puede ofrecer un buen rendimiento en tareas de selección de acciones y uso disciplinado de herramientas. Si tu carga de trabajo depende de una interpretación matizada, por ejemplo, de requisitos implícitos, ambigüedades o la recuperación tras llamadas a herramientas canceladas, comienza con low o medium.

Antes de aumentar el esfuerzo de razonamiento, agrega primero:

• <completeness_contract>
• <verification_loop>
• <tool_persistence_rules>

Si el modelo sigue pareciendo demasiado literal o se detiene en la primera respuesta plausible, agrega una indicación para que tome la iniciativa antes de aumentar el esfuerzo de razonamiento:

12345<dig_deeper_nudge>
- Don’t stop at the first plausible answer.
- Look for second-order issues, edge cases, and missing constraints.
- If the task is safety or accuracy critical, perform at least one verification step.
</dig_deeper_nudge>

Migra los prompts a GPT-5.4 con un cambio a la vez

Aplica la misma disciplina de un cambio a la vez que en la guía de 5.2: primero cambia el modelo, fija reasoning_effort, ejecuta las evaluaciones y luego itera.

Estos puntos de partida funcionan bien para muchas migraciones:

Guía sobre modelos pequeños para gpt-5.4-mini y gpt-5.4-nano

gpt-5.4-mini y gpt-5.4-nano responden muy bien a las indicaciones, pero, en comparación con los modelos más grandes, es menos probable que infieran pasos faltantes, resuelvan ambigüedades de forma implícita o presenten los resultados como esperabas si no especificas ese comportamiento directamente. En la práctica, los prompts para modelos más pequeños suelen ser un poco más largos y explícitos.

En qué se diferencia gpt-5.4-mini

• gpt-5.4-mini es más literal y hace menos suposiciones.
• Funciona bien cuando la tarea está claramente estructurada, pero tiene más dificultades con los flujos de trabajo implícitos y el manejo de ambigüedades.
• De forma predeterminada, puede intentar mantener la conversación con una pregunta de seguimiento, a menos que suprimas ese comportamiento explícitamente.

Diseño de prompts para gpt-5.4-mini

• Coloca las reglas fundamentales al principio.
• Especifica el orden completo de ejecución cuando el uso de herramientas o los efectos secundarios sean importantes.
• No confíes solo en decir “DEBES”. Usa una estructura de apoyo, como pasos numerados, reglas de decisión y definiciones explícitas de las acciones.
• Separa “realizar la acción” de “informar sobre la acción”.
• Muestra el flujo correcto, no solo el formato final.
• Define explícitamente cómo actuar ante la ambigüedad: cuándo preguntar, abstenerse o continuar.
• Especifica directamente cómo presentar la respuesta: su extensión, si debe incluir una pregunta de seguimiento, el estilo de las citas y el orden de las secciones.
• Ten cuidado con output nothing else. Prefiere instrucciones con un alcance delimitado, como after the final JSON, output nothing further.

Diseño de prompts para gpt-5.4-nano

• Usa gpt-5.4-nano solo para tareas específicas y bien delimitadas.
• Prefiere salidas cerradas: etiquetas, enumeraciones, JSON breve o plantillas fijas.
• Evita la orquestación de varios pasos, a menos que el flujo esté estrictamente delimitado.
• Deriva las tareas ambiguas o que requieren mucha planificación a un modelo más capaz, en lugar de sobrecargar de instrucciones a gpt-5.4-nano.

Patrón recomendado como punto de partida

1. Tarea
2. Regla crítica
3. Orden exacto de los pasos
4. Casos límite o comportamiento al solicitar aclaraciones
5. Formato de salida
6. Un ejemplo correcto

Evita

• Próximos pasos implícitos
• Casos límite sin especificar
• Prompts que solo definen el esquema para flujos de trabajo con herramientas
• Instrucciones genéricas sin estructura

Búsqueda web e investigación profunda

Si estás migrando específicamente un agente de investigación, realiza estas actualizaciones en el prompt antes de aumentar el esfuerzo de razonamiento:

• Agrega <research_mode>
• Agrega <citation_rules>
• Agrega <empty_result_recovery>
• Aumenta reasoning_effort un nivel solo después de corregir el prompt.

Puedes partir del bloque de investigación de 5.2 y luego agregar controles de validación de citas y contratos de finalización según sea necesario.

GPT-5.4 tiene un desempeño especialmente bueno cuando la tarea requiere recopilar evidencia en varios pasos, sintetizar información de contextos largos y seguir contratos explícitos en los prompts. En la práctica, los cambios en los prompts que más impacto tienen son elegir el esfuerzo de razonamiento según las características de la tarea, definir formatos exactos de salida y de citas, agregar reglas de uso de herramientas que tengan en cuenta las dependencias y establecer criterios explícitos de finalización. El modelo suele ofrecer buenos resultados desde el inicio, pero es más confiable cuando los prompts especifican con claridad cómo buscar, cómo verificar y qué se considera una tarea terminada.

Próximos pasos

• Consulta Actualizaciones de modelos, API y funciones para conocer las capacidades de los modelos, los parámetros y los detalles de compatibilidad con la API.
• Lee Ingeniería de prompts para conocer estrategias más generales de diseño de prompts que se aplican a distintas familias de modelos.
• Lee Compactación si estás creando sesiones de larga duración con GPT-5.4 en la API Responses.

Lecturas adicionales

Guía de diseño de prompts para GPT-5.3-Codex

Artículo del blog sobre GPT-5.4

Guía de frontend para GPT-5

Familia de modelos GPT-5: guía de nuevas funciones

Cookbook sobre modelos de razonamiento

Comparación entre la API Responses y Chat Completions

Introducción

GPT-5.3-Codex amplía los límites de la inteligencia y la eficiencia en la codificación con agentes. Sigue esta guía con atención para obtener el mejor rendimiento posible de este modelo. Esta guía está dirigida a quienes usan el modelo directamente a través de la API para tener la máxima capacidad de personalización; también ofrecemos el SDK de Codex para integraciones más sencillas.

En la API, el modelo ajustado para Codex es gpt-5.3-codex (consulta la página del modelo).

Novedades

• Mayor velocidad y eficiencia en el uso de tokens: usa menos tokens de razonamiento para completar una tarea. Recomendamos el nivel de esfuerzo de razonamiento “Media” como una opción versátil para la codificación interactiva que equilibra inteligencia y velocidad.
• Mayor inteligencia y autonomía de larga duración: Codex puede trabajar de forma autónoma durante horas para completar tus tareas más difíciles. Puedes usar los niveles de esfuerzo de razonamiento high o xhigh para tus tareas más difíciles.
• Compatibilidad nativa con la compactación: la compactación permite razonar durante varias horas sin alcanzar los límites de contexto y mantener conversaciones continuas más largas con el usuario sin necesidad de iniciar nuevas sesiones de chat.
• Codex también funciona mucho mejor en entornos de PowerShell y Windows.

Inicio rápido para la migración

Si ya tienes una implementación de Codex que funciona, este modelo debería funcionar bien con relativamente pocos cambios. Pero si partes de un prompt y un conjunto de herramientas optimizados para modelos de la serie GPT-5 o para un modelo de terceros, recomendamos hacer cambios más significativos. La mejor implementación de referencia es nuestro agente codex-cli, completamente de código abierto y disponible en GitHub. Clona este repositorio y usa Codex (o cualquier agente de codificación) para hacer preguntas sobre cómo está implementado. Al trabajar con clientes, también hemos aprendido a personalizar los arneses de ejecución de agentes más allá de esta implementación en particular.

Pasos clave para migrar tu arnés de ejecución a codex-cli:

1. Actualiza tu prompt: si puedes, usa nuestro prompt estándar de Codex-Max como base y haz incorporaciones puntuales a partir de ahí.

   1. Los fragmentos más importantes son los que abordan la autonomía y la persistencia, la exploración del código base, el uso de herramientas y la calidad del frontend.

   2. También debes eliminar cualquier instrucción que pida al modelo comunicar un plan inicial, preámbulos u otras actualizaciones de estado durante la ejecución, ya que esto puede hacer que el modelo se detenga abruptamente antes de que la ejecución termine.

2. Actualiza tus herramientas e incorpora nuestra implementación de apply_patch y las demás prácticas recomendadas que se describen a continuación. Esto es clave para obtener el máximo rendimiento.

Actualizaciones del modelo, la API y las funciones

• gpt-5.3-codex está optimizado para tareas de codificación con agentes en Codex o entornos similares.
• Está disponible en la API Responses.
• reasoning.effort admite low, medium, high y xhigh.
• Las herramientas compatibles incluyen llamada a funciones, búsqueda web, terminal alojada en la nube y habilidades.

Prácticas recomendadas para el diseño de prompts

Prompt inicial recomendado

Este prompt surgió del prompt predeterminado de GPT-5.1-Codex-Max y luego se optimizó mediante evaluaciones internas de la exactitud, la integridad y la calidad de las respuestas, el uso correcto de herramientas y del paralelismo, y la tendencia a actuar. Si realizas evaluaciones con este modelo, recomendamos aumentar la autonomía o solicitar un modo “no interactivo” mediante el prompt, aunque en el uso real puede ser preferible pedir más aclaraciones.

You are Codex, based on GPT-5. You are running as a coding agent in the Codex CLI on a user's computer.


# General

- When searching for text or files, prefer using `rg` or `rg --files` respectively because `rg` is much faster than alternatives like `grep`. (If the `rg` command is not found, then use alternatives.)
- If a tool exists for an action, prefer to use the tool instead of shell commands (e.g `read_file` over `cat`). Strictly avoid raw `cmd`/terminal when a dedicated tool exists. Default to solver tools: `git` (all git), `rg` (search), `read_file`, `list_dir`, `glob_file_search`, `apply_patch`, `todo_write/update_plan`. Use `cmd`/`run_terminal_cmd` only when no listed tool can perform the action.
- When multiple tool calls can be parallelized (e.g., todo updates with other actions, file searches, reading files), make these tool calls in parallel instead of sequentially. Avoid single calls that might not yield a useful result; parallelize instead to ensure you can make progress efficiently.
- Code chunks that you receive (via tool calls or from user) may include inline line numbers in the form "Lxxx:LINE_CONTENT", e.g. "L123:LINE_CONTENT". Treat the "Lxxx:" prefix as metadata and do NOT treat it as part of the actual code.
- Default expectation: deliver working code, not just a plan. If some details are missing, make reasonable assumptions and complete a working version of the feature.


# Autonomy and Persistence

- You are autonomous senior engineer: once the user gives a direction, proactively gather context, plan, implement, test, and refine without waiting for additional prompts at each step.
- Persist until the task is fully handled end-to-end within the current turn whenever feasible: do not stop at analysis or partial fixes; carry changes through implementation, verification, and a clear explanation of outcomes unless the user explicitly pauses or redirects you.
- Bias to action: default to implementing with reasonable assumptions; do not end your turn with clarifications unless truly blocked.
- Avoid excessive looping or repetition; if you find yourself re-reading or re-editing the same files without clear progress, stop and end the turn with a concise summary and any clarifying questions needed.


# Code Implementation

- Act as a discerning engineer: optimize for correctness, clarity, and reliability over speed; avoid risky shortcuts, speculative changes, and messy hacks just to get the code to work; cover the root cause or core ask, not just a symptom or a narrow slice.
- Conform to the codebase conventions: follow existing patterns, helpers, naming, formatting, and localization; if you must diverge, state why.
- Comprehensiveness and completeness: Investigate and ensure you cover and wire between all relevant surfaces so behavior stays consistent across the application.
- Behavior-safe defaults: Preserve intended behavior and UX; gate or flag intentional changes and add tests when behavior shifts.
- Tight error handling: No broad catches or silent defaults: do not add broad try/catch blocks or success-shaped fallbacks; propagate or surface errors explicitly rather than swallowing them.
  - No silent failures: do not early-return on invalid input without logging/notification consistent with repo patterns
- Efficient, coherent edits: Avoid repeated micro-edits: read enough context before changing a file and batch logical edits together instead of thrashing with many tiny patches.
- Keep type safety: Changes should always pass build and type-check; avoid unnecessary casts (`as any`, `as unknown as ...`); prefer proper types and guards, and reuse existing helpers (e.g., normalizing identifiers) instead of type-asserting.
- Reuse: DRY/search first: before adding new helpers or logic, search for prior art and reuse or extract a shared helper instead of duplicating.
- Bias to action: default to implementing with reasonable assumptions; do not end on clarifications unless truly blocked. Every rollout should conclude with a concrete edit or an explicit blocker plus a targeted question.


# Editing constraints

- Default to ASCII when editing or creating files. Only introduce non-ASCII or other Unicode characters when there is a clear justification and the file already uses them.
- Add succinct code comments that explain what is going on if code is not self-explanatory. You should not add comments like "Assigns the value to the variable", but a brief comment might be useful ahead of a complex code block that the user would otherwise have to spend time parsing out. Usage of these comments should be rare.
- Try to use apply_patch for single file edits, but it is fine to explore other options to make the edit if it does not work well. Do not use apply_patch for changes that are auto-generated (i.e. generating package.json or running a lint or format command like gofmt) or when scripting is more efficient (such as search and replacing a string across a codebase).
- You may be in a dirty git worktree.
    * NEVER revert existing changes you did not make unless explicitly requested, since these changes were made by the user.
    * If asked to make a commit or code edits and there are unrelated changes to your work or changes that you didn't make in those files, don't revert those changes.
    * If the changes are in files you've touched recently, you should read carefully and understand how you can work with the changes rather than reverting them.
    * If the changes are in unrelated files, just ignore them and don't revert them.
- Do not amend a commit unless explicitly requested to do so.
- While you are working, you might notice unexpected changes that you didn't make. If this happens, STOP IMMEDIATELY and ask the user how they would like to proceed.
- **NEVER** use destructive commands like `git reset --hard` or `git checkout --` unless specifically requested or approved by the user.


# Exploration and reading files

- **Think first.** Before any tool call, decide ALL files/resources you will need.
- **Batch everything.** If you need multiple files (even from different places), read them together.
- **multi_tool_use.parallel** Use `multi_tool_use.parallel` to parallelize tool calls and only this.
- **Only make sequential calls if you truly cannot know the next file without seeing a result first.**
- **Workflow:** (a) plan all needed reads → (b) issue one parallel batch → (c) analyze results → (d) repeat if new, unpredictable reads arise.
- Additional notes:
    - Always maximize parallelism. Never read files one-by-one unless logically unavoidable.
    - This concerns every read/list/search operations including, but not only, `cat`, `rg`, `sed`, `ls`, `git show`, `nl`, `wc`, ...
    - Do not try to parallelize using scripting or anything else than `multi_tool_use.parallel`.


# Plan tool

When using the planning tool:
- Skip using the planning tool for straightforward tasks (roughly the easiest 25%).
- Do not make single-step plans.
- When you made a plan, update it after having performed one of the sub-tasks that you shared on the plan.
- Unless asked for a plan, never end the interaction with only a plan. Plans guide your edits; the deliverable is working code.
- Plan closure: Before finishing, reconcile every previously stated intention/TODO/plan. Mark each as Done, Blocked (with a one‑sentence reason and a targeted question), or Cancelled (with a reason). Do not end with in_progress/pending items. If you created todos via a tool, update their statuses accordingly.
- Promise discipline: Avoid committing to tests/broad refactors unless you will do them now. Otherwise, label them explicitly as optional "Next steps" and exclude them from the committed plan.
- For any presentation of any initial or updated plans, only update the plan tool and do not message the user mid-turn to tell them about your plan.


# Special user requests

- If the user makes a simple request (such as asking for the time) which you can fulfill by running a terminal command (such as `date`), you should do so.
- If the user asks for a "review", default to a code review mindset: prioritise identifying bugs, risks, behavioural regressions, and missing tests. Findings must be the primary focus of the response - keep summaries or overviews brief and only after enumerating the issues. Present findings first (ordered by severity with file/line references), follow with open questions or assumptions, and offer a change-summary only as a secondary detail. If no findings are discovered, state that explicitly and mention any residual risks or testing gaps.


# Frontend tasks

When doing frontend design tasks, avoid collapsing into "AI slop" or safe, average-looking layouts.
Aim for interfaces that feel intentional, bold, and a bit surprising.
- Typography: Use expressive, purposeful fonts and avoid default stacks (Inter, Roboto, Arial, system).
- Color & Look: Choose a clear visual direction; define CSS variables; avoid purple-on-white defaults. No purple bias or dark mode bias.
- Motion: Use a few meaningful animations (page-load, staggered reveals) instead of generic micro-motions.
- Background: Don't rely on flat, single-color backgrounds; use gradients, shapes, or subtle patterns to build atmosphere.
- Overall: Avoid boilerplate layouts and interchangeable UI patterns. Vary themes, type families, and visual languages across outputs.
- Ensure the page loads properly on both desktop and mobile
- Finish the website or app to completion, within the scope of what's possible without adding entire adjacent features or services. It should be in a working state for a user to run and test.

Exception: If working within an existing website or design system, preserve the established patterns, structure, and visual language.


# Presenting your work and final message

You are producing plain text that will later be styled by the CLI. Follow these rules exactly. Formatting should make results easy to scan, but not feel mechanical. Use judgment to decide how much structure adds value.

- Default: be very concise; friendly coding teammate tone.
- Format: Use natural language with high-level headings.
- Ask only when needed; suggest ideas; mirror the user's style.
- For substantial work, summarize clearly; follow final‑answer formatting.
- Skip heavy formatting for simple confirmations.
- Don't dump large files you've written; reference paths only.
- No "save/copy this file" - User is on the same machine.
- Offer logical next steps (tests, commits, build) briefly; add verify steps if you couldn't do something.
- For code changes:
  * Lead with a quick explanation of the change, and then give more details on the context covering where and why a change was made. Do not start this explanation with "summary", just jump right in.
  * If there are natural next steps the user may want to take, suggest them at the end of your response. Do not make suggestions if there are no natural next steps.
  * When suggesting multiple options, use numeric lists for the suggestions so the user can quickly respond with a single number.
- The user does not command execution outputs. When asked to show the output of a command (e.g. `git show`), relay the important details in your answer or summarize the key lines so the user understands the result.

## Final answer structure and style guidelines

- Plain text; CLI handles styling. Use structure only when it helps scanability.
- Headers: optional; short Title Case (1-3 words) wrapped in **…**; no blank line before the first bullet; add only if they truly help.
- Bullets: use - ; merge related points; keep to one line when possible; 4–6 per list ordered by importance; keep phrasing consistent.
- Monospace: backticks for commands/paths/env vars/code ids and inline examples; use for literal keyword bullets; never combine with **.
- Code samples or multi-line snippets should be wrapped in fenced code blocks; include an info string as often as possible.
- Structure: group related bullets; order sections general → specific → supporting; for subsections, start with a bolded keyword bullet, then items; match complexity to the task.
- Tone: collaborative, concise, factual; present tense, active voice; self‑contained; no "above/below"; parallel wording.
- Don'ts: no nested bullets/hierarchies; no ANSI codes; don't cram unrelated keywords; keep keyword lists short—wrap/reformat if long; avoid naming formatting styles in answers.
- Adaptation: code explanations → precise, structured with code refs; simple tasks → lead with outcome; big changes → logical walkthrough + rationale + next actions; casual one-offs → plain sentences, no headers/bullets.
- File References: When referencing files in your response follow the below rules:
  * Use inline code to make file paths clickable.
  * Each reference should have a stand-alone path, even if it's the same file.
  * Accepted: absolute, workspace‑relative, a/ or b/ diff prefixes, or bare filename/suffix.
  * Optionally include line/column (1‑based): :line[:column] or #Lline[Ccolumn] (column defaults to 1).
  * Do not use URIs like file://, vscode://, or https://.
  * Do not provide range of lines
  * Examples: src/app.ts, src/app.ts:42, b/server/index.js#L10, C:\repo\project\main.rs:12:5

Actualizaciones para el usuario durante la ejecución

La familia de modelos Codex puede mostrar actualizaciones al usuario mientras trabaja. En las versiones de codex anteriores a gpt-5.3-codex, estas actualizaciones las genera el sistema y no se pueden configurar mediante prompts, por lo que desaconsejamos agregar al prompt instrucciones sobre planes intermedios o mensajes al usuario para esas versiones. A partir de gpt-5.3-codex, estas actualizaciones son más comunicativas y ofrecen más información clave sobre lo que ocurre y por qué. Funcionan de forma similar a los mensajes intermedios de otros modelos de la serie GPT-5 y se pueden configurar mediante prompts según la sección Preámbulos y personalidad que aparece más adelante.

Uso de agents.md

Codex-cli enumera estos archivos automáticamente y los inserta en la conversación; el modelo está entrenado para seguir estas instrucciones de cerca.

1. Los archivos se obtienen de ~/.codex y de cada directorio desde la raíz del repositorio hasta el directorio de trabajo actual (CWD), con nombres alternativos opcionales y un límite de tamaño.
2. Se combinan en orden; las instrucciones de los directorios posteriores prevalecen sobre las de los anteriores.
3. Cada fragmento combinado se presenta al modelo como un mensaje independiente con el rol de usuario, de esta manera:

# AGENTS.md instructions for <directory>
<INSTRUCTIONS>
...file contents...
</INSTRUCTIONS>

Detalles adicionales

• Cada archivo encontrado se convierte en un mensaje independiente con el rol de usuario que comienza con # AGENTS.md instructions for <directory>, donde <directory> es la ruta (relativa a la raíz del repositorio) de la carpeta de la que se obtuvo el archivo.
• Los mensajes se insertan cerca del inicio del historial de la conversación, antes del prompt del usuario, desde la raíz hacia los subdirectorios: primero las instrucciones globales, luego las de la raíz del repositorio y después las de cada directorio más profundo. Si se usó un archivo AGENTS.override.md, el nombre de su directorio sigue apareciendo en el encabezado (por ejemplo, # AGENTS.md instructions for backend/api), de modo que el contexto queda claro en la transcripción.

Compactación

La compactación permite ampliar considerablemente la ventana de contexto efectiva. Así, las conversaciones con el usuario pueden continuar durante muchos turnos sin alcanzar los límites de la ventana de contexto ni sufrir una degradación del rendimiento por un contexto largo, y los agentes pueden realizar secuencias de acciones muy extensas que superan una ventana de contexto típica en tareas complejas de larga duración. Antes era posible lograr una versión más limitada mediante estructuras auxiliares ad hoc y resúmenes de conversaciones, pero nuestra implementación nativa, disponible a través de la API Responses, está integrada con el modelo y ofrece un alto rendimiento.

Cómo funciona:

1. Usas la API Responses como lo haces actualmente y envías elementos de entrada que incluyen llamadas a herramientas, entradas del usuario y mensajes del asistente.
2. Cuando tu ventana de contexto crece demasiado, puedes invocar /compact para generar una nueva ventana de contexto compactada. Ten en cuenta dos cosas:
   1. La ventana de contexto que envíes a /compact debe caber dentro de la ventana de contexto de tu modelo.
   2. El punto de acceso es compatible con ZDR y devolverá un elemento “encrypted_content” que puedes incluir en solicitudes futuras.
3. En las llamadas posteriores al punto de acceso /responses, puedes enviar tu lista de elementos de conversación actualizada y compactada (incluido el elemento de compactación agregado). El modelo conserva la información clave del estado anterior con menos tokens de conversación.

Para obtener detalles sobre el punto de acceso, consulta nuestra documentación de /responses/compact.

Herramientas

1. Recomendamos enfáticamente usar nuestra implementación exacta de apply_patch, ya que el modelo está entrenado para manejar este formato de diff con gran precisión. Para los comandos de terminal, recomendamos nuestra herramienta shell; para los elementos del plan y las tareas pendientes, nuestra herramienta update_plan debería ofrecer el mejor rendimiento.
2. Si prefieres que tu agente use más “herramientas similares a una terminal” (como file_read() en lugar de llamar a `sed` en la terminal), este modelo puede llamarlas de forma confiable en lugar de usar la terminal (siguiendo las instrucciones que aparecen a continuación)
3. Otras herramientas, como la búsqueda semántica, los MCP u otras herramientas personalizadas, pueden funcionar, pero requieren más ajustes y experimentación.

Apply_patch

La forma más sencilla de implementar apply_patch es usar nuestra implementación nativa en la API Responses, pero también puedes usar nuestra implementación como herramienta de formato libre con gramática libre de contexto. A continuación se muestran ambas.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146# Sample script to demonstrate the server-defined apply_patch tool

import json
from pprint import pprint
from typing import cast

from openai import OpenAI
from openai.types.responses import ResponseInputParam, ToolParam

client = OpenAI()

## Shared tools and prompt
user_request = """Add a cancel button that logs when clicked"""
file_excerpt = """\
export default function Page() {
return (
<div>
    <p>Page component not implemented</p>
    <button onClick={() => console.log("clicked")}>Click me</button>
</div>
);
}
"""

input_items: ResponseInputParam = [
    {"role": "user", "content": user_request},
    {
        "type": "function_call",
        "call_id": "call_read_file_1",
        "name": "read_file",
        "arguments": json.dumps({"path": ("/app/page.tsx")}),
    },
    {
        "type": "function_call_output",
        "call_id": "call_read_file_1",
        "output": file_excerpt,
    },
]

read_file_tool: ToolParam = cast(
    ToolParam,
    {
        "type": "function",
        "name": "read_file",
        "description": "Reads a file from disk",
        "parameters": {
            "type": "object",
            "properties": {"path": {"type": "string"}},
            "required": ["path"],
        },
    },
)

### Get patch with built-in responses tool
tools: list[ToolParam] = [
    read_file_tool,
    cast(ToolParam, {"type": "apply_patch"}),
]

response = client.responses.create(
    model="gpt-5.3-codex",
    input=input_items,
    tools=tools,
    parallel_tool_calls=False,
)

for item in response.output:
    if item.type == "apply_patch_call":
        print("Responses API apply_patch patch:")
        pprint(item.operation)
        # output:
        # {'diff': '@@\n'
        #          '   return (\n'
        #          '     <div>\n'
        #          '       <p>Page component not implemented</p>\n'
        #          '       <button onClick={() => console.log("clicked")}>Click me</button>\n'
        #          '+      <button onClick={() => console.log("cancel clicked")}>Cancel</button>\n'
        #          '     </div>\n'
        #          '   );\n'
        #          ' }\n',
        #  'path': '/app/page.tsx',
        #  'type': 'update_file'}

### Get patch with custom tool implementation, including freeform tool definition and context-free grammar
apply_patch_grammar = """
start: begin_patch hunk+ end_patch
begin_patch: "*** Begin Patch" LF
end_patch: "*** End Patch" LF?

hunk: add_hunk | delete_hunk | update_hunk
add_hunk: "*** Add File: " filename LF add_line+
delete_hunk: "*** Delete File: " filename LF
update_hunk: "*** Update File: " filename LF change_move? change?

filename: /(.+)/
add_line: "+" /(.*)/ LF -> line

change_move: "*** Move to: " filename LF
change: (change_context | change_line)+ eof_line?
change_context: ("@@" | "@@ " /(.+)/) LF
change_line: ("+" | "-" | " ") /(.*)/ LF
eof_line: "*** End of File" LF

%import common.LF
"""

tools_with_cfg: list[ToolParam] = [
    read_file_tool,
    cast(
        ToolParam,
        {
            "type": "custom",
            "name": "apply_patch_grammar",
            "description": "Use the `apply_patch` tool to edit files. This is a FREEFORM tool, so do not wrap the patch in JSON.",
            "format": {
                "type": "grammar",
                "syntax": "lark",
                "definition": apply_patch_grammar,
            },
        },
    ),
]

response_cfg = client.responses.create(
    model="gpt-5.3-codex",
    input=input_items,
    tools=tools_with_cfg,
    parallel_tool_calls=False,
)

for item in response_cfg.output:
    if item.type == "custom_tool_call":
        print("\n\nContext-free grammar apply_patch patch:")
        print(item.input)
        #  Output
        # *** Begin Patch
        # *** Update File: /app/page.tsx
        # @@
        #      <div>
        #        <p>Page component not implemented</p>
        #        <button onClick={() => console.log("clicked")}>Click me</button>
        # +      <button onClick={() => console.log("cancel clicked")}>Cancel</button>
        #      </div>
        #    );
        #  }
        # *** End Patch

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60require "openai"

client = OpenAI::Client.new

input = <<~PROMPT
  Add a cancel button next to the save button in app/page.tsx.
  Current file contents:
  export default function Page() { return <button>Save</button>; }
PROMPT
response = client.responses.create(
  model: "gpt-5.3-codex", input: input,
  tools: [{ type: :apply_patch }], parallel_tool_calls: false
)
response.output.each do |item|
  pp(item.operation) if item.is_a?(OpenAI::Responses::ResponseApplyPatchToolCall)
end

APPLY_PATCH_GRAMMAR = <<~GRAMMAR

  start: begin_patch hunk+ end_patch
  begin_patch: "*** Begin Patch" LF
  end_patch: "*** End Patch" LF?

  hunk: add_hunk | delete_hunk | update_hunk
  add_hunk: "*** Add File: " filename LF add_line+
  delete_hunk: "*** Delete File: " filename LF
  update_hunk: "*** Update File: " filename LF change_move? change?

  filename: /(.+)/
  add_line: "+" /(.*)/ LF -> line

  change_move: "*** Move to: " filename LF
  change: (change_context | change_line)+ eof_line?
  change_context: ("@@" | "@@ " /(.+)/) LF
  change_line: ("+" | "-" | " ") /(.*)/ LF
  eof_line: "*** End of File" LF

  %import common.LF

GRAMMAR

response = client.responses.create(
  model: "gpt-5.3-codex", input: input,
  tools: [
    {
      type: :custom,
      name: "apply_patch",
      description: "Apply a patch to update files.",
      format: {
        type: :grammar,
        syntax: :lark,
        definition: APPLY_PATCH_GRAMMAR
      }
    }
  ],
  parallel_tool_calls: false
)
response.output.each do |item|
  puts(item.input) if item.is_a?(OpenAI::Responses::ResponseCustomToolCall)
end

Puedes implementar los objetos de parche de la herramienta de la API Responses siguiendo este ejemplo, y aplicar los parches de la herramienta de formato libre con la lógica de nuestra implementación canónica de apply_patch.py para GPT-5.

Shell_command

Esta es nuestra herramienta de shell predeterminada. Hemos observado un mejor rendimiento cuando el comando es de tipo “string” en lugar de una lista de comandos.

1234567891011121314151617181920212223242526272829303132333435{
  "type": "function",
  "function": {
    "name": "shell_command",
    "description": "Runs a shell command and returns its output.\n- Always set the `workdir` param when using the shell_command function. Do not use `cd` unless absolutely necessary.",
    "strict": false,
    "parameters": {
      "type": "object",
      "properties": {
        "command": {
          "type": "string",
          "description": "The shell script to execute in the user's default shell"
        },
        "workdir": {
          "type": "string",
          "description": "The working directory to execute the command in"
        },
        "timeout_ms": {
          "type": "number",
          "description": "The timeout for the command in milliseconds"
        },
        "with_escalated_permissions": {
          "type": "boolean",
          "description": "Whether to request escalated permissions. Set to true if command needs to be run without sandbox restrictions"
        },
        "justification": {
          "type": "string",
          "description": "Only set if with_escalated_permissions is true. 1-sentence explanation of why we want to run this command."
        }
      },
      "required": ["command"],
      "additionalProperties": false
    }
  }
}

Si usas Windows PowerShell, reemplaza la descripción de la herramienta por esta.

Runs a shell command and returns its output. The arguments you pass will be invoked via PowerShell (e.g., ["pwsh", "-NoLogo", "-NoProfile", "-Command", "<cmd>"]). Always fill in workdir; avoid using cd in the command string.

Puedes consultar en codex-cli la implementación de exec_command, que inicia una PTY de larga duración cuando necesitas salida en streaming, REPL o sesiones interactivas; y la de write_stdin, que permite enviar pulsaciones de teclas adicionales (o simplemente consultar la salida) a una sesión existente de exec_command.

Actualizar plan

Esta es nuestra herramienta predeterminada para tareas pendientes; puedes personalizarla como prefieras. Consulta la sección ## Plan tool de nuestro prompt inicial para obtener instrucciones adicionales que te ayuden a mantener el orden y ajustar el comportamiento.

123456789101112131415161718192021222324252627282930313233343536{
  "type": "function",
  "function": {
    "name": "update_plan",
    "description": "Updates the task plan.\nProvide an optional explanation and a list of plan items, each with a step and status.\nAt most one step can be in_progress at a time.",
    "strict": false,
    "parameters": {
      "type": "object",
      "properties": {
        "explanation": {
          "type": "string"
        },
        "plan": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "step": {
                "type": "string"
              },
              "status": {
                "type": "string",
                "description": "One of: pending, in_progress, completed"
              }
            },
            "additionalProperties": false,
            "required": ["step", "status"]
          },
          "description": "The list of steps"
        }
      },
      "additionalProperties": false,
      "required": ["plan"]
    }
  }
}

View_image

Esta es una función básica que se usa en codex-cli para que el modelo pueda ver imágenes.

12345678910111213141516171819{
  "type": "function",
  "function": {
    "name": "view_image",
    "description": "Attach a local image (by filesystem path) to the conversation context for this turn.",
    "strict": false,
    "parameters": {
      "type": "object",
      "properties": {
        "path": {
          "type": "string",
          "description": "Local filesystem path to an image file"
        }
      },
      "additionalProperties": false,
      "required": ["path"]
    }
  }
}

Herramientas específicas que encapsulan comandos de terminal

Si prefieres que tu agente codex use herramientas que encapsulan comandos de terminal (como una herramienta específica list_dir(‘.’) en lugar de terminal(‘ls .’)), esto suele funcionar bien. Observamos los mejores resultados cuando el nombre de la herramienta, los argumentos y la salida se parecen lo más posible a los del comando subyacente, de modo que se ajusten lo mejor posible a la distribución de entrenamiento del modelo (que se entrenó principalmente con una herramienta de terminal específica). Por ejemplo, si observas que el modelo usa git a través de la terminal y prefieres que use una herramienta específica, comprobamos que crear una herramienta para ello y agregar al prompt una instrucción para que use únicamente esa herramienta para los comandos de git eliminó por completo el uso de la terminal para esos comandos.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36GIT_TOOL = {
    "type": "function",
    "name": "git",
    "description": (
        "Execute a git command in the repository root. Behaves like running git in the"
        " terminal; supports any subcommand and flags. The command can be provided as a"
        " full git invocation (e.g., `git status -sb`) or just the arguments after git"
        " (e.g., `status -sb`)."
    ),
    "parameters": {
        "type": "object",
        "properties": {
            "command": {
                "type": "string",
                "description": (
                    "The git command to execute. Accepts either a full git invocation or"
                    " only the subcommand/args."
                ),
            },
            "timeout_sec": {
                "type": "integer",
                "minimum": 1,
                "maximum": 1800,
                "description": "Optional timeout in seconds for the git command.",
            },
        },
        "required": ["command"],
    },
}

TOOLS = [GIT_TOOL]

PROMPT_TOOL_USE_DIRECTIVE = (
    "- Strictly avoid raw `cmd`/terminal for Git operations. Use the dedicated "
    "`git` tool instead."
)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28require "json"

GIT_TOOL = {
  "type" => "function",
  "name" => "git",
  "description" => "Execute a git command in the repository root. Behaves like running git in the terminal; supports any subcommand and flags. The command can be provided as a full git invocation (e.g., `git status -sb`) or just the arguments after git (e.g., `status -sb`).",
  "parameters" => {
    "type" => "object",
    "properties" => {
      "command" => {
        "type" => "string",
        "description" => "The git command to execute. Accepts either a full git invocation or only the subcommand/args."
      },
      "timeout_sec" => {
        "type" => "integer",
        "minimum" => 1,
        "maximum" => 1800,
        "description" => "Optional timeout in seconds for the git command."
      }
    },
    "required" => ["command"]
  }
}

TOOLS = [GIT_TOOL]
PROMPT_TOOL_USE_DIRECTIVE = "- Strictly avoid raw `cmd`/terminal for Git operations. Use the dedicated `git` tool instead."
puts(JSON.generate(TOOLS))
puts(PROMPT_TOOL_USE_DIRECTIVE)

Otras herramientas personalizadas (búsqueda web, búsqueda semántica, memoria, etc.)

El modelo no necesariamente ha recibido posentrenamiento para destacar en el uso de estas herramientas, pero también hemos observado buenos resultados con ellas. Para aprovecharlas al máximo, recomendamos:

1. Elegir nombres de herramientas y argumentos que sean lo más “correctos” posible desde el punto de vista semántico. Por ejemplo, “search” es ambiguo, pero “semantic_search” indica claramente qué hace la herramienta y la distingue de otras herramientas de búsqueda que puedas tener. “Query” sería un buen nombre de parámetro para esta herramienta.
2. Indica explícitamente en tu prompt cuándo, por qué y cómo usar estas herramientas, e incluye ejemplos de uso correcto e incorrecto.
3. También podría ser útil que los resultados tengan un aspecto distinto al de las salidas que el modelo suele recibir de otras herramientas. Por ejemplo, los resultados de ripgrep deberían verse diferentes de los de la búsqueda semántica para evitar que el modelo vuelva a sus hábitos anteriores.

Llamadas a herramientas en paralelo

En codex-cli, cuando se habilitan las llamadas a herramientas en paralelo, la solicitud a la API Responses establece parallel_tool_calls: true y se agrega el siguiente fragmento a las instrucciones del sistema:

## Exploration and reading files

- **Think first.** Before any tool call, decide ALL files/resources you will need.
- **Batch everything.** If you need multiple files (even from different places), read them together.
- **multi_tool_use.parallel** Use `multi_tool_use.parallel` to parallelize tool calls and only this.
- **Only make sequential calls if you truly cannot know the next file without seeing a result first.**
- **Workflow:** (a) plan all needed reads → (b) issue one parallel batch → (c) analyze results → (d) repeat if new, unpredictable reads arise.

**Additional notes**:
- Always maximize parallelism. Never read files one-by-one unless logically unavoidable.
- This concerns every read/list/search operations including, but not only, `cat`, `rg`, `sed`, `ls`, `git show`, `nl`, `wc`, ...
- Do not try to parallelize using scripting or anything else than `multi_tool_use.parallel`.

Hemos observado que ordenar los elementos de las llamadas a herramientas en paralelo y sus respuestas de la siguiente manera resulta útil y se ajusta mejor a la distribución de entrenamiento del modelo:

function_call
function_call
function_call_output
function_call_output

Truncamiento de respuestas de herramientas

Recomendamos truncar las respuestas de las llamadas a herramientas de la siguiente manera para ajustarse lo más posible a la distribución de entrenamiento del modelo:

• Establece un límite de 10 000 tokens. Puedes estimar esta cantidad con un costo de cómputo bajo mediante num_bytes/4.
• Si alcanzas el límite de truncamiento, debes usar la mitad del presupuesto para el principio y la otra mitad para el final, y truncar la parte central con …3 tokens truncated…

Nuevas funciones de GPT-5.3 Codex

Mensajes de preámbulo

La API Responses incluye un parámetro phase destinado a evitar que el modelo se detenga antes de tiempo o presente otros comportamientos incorrectos cuando el prompt solicita mensajes de preámbulo. Es obligatorio implementar correctamente este parámetro para gpt-5.3-codex; de lo contrario, el rendimiento puede degradarse considerablemente.

Fase

Para mejorar la compatibilidad con los mensajes de preámbulo de gpt-5.3-codex, la API Responses incluye un campo phase diseñado para evitar que el modelo se detenga antes de tiempo en tareas de mayor duración o presente otros comportamientos incorrectos.

Valores

phase tiene uno de los siguientes valores:

• null
• "commentary"
• "final_answer"

Dónde aparece

Recibirás phase en los elementos de salida del asistente (por ejemplo, output_item.done). Tu integración debe conservar los elementos de salida del asistente, incluido su phase, y volver a enviarlos en las solicitudes posteriores.

Importante: phase solo se admite en los elementos del asistente. No agregues phase a los mensajes del usuario.

Cómo se usa en las etapas posteriores

Cuando el modelo marca un elemento de salida con:

• phase: "commentary": el mensaje correspondiente del asistente debe tratarse como contenido de tipo comentario o preámbulo.
• phase: "final_answer": el mensaje correspondiente del asistente debe tratarse como la respuesta de cierre.

Es obligatorio conservar correctamente phase en los elementos del asistente para gpt-5.3-codex. Si se pierden los metadatos phase del asistente durante la reconstrucción del historial, el rendimiento puede degradarse considerablemente.

Preámbulos y personalidad

Los preámbulos son mensajes que se envían junto con las llamadas a herramientas para mantener al usuario al tanto mientras se trabaja: resúmenes breves y fáciles de leer sobre el progreso y lo que se pretende hacer, que orientan al usuario sin convertir la transcripción en un registro de llamadas a herramientas. Los preámbulos de GPT-5.3-Codex se han ajustado para que tengan las siguientes características:

• Confirma que entendiste la solicitud y luego presenta un plan antes de llamar a cualquier herramienta (1 oración de confirmación y 1–2 oraciones para el plan).
• Limita la mayoría de las actualizaciones a 1–2 oraciones y usa actualizaciones más largas solo al alcanzar hitos reales.
• Frecuencia: procura enviar una actualización cada 1–3 pasos de ejecución; mínimo obligatorio: al menos una cada 6 pasos o 10 llamadas a herramientas.
• Contenido de cada actualización: resultados o impacto hasta el momento, los próximos 1–3 pasos y las preguntas pendientes o lo aprendido, cuando corresponda.
• Tono: como una persona real que colabora contigo, sin demasiadas formalidades; evita los encabezados, las etiquetas de estado y el estilo de los registros de ejecución.

Personalidad (Amable vs. Pragmático)

La personalidad es el tono general y la actitud de colaboración que van más allá de los aspectos mecánicos de los preámbulos (frecuencia, extensión y anclaje). Afecta la elección de palabras, la disposición del modelo a explicar las ventajas y desventajas de cada opción y la calidez que aporta a la interacción.

Codex App y la CLI incluyen compatibilidad con dos personalidades que se presentan aquí como ejemplos de implementación para tu arnés de ejecución.

Amable

• Una colaboración más humana y cercana, como entre compañeros.
• Un poco más de reconocimiento de lo que dice el usuario, mensajes que transmiten confianza y explicaciones de contexto.
• Más adecuada cuando al usuario le resulta útil una explicación que lo oriente (primeros pasos, tareas ambiguas o cambios con mayores consecuencias).

Fragmento de ejemplo del prompt de la personalidad Amable de codex-cli

Puedes usar este fragmento en tu prompt del sistema para orientar la personalidad del modelo durante la programación en pareja.

# Personality

You optimize for team morale and being a supportive teammate as much as code quality. You communicate warmly, check in often, and explain concepts without ego. You excel at pairing, onboarding, and unblocking others. You create momentum by making collaborators feel supported and capable.

## Values
You are guided by these core values:
* Empathy: Interprets empathy as meeting people where they are - adjusting explanations, pacing, and tone to maximize understanding and confidence.
* Collaboration: Sees collaboration as an active skill: inviting input, synthesizing perspectives, and making others successful.
* Ownership: Takes responsibility not just for code, but for whether teammates are unblocked and progress continues.

## Tone & User Experience
Your voice is warm, encouraging, and conversational. You use teamwork-oriented language such as "we" and "let’s"; affirm progress, and replaces judgment with curiosity. You use light enthusiasm and humor when it helps sustain energy and focus. The user should feel safe asking basic questions without embarrassment, supported even when the problem is hard, and genuinely partnered with rather than evaluated. Interactions should reduce anxiety, increase clarity, and leave the user motivated to keep going.

You are NEVER curt or dismissive.

You are a patient and enjoyable collaborator: unflappable when others might get frustrated, while being an enjoyable, easy-going personality to work with. Even if you suspect a statement is incorrect, you remain supportive and collaborative, explaining your concerns while noting valid points. You frequently point out the strengths and insights of others while remaining focused on working with others to accomplish the task at hand.

## Escalation
You escalate gently and deliberately when decisions have non-obvious consequences or hidden risk. Escalation is framed as support and shared responsibility-never correction-and is introduced with an explicit pause to realign, sanity-check assumptions, or surface tradeoffs before committing.

Pragmático

• Un estilo más breve, directo y enfocado en entregar resultados.
• Menos fórmulas de cortesía y una mayor proporción de información útil para actuar por token.
• Más adecuada cuando la latencia o el rendimiento son importantes, o cuando tus usuarios ya conocen el flujo de trabajo y solo quieren avances y resultados.

Solución de problemas y diseño de metaprompts

Problemas comunes a los que hemos dado seguimiento específico:

• Razonamiento excesivo o demora prolongada antes de la primera acción útil (una llamada a una herramienta o un plan concreto).
• Actualizaciones de estado poco naturales o con estilo de registro de ejecución, en lugar de una colaboración propia de la programación en pareja.
• Redacción poco natural en los preámbulos y muletillas repetitivas (“Bien visto”, “Ajá”, “Entendido–”, etc.).

Diseño de metaprompts para correcciones específicas

Los problemas como los anteriores normalmente pueden resolverse mediante el diseño de metaprompts. Al final de un turno cuyo desempeño no haya cumplido las expectativas, puedes preguntarle al modelo cómo mejorar sus propias instrucciones. El siguiente prompt se usó para generar algunas de las soluciones a los problemas de razonamiento excesivo mencionados anteriormente y se puede modificar para adaptarlo a tus necesidades específicas.

That was a high quality response, thanks! It seemed like it took you a while to finish responding though. Is there a way to clarify your instructions so you can get to a response as good as this faster next time? It’s extremely important to be efficient when providing these responses or users won’t get the most out of them in time. Let’s see if we can improve!
think through the response you gave above
read through your instructions starting from "" and look for anything that might have made you take longer to formulate a high quality response than you needed
write out targeted (but generalized) additions/changes/deletions to your instructions to make a request like this one faster next time with the same level of quality

Al diseñar metaprompts dentro de un contexto específico, es importante generar respuestas varias veces, si es posible, y prestar atención a los elementos que tienen en común. Algunas mejoras o cambios que propone el modelo podrían ser demasiado específicos para esa situación, pero a menudo puedes simplificarlos para obtener una mejora general. Recomendamos crear una evaluación para medir si un cambio concreto en el prompt mejora o empeora los resultados de tu caso de uso.

Algunos ejemplos

• Para el razonamiento excesivo o los inicios lentos: pídele que proponga cambios en las instrucciones que reduzcan el tiempo hasta la primera llamada a una herramienta o el primer plan concreto.
• Para los preámbulos que se parecen demasiado a un registro de ejecución: pídele que reescriba tus instrucciones sobre las actualizaciones para el usuario de modo que cumplan con tus preferencias específicas.

Introducción

GPT-5.2 se lanzó como un modelo insignia de propósito general para tareas tanto generales como con agentes. En comparación con GPT-5.1, mejoró en los siguientes aspectos:

• Inteligencia general
• Seguimiento de instrucciones
• Precisión y eficiencia en el uso de tokens
• Multimodalidad, especialmente visión
• Generación de código, especialmente la creación de interfaces de usuario de front-end
• Llamadas a herramientas y gestión del contexto en la API
• Comprensión y creación de hojas de cálculo

A diferencia del modelo anterior, GPT-5.1, GPT-5.2 cuenta con nuevas funciones para gestionar lo que el modelo “sabe” y “recuerda” y así mejorar la precisión.

Esta guía explica las funciones clave de la familia de modelos GPT-5 y cómo sacar el máximo provecho de GPT-5.2.

Explora ejemplos de programación

Explora algunas aplicaciones de demostración generadas por completo con un solo prompt, sin escribir código a mano. Ten en cuenta que estos ejemplos se generaron con GPT-5.2 o con nuestro modelo insignia anterior, GPT-5.

Explore

Actualizaciones de modelos, API y funciones

La generación GPT-5.2 incluye gpt-5.2 para tareas complejas que requieren un amplio conocimiento del mundo, gpt-5.2-chat-latest para un comportamiento alineado con ChatGPT y gpt-5.2-pro para problemas que se benefician de más recursos de cómputo.

Si necesitas un modelo más pequeño, usa gpt-5-mini.

Para elegir el modelo que mejor se adapte a tu caso de uso, considera estas ventajas y desventajas:

Nuevas funciones de GPT-5.2

Al igual que GPT-5.1, el nuevo GPT-5.2 cuenta con funciones de API como herramientas personalizadas, parámetros para controlar el nivel de detalle y el razonamiento, y una lista de herramientas permitidas. Las novedades de 5.2 son un nuevo nivel de esfuerzo de razonamiento xhigh, resúmenes de razonamiento concisos y una nueva gestión del contexto mediante compactación.

Esta guía explica algunas de las funciones clave de la familia de modelos GPT-5 y cómo sacar el máximo provecho de 5.2 en particular.

Para las tareas de programación, GPT-5.2-Codex es nuestra variante optimizada para programar en flujos de trabajo con agentes en Codex o entornos similares.

Menor esfuerzo de razonamiento

El parámetro reasoning.effort controla cuántos tokens de razonamiento genera el modelo antes de producir una respuesta. Los modelos de razonamiento anteriores, como o3, solo admitían low, medium y high: low priorizaba la velocidad y un menor uso de tokens, mientras que high priorizaba un razonamiento más exhaustivo.

En GPT-5.2, el nivel más bajo es none, que permite interacciones con menor latencia. Esta es la configuración predeterminada de GPT-5.2. Si necesitas más razonamiento, aumenta gradualmente el nivel hasta medium y experimenta con los resultados.

Cuando el esfuerzo de razonamiento se establece en none, el diseño de prompts es importante. Para mejorar la calidad del razonamiento del modelo, incluso con la configuración predeterminada, anímalo a “pensar” o a esbozar sus pasos antes de responder.

1
2
3
4
5
6
7
8
9
10
11
12
13import OpenAI from "openai";
const openai = new OpenAI();

const response = await openai.responses.create({
  model: "gpt-5.2",
  input:
    "Think carefully and outline your steps before answering. How much gold would it take to coat the Statue of Liberty in a 1mm layer?",
  reasoning: {
    effort: "none",
  },
});

console.log(response);

1
2
3
4
5
6
7
8
9
10
11from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.2",
    input="Think carefully and outline your steps before answering. How much gold would it take to coat the Statue of Liberty in a 1mm layer?",
    reasoning={"effort": "none"},
)

print(response)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23package main

import (
	"context"
	"fmt"

	"github.com/openai/openai-go/v3"
	"github.com/openai/openai-go/v3/responses"
	"github.com/openai/openai-go/v3/shared"
)

func main() {
	client := openai.NewClient()
	response, err := client.Responses.New(context.Background(), responses.ResponseNewParams{
		Model:     "gpt-5.2",
		Input:     responses.ResponseNewParamsInputUnion{OfString: openai.String("Think carefully and outline your steps before answering. How much gold would it take to coat the Statue of Liberty in a 1mm layer?")},
		Reasoning: shared.ReasoningParam{Effort: shared.ReasoningEffortNone},
	})
	if err != nil {
		panic(err)
	}
	fmt.Println(response)
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18import com.openai.client.OpenAIClient;
import com.openai.client.okhttp.OpenAIOkHttpClient;
import com.openai.models.Reasoning;
import com.openai.models.ReasoningEffort;
import com.openai.models.responses.ResponseCreateParams;

ResponseCreateParams params =
    ResponseCreateParams.builder()
        .model("gpt-5.2")
        .input("Explain the bug and propose a fix.")
        .reasoning(Reasoning.builder().effort(ReasoningEffort.NONE).build())
        .build();

client.responses().create(params).output().stream()
    .flatMap(item -> item.message().stream())
    .flatMap(message -> message.content().stream())
    .flatMap(content -> content.outputText().stream())
    .forEach(text -> System.out.println(text.text()));

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22using OpenAI.Responses;
#pragma warning disable OPENAI001

string key = Environment.GetEnvironmentVariable("OPENAI_API_KEY")!;
ResponsesClient client = new(key);

CreateResponseOptions options = new()
{
    Model = "gpt-5.2",
    ReasoningOptions = new ResponseReasoningOptions
    {
        ReasoningEffortLevel = ResponseReasoningEffortLevel.None,
    },
};
options.InputItems.Add(
    ResponseItem.CreateUserMessageItem(
        "Think carefully and outline your steps before answering. How much gold would it take to coat the Statue of Liberty in a 1mm layer?"
    )
);

ResponseResult response = await client.CreateResponseAsync(options);
Console.WriteLine(response.GetOutputText());

1
2
3
4
5
6
7
8
9require "openai"

client = OpenAI::Client.new
response = client.responses.create(
  model: "gpt-5.2",
  reasoning: { effort: :minimal },
  input: "Explain the bug and propose a fix."
)
puts(response.output_text)

1
2
3
4
5
6
7
8
9
10
11curl --request POST \
  --url https://api.openai.com/v1/responses \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header 'Content-type: application/json' \
  --data '{
        "model": "gpt-5.2",
        "input": "Think carefully and outline your steps before answering. How much gold would it take to coat the Statue of Liberty in a 1mm layer?",
        "reasoning": {
                "effort": "none"
        }
}'

Nivel de detalle

El nivel de detalle determina cuántos tokens de salida se generan. Reducir la cantidad de tokens disminuye la latencia general. Aunque el enfoque de razonamiento del modelo se mantiene prácticamente igual, el modelo encuentra formas de responder con mayor concisión, lo que puede mejorar o reducir la calidad de la respuesta según tu caso de uso. Estos son algunos escenarios para ambos extremos del nivel de detalle:

• Nivel de detalle alto: úsalo cuando necesites que el modelo proporcione explicaciones exhaustivas de documentos o realice una refactorización extensa del código.
• Nivel de detalle bajo: ideal para situaciones en las que buscas respuestas concisas o generación de código específico, como consultas SQL.

GPT-5 permitió configurar esta opción con los valores high, medium o low. En GPT-5.2, el nivel de detalle sigue siendo configurable y su valor predeterminado es medium.

Al generar código con GPT-5.2, los niveles de detalle medium y high producen código más extenso y estructurado, con explicaciones integradas, mientras que el nivel low produce código más breve y conciso, con comentarios mínimos.

1
2
3
4
5
6
7
8
9
10
11
12
13import OpenAI from "openai";
const openai = new OpenAI();

const response = await openai.responses.create({
  model: "gpt-5.2",
  input:
    "What is the answer to the ultimate question of life, the universe, and everything?",
  text: {
    verbosity: "low",
  },
});

console.log(response);

1
2
3
4
5
6
7
8
9
10
11from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.2",
    input="What is the answer to the ultimate question of life, the universe, and everything?",
    text={"verbosity": "low"},
)

print(response)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22package main

import (
	"context"
	"fmt"

	"github.com/openai/openai-go/v3"
	"github.com/openai/openai-go/v3/responses"
)

func main() {
	client := openai.NewClient()
	response, err := client.Responses.New(context.Background(), responses.ResponseNewParams{
		Model: "gpt-5.2",
		Input: responses.ResponseNewParamsInputUnion{OfString: openai.String("What is the answer to the ultimate question of life, the universe, and everything?")},
		Text:  responses.ResponseTextConfigParam{Verbosity: responses.ResponseTextConfigVerbosityLow},
	})
	if err != nil {
		panic(err)
	}
	fmt.Println(response)
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17import com.openai.client.OpenAIClient;
import com.openai.client.okhttp.OpenAIOkHttpClient;
import com.openai.models.responses.ResponseCreateParams;
import com.openai.models.responses.ResponseTextConfig;

ResponseCreateParams params =
    ResponseCreateParams.builder()
        .model("gpt-5.2")
        .input("Explain the bug and propose a fix.")
        .text(ResponseTextConfig.builder().verbosity(ResponseTextConfig.Verbosity.LOW).build())
        .build();

client.responses().create(params).output().stream()
    .flatMap(item -> item.message().stream())
    .flatMap(message -> message.content().stream())
    .flatMap(content -> content.outputText().stream())
    .forEach(text -> System.out.println(text.text()));

1
2
3
4
5
6
7
8
9require "openai"

client = OpenAI::Client.new
response = client.responses.create(
  model: "gpt-5.2",
  text: { verbosity: :low },
  input: "Explain the bug and propose a fix."
)
puts(response.output_text)

1
2
3
4
5
6
7
8
9
10
11curl --request POST \
  --url https://api.openai.com/v1/responses \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header 'Content-type: application/json' \
  --data '{
  "model": "gpt-5.2",
  "input": "What is the answer to the ultimate question of life, the universe, and everything?",
  "text": {
    "verbosity": "low"
  }
}'

Puedes seguir ajustando el nivel de detalle mediante prompts después de establecerlo en low en la API. El parámetro de nivel de detalle define un rango general de tokens en el prompt del sistema, pero la salida concreta se adapta a los prompts del desarrollador y del usuario dentro de ese rango.

Uso de herramientas con GPT-5.2

GPT-5.2 se ha posentrenado para usar herramientas específicas. Consulta la documentación de herramientas para obtener indicaciones más específicas.

La herramienta Aplicar parches

La herramienta apply_patch permite que GPT-5.2 cree, actualice y elimine archivos en tu base de código mediante diffs estructurados. En lugar de limitarse a sugerir modificaciones, el modelo genera operaciones de parche que tu aplicación aplica y cuyos resultados luego comunica al modelo, lo que permite flujos de trabajo iterativos de edición de código en varios pasos. Consulta la documentación.

Internamente, esta implementación utiliza una llamada a función de formato libre en lugar de un formato JSON. En las pruebas, la función con nombre redujo las tasas de error de apply_patch en un 35 %.

Herramienta Shell

GPT-5.2 admite Shell local. La herramienta Shell permite que el modelo interactúe con tu computadora local a través de una interfaz de línea de comandos controlada. Consulta la documentación para obtener más información.

Herramientas personalizadas

Con el lanzamiento de la familia de modelos GPT-5, presentamos una nueva capacidad llamada herramientas personalizadas, que permite a los modelos enviar cualquier texto sin procesar como entrada de una llamada a herramienta y, aun así, restringir las salidas si se desea. Este comportamiento de las herramientas se mantiene en GPT-5.2.

Entradas de formato libre

Define tu herramienta con type: custom para permitir que los modelos envíen entradas de texto sin formato directamente a tus herramientas, sin limitarse a JSON estructurado. El modelo puede enviar cualquier texto sin procesar, como código, consultas SQL, comandos de shell, archivos de configuración o textos extensos en prosa, directamente a tu herramienta.

12345{
  "type": "custom",
  "name": "code_exec",
  "description": "Executes arbitrary python code"
}

Restricción de salidas

GPT-5.2 admite gramáticas libres de contexto (CFGs) para herramientas personalizadas, lo que te permite proporcionar una gramática Lark para restringir las salidas a una sintaxis específica o un DSL. Adjuntar una CFG, por ejemplo, una gramática SQL o de un DSL, garantiza que el texto del asistente se ajuste a tu gramática.

Esto permite realizar llamadas a herramientas precisas y sujetas a restricciones, o generar respuestas estructuradas, y te permite exigir formatos sintácticos estrictos o específicos de un dominio directamente en las llamadas a funciones de GPT-5.2, lo que mejora el control y la confiabilidad en dominios complejos o sujetos a restricciones.

Prácticas recomendadas para herramientas personalizadas