Introducción
Entrando en 2025, la API de OpenAI ha alcanzado un punto de inflexión importante. En marzo de 2025, la Responses API fue lanzada oficialmente (GA), consolidando las capacidades de conversación de la Chat Completions API y las funciones de integración de herramientas de la Assistants API en un único endpoint. La API de Assistants (legacy) está programada para ser retirada el 26 de agosto de 2026.
Además, Structured Outputs, que garantiza que las salidas del modelo se adhieren estrictamente a un esquema JSON, demuestra su verdadero potencial cuando se combina con la Responses API. Desde su lanzamiento en agosto de 2024, ha mejorado significativamente la fiabilidad de los flujos de trabajo agénticos y los pipelines de extracción de datos.
Este artículo primero describe el panorama general de la API de OpenAI a partir de 2025, y luego profundiza en las especificaciones y detalles de implementación de estos dos temas clave.
Información de fuentes
Las especificaciones y datos de rendimiento en este artículo hacen referencia a la Documentación Oficial de OpenAI (developers.openai.com/api), la Guía de Migración Oficial (developers.openai.com/api/docs/guides/migrate-to-responses) y el Blog Oficial (openai.com/index/introducing-structured-outputs-in-the-api).
1. Panorama de la API
Las principales categorías de la API de OpenAI a partir de 2025 se organizan de la siguiente manera:
| Categoría | Endpoint | Posicionamiento |
|---|---|---|
| Responses API | POST /v1/responses |
Recomendado para nuevos proyectos. Interfaz unificada para agentes. |
| Chat Completions API | POST /v1/chat/completions |
Soporte continuo (sin depreciación planificada). |
| Realtime API | WebRTC / WebSocket / SIP | Voz y texto bidireccional en tiempo real. |
| Embeddings | POST /v1/embeddings |
Búsqueda vectorial y RAG. |
| Images | POST /v1/images/generations |
Generación y edición de imágenes. |
| Audio | POST /v1/audio/transcriptions |
Reconocimiento de voz y TTS. |
OpenAI ha posicionado la Responses API como el destino principal para nuevas funcionalidades, y la retirada de la Assistants API el 26 de agosto de 2026 ha sido confirmada oficialmente (Fuente: Guía de Migración Oficial). Aunque la Chat Completions API seguirá siendo soportada sin una fecha de retirada, la Responses API es la recomendación actual para nuevos proyectos.
Structured Outputs no es un endpoint independiente como los de la tabla anterior, sino una opción de control de formato de salida disponible tanto para la Responses API como para la Chat Completions API. Se especifica usando el parámetro text.format en la primera y el parámetro response_format en la última. Este artículo se enfoca particularmente en su combinación con la Responses API.
2. Responses API
2.1 Descripción general
La Responses API es un nuevo primitivo que sucede a la Chat Completions API e integra las funciones de la Assistants API. Alcanzó Disponibilidad General (GA) en marzo de 2025.
El cambio más significativo es la capacidad de persistir el estado de la conversación en el lado del servidor. A diferencia de las Chat Completions tradicionales, que requerían incluir todo el historial de la conversación en cada solicitud, la Responses API te permite continuar una conversación simplemente pasando un previous_response_id.
2.2 Solicitud básica
import OpenAI from "openai";
const client = new OpenAI();
const response = await client.responses.create({
model: "gpt-4o",
input: "Dime el clima en Tokio.",
});
console.log(response.output_text); // Recupera el texto directamente usando el helper output_text
2.3 El helper output_text
output_text es una propiedad de conveniencia proporcionada por el SDK de OpenAI, no es parte de la especificación de la API en sí.
En la respuesta sin procesar de la Responses API, el texto está anidado dentro de la siguiente estructura:
response.output[0].content[0].text
output_text resume el proceso de recorrer esta ruta. Internamente, devuelve el texto del primer elemento en el array output que tiene type: "message" y un bloque content con type: "output_text".
// Ambos producen el mismo resultado
console.log(response.output_text);
console.log(response.output[0].content[0].text);
Sin embargo, puede no funcionar como se espera si el primer elemento en el array output no es un mensaje de texto — por ejemplo, cuando ocurre una llamada a herramienta. Para código agéntico robusto que usa herramientas, es mejor recorrer el array output y verificar el type.
for (const item of response.output) {
if (item.type === "message") {
for (const block of item.content) {
if (block.type === "output_text") {
console.log(block.text);
}
}
}
}
2.4 role en los mensajes de entrada
Al pasar un array a input, puedes especificar un role para cada mensaje. El role le dice al modelo "quién está haciendo esta declaración", y hay tres tipos.
| role | Significado | Uso típico |
|---|---|---|
system |
Instrucciones del sistema (desarrollador) | Define el comportamiento, tono y restricciones del modelo. Generalmente se coloca una vez al inicio de una conversación. |
user |
Entrada del usuario final | Representa las declaraciones o preguntas del usuario. |
assistant |
Las declaraciones pasadas del propio modelo | Se usa en conversaciones multipaso para proporcionar respuestas anteriores como historial. |
const response = await client.responses.create({
model: "gpt-4o",
input: [
{
role: "system",
content: "Eres un asistente útil en español. Por favor, responde de forma concisa.",
},
{
role: "user",
content: "Cuéntame sobre los métodos de array de JavaScript.",
},
],
});
Si pasas una cadena directamente a input (como en el ejemplo en 2.2), esa cadena se trata como un mensaje con role: "user". Usa el formato de array si quieres un control detallado sobre el comportamiento del modelo o si quieres proporcionar instrucciones system.
2.5 Estructura de la respuesta
A diferencia de choices de Chat Completions, los resultados se devuelven en un array output.
{
"id": "resp_68af4030...",
"object": "response",
"created_at": 1756315696,
"model": "gpt-4o",
"output": [
{
"id": "msg_68af4033...",
"type": "message",
"status": "completed",
"role": "assistant",
"content": [
{
"type": "output_text",
"text": "El clima en Tokio es soleado."
}
]
}
],
"usage": {
"input_tokens": 15,
"output_tokens": 12,
"total_tokens": 27
}
}
2.6 Conversación multipaso
Hay dos formas de lograr conversaciones multipaso con la Responses API.
1. Pasar el historial como un array en input
Este es el método tradicional de la Chat Completions API. Mantienes y gestionas el historial de la conversación en el lado del cliente e incluyes todos los mensajes en cada solicitud.
const history = [
{ role: "system", content: "Eres un asistente útil." },
{ role: "user", content: "Dime el clima en Tokio." },
{ role: "assistant", content: "Hoy está soleado en Tokio." },
];
const response = await client.responses.create({
model: "gpt-4o",
input: [...history, { role: "user", content: "¿Y mañana?" }],
});
Dado que el estado no se mantiene en el servidor, la ventaja es que puedes manipular libremente el historial, como eliminar o resumir mensajes específicos. Sin embargo, a medida que la conversación se alarga, aumenta el número de tokens de entrada, impactando tanto el costo como la latencia.
2. Pasar previous_response_id (exclusivo de Responses API)
Este es el método de gestión de estado del lado del servidor introducido con la Responses API. Simplemente pasando el ID de la respuesta anterior, los servidores de OpenAI continuarán el historial de la conversación.
// Primer turno
const response1 = await client.responses.create({
model: "gpt-4o",
input: "Dime el clima en Tokio.",
});
// Segundo turno: El contexto se hereda usando solo previous_response_id
const response2 = await client.responses.create({
model: "gpt-4o",
input: "¿Y mañana?",
previous_response_id: response1.id,
});
El cliente no necesita mantener ni enviar todo el historial, manteniendo pequeño el tamaño de la solicitud. Además, al usar modelos de razonamiento como o1 u o3, los tokens de pensamiento se preservan entre turnos, lo cual es una ventaja significativa ya que mejora la precisión para tareas que requieren razonamiento continuo.
Para usar este método, la respuesta debe guardarse en el servidor. Ten en cuenta que aunque el parámetro store por defecto es true, establecerlo a store: false hará imposible la referencia por ID.
Criterios de selección
| Situación | Método recomendado |
|---|---|
| Necesitas modificar/editar el historial a mitad (inyección RAG, eliminar mensajes antiguos, etc.) | ① Basado en array |
| Resolver problemas multipaso complejos con modelos de razonamiento (o1, o3, etc.) | ② previous_response_id |
| Chat simple donde quieres evitar la gestión manual del historial | ② previous_response_id |
| Usando la Chat Completions API | ① Basado en array (previous_response_id es solo para Responses API) |
Si se requiere gestión de conversación persistente, también es posible la integración con la Conversations API.
2.7 Herramientas integradas
Uno de los mayores beneficios de la Responses API es el conjunto de herramientas integradas disponibles sin infraestructura adicional.
const response = await client.responses.create({
model: "gpt-4o",
input: "Busca las últimas noticias de OpenAI y resúmelas.",
tools: [
{ type: "web_search_preview" },
{ type: "file_search" },
{ type: "code_interpreter" },
],
});
| Herramienta | Propósito |
|---|---|
web_search_preview |
Búsqueda web equivalente a ChatGPT. |
file_search |
Búsqueda RAG sobre archivos subidos. |
code_interpreter |
Ejecución de código y análisis de datos. |
computer_use |
Agente de operación de computadora. |
mcp |
Conexión a servidores MCP de terceros. |
Integración MCP (Model Context Protocol)
Los Connectors son wrappers MCP mantenidos por OpenAI para servicios populares como Google Workspace o Dropbox, mientras que los servidores MCP remotos son cualquier servidor en la internet pública que implemente el protocolo MCP remoto (Fuente: Guía de Connectors y MCP de OpenAI).
La Responses API puede integrarse con servidores MCP remotos que soporten los protocolos de transporte Streamable HTTP o HTTP/SSE. Cuando se especifica una herramienta, la API primero recupera la lista de herramientas disponibles del servidor (mcp_list_tools), y el modelo luego llama a las herramientas necesarias de esa lista.
Ejemplo de conexión básica (Fuente: Guía de Using tools de OpenAI)
const response = await client.responses.create({
model: "gpt-4o",
input: "Tira 2d6 y dime el resultado.",
tools: [
{
type: "mcp",
server_label: "dice_server", // Identificador para el servidor (arbitrario)
server_url: "https://example.com/mcp", // URL del servidor MCP
require_approval: "never", // Aprobar automáticamente las llamadas a herramientas
},
],
});
console.log(response.output_text);
Control de aprobación con require_approval
Por defecto, todas las llamadas a herramientas requieren aprobación explícita del desarrollador. Puedes controlar este comportamiento con require_approval (Fuente: Guía de Connectors y MCP de OpenAI).
const response = await client.responses.create({
model: "gpt-4o",
input: "Cuéntame sobre los protocolos de transporte de la especificación MCP.",
tools: [
{
type: "mcp",
server_label: "deepwiki",
server_url: "https://mcp.deepwiki.com/mcp",
require_approval: {
never: {
// Estas dos herramientas no requieren aprobación; las demás sí
tool_names: ["ask_question", "read_wiki_structure"],
},
},
},
],
});
Valor de require_approval |
Comportamiento |
|---|---|
"never" |
Aprobar automáticamente todas las llamadas a herramientas. |
{ never: { tool_names: [...] } } |
Aprobar automáticamente las herramientas especificadas; las demás requieren aprobación. |
| Omitido (Predeterminado) | Todas las llamadas a herramientas requieren aprobación. |
Conexión a servidores que requieren autenticación
Si el servidor MCP requiere autenticación, pasa el token usando el parámetro headers.
const response = await client.responses.create({
model: "gpt-4o",
input: "Obtén algunos datos.",
tools: [
{
type: "mcp",
server_label: "my_server",
server_url: "https://my-mcp-server.example.com/mcp",
require_approval: "never",
headers: {
Authorization: `Bearer ${process.env.MCP_ACCESS_TOKEN}`,
},
},
],
});
Caché de lista de herramientas: Aunque la recuperación de la lista de herramientas del servidor MCP (
mcp_list_tools) ocurre por solicitud, en conversaciones multipaso que usanprevious_response_id, la lista de herramientas se incluye en la respuesta anterior, por lo que se omite la re-recuperación (Fuente: OpenAI Cookbook: Guía de herramientas MCP).
2.8 Parámetros clave de la solicitud
| Parámetro | Tipo | Descripción |
|---|---|---|
model |
string | Nombre del modelo (por ejemplo, gpt-4o). |
input |
string / array | Entrada de texto o multimodal. |
previous_response_id |
string | ID de la respuesta anterior para multipaso. |
tools |
array | Definiciones de herramientas a usar. |
text.format |
object | Especificación para Structured Outputs (ver abajo). |
stream |
boolean | Habilitar streaming. |
store |
boolean | Si guardar la respuesta en el servidor (predeterminado: true). |
reasoning_effort |
string | Ajustar la profundidad del razonamiento (low / medium / high). |
background |
boolean | Ejecución asíncrona en modo background. |
2.9 Comparación con Chat Completions
| Característica | Chat Completions | Responses API |
|---|---|---|
| Estado de la conversación | Del lado del cliente (se requiere todo el historial) | Del lado del servidor (previous_response_id) |
| Búsqueda web | Implementación manual necesaria | Integrada (web_search_preview) |
| Búsqueda de archivos / RAG | Implementación manual necesaria | Integrada (file_search) |
| Ejecución de código | Implementación manual necesaria | Integrada (code_interpreter) |
| Conexión MCP | No soportado | Soporte nativo para MCP remoto |
| Persistencia de tokens de razonamiento | Descartados entre turnos | Pueden persistirse |
Helper output_text |
No | Sí |
| Especificación de formato | response_format |
text.format |
| Entrega de nuevas funcionalidades | Limitada | Destino principal |
2.10 Modelos de razonamiento (serie o)
Distintos de la serie GPT, OpenAI ofrece un grupo de modelos llamados Modelos de Razonamiento. Estos modelos ejecutan un proceso de pensamiento paso a paso interno (Chain-of-Thought) antes de generar una respuesta. Este pensamiento interno se cuenta como tokens de razonamiento, que no se incluyen en la salida final.
Demuestran una precisión significativamente mayor que GPT-4o para tareas que requieren razonamiento de múltiples pasos, como matemáticas, codificación, inferencia lógica y análisis complejos. Por otro lado, la latencia y los costos son mayores porque el pensamiento lleva tiempo.
Modelos principales a partir de 2025:
| Modelo | Características |
|---|---|
o1 / o1-mini |
Modelos de razonamiento de primera generación. |
o3 / o3-mini |
Serie sucesora de alta precisión y alto rendimiento. |
o4-mini |
Modelo equilibrado en costo y rendimiento. |
La profundidad del razonamiento se puede ajustar con el parámetro reasoning_effort (ver 2.8). low es un razonamiento ligero que reduce la latencia y el costo, mientras que high es un razonamiento profundo para máxima precisión.
const response = await client.responses.create({
model: "o3",
input: "Encuentra el término general para esta secuencia: 1, 1, 2, 3, 5, 8, 13, ...",
reasoning_effort: "high",
});
Además, en conversaciones multipaso que usan previous_response_id (ver 2.6, método 2), los tokens de razonamiento se preservan entre turnos. Al profundizar en el mismo problema durante múltiples turnos, la precisión y eficiencia mejoran porque el modelo hereda el razonamiento del turno anterior en lugar de comenzar desde cero.
3. Structured Outputs
3.1 Descripción general y contexto
Forzar de manera confiable las salidas de LLM en formato JSON ha sido un desafío clave para la integración de aplicaciones. OpenAI ha resuelto esto de manera incremental:
Modo JSON (función legacy) garantiza JSON sintácticamente correcto, pero no garantiza la adherencia a un esquema. Existía el riesgo de que faltaran campos requeridos o hubiera campos adicionales no deseados.
Structured Outputs, lanzado en agosto de 2024, garantiza el 100% de adherencia a un esquema JSON especificado por el desarrollador (Fuente: Blog Oficial de OpenAI).
Las evaluaciones internas (evals) en OpenAI muestran que gpt-4o-2024-08-06 logra una adherencia del 100% a esquemas JSON complejos usando Structured Outputs, un salto enorme respecto al menos del 40% de gpt-4-0613 (Fuente: Blog Oficial de OpenAI).
3.2 Cómo funciona
La API de OpenAI logra salidas estructuradas convirtiendo el JSON Schema especificado en una Gramática Libre de Contexto (CFG). Esta gramática restringe los tokens que se pueden generar durante el muestreo, haciendo cumplir el esquema. Debido a esto, la primera vez que se envía un nuevo esquema, hay latencia adicional para el pre-procesamiento de la gramática, pero las solicitudes posteriores con el mismo esquema no incurren en esta penalización.
Nota (Modelos fine-tuned): Para los modelos fine-tuned, ocurre latencia adicional en la primera solicitud usando un nuevo esquema. Las solicitudes posteriores con el mismo esquema no tienen esto. Otros modelos no tienen esta limitación. (Fuente: Guía de Structured Outputs)
3.3 Dos formas de usar
Structured Outputs se proporciona en dos formas en la API.
La primera es mediante Function calling (tools), habilitado al establecer strict: true dentro de la definición de función. Está disponible en todos los modelos desde gpt-4-0613 en adelante y es adecuado para conectar las capacidades del modelo con aplicaciones (por ejemplo, acceder a una función de consulta de base de datos).
La segunda es mediante el parámetro response_format / text.format, donde especificar un json_schema es adecuado para que el modelo responda al usuario en un formato estructurado (por ejemplo, mostrar diferentes partes por separado en una UI de tutorial matemático).
3.4 Ejemplo de implementación (Responses API)
En la Responses API, el parámetro ha pasado de response_format a text.format (Fuente: Guía de Migración Oficial).
Sobre description en el esquema
Se recomienda encarecidamente incluir una description para cada campo en tu JSON Schema. La description actúa como una instrucción para el modelo, proporcionando pistas para ayudarlo a determinar correctamente qué debe ir en ese campo. Los nombres de campo generales como explanation o output son particularmente propensos a ser malinterpretados por el modelo sin una description.
Al usar Zod, usa .describe("..."). Al escribir el JSON Schema directamente, especifícalo con la clave "description" dentro del objeto de propiedad.
Definición de esquema usando Zod (Recomendado)
import OpenAI from "openai";
import { zodResponseFormat } from "openai/helpers/zod";
import { z } from "zod";
const client = new OpenAI();
const Step = z.object({
explanation: z.string().describe("Explicación de lo que se está haciendo en este paso de cálculo."),
output: z.string().describe("El resultado del cálculo para este paso (fórmula o valor numérico)."),
});
const MathResponse = z.object({
steps: z.array(Step).describe("Una lista de pasos para la solución."),
final_answer: z.string().describe("La respuesta final a la ecuación (por ejemplo, x = -3.75)."),
});
const response = await client.responses.parse({
model: "gpt-4o",
input: [
{ role: "system", content: "Eres un tutor de matemáticas. Explica paso a paso." },
{ role: "user", content: "Resuelve 8x + 7 = -23" },
],
text: { format: zodResponseFormat(MathResponse, "math_response") },
});
const result = response.output_parsed;
console.log(result.final_answer);
for (const step of result.steps) {
console.log(step.explanation, "->", step.output);
}
Especificación directa del JSON Schema
const response = await client.responses.create({
model: "gpt-4o",
input: [
{ role: "system", content: "Eres un tutor de matemáticas." },
{ role: "user", content: "Resuelve 8x + 7 = -23" },
],
text: {
format: {
type: "json_schema",
name: "math_response",
strict: true,
schema: {
type: "object",
description: "Una respuesta que muestra la solución paso a paso de una ecuación.",
properties: {
steps: {
type: "array",
description: "Una lista de pasos para la solución.",
items: {
type: "object",
properties: {
explanation: {
type: "string",
description: "Explicación de lo que se está haciendo en este paso de cálculo.",
},
output: {
type: "string",
description: "El resultado del cálculo para este paso (fórmula o valor numérico).",
},
},
required: ["explanation", "output"],
additionalProperties: false,
},
},
final_answer: {
type: "string",
description: "La respuesta final a la ecuación (por ejemplo, x = -3.75).",
},
},
required: ["steps", "final_answer"],
additionalProperties: false,
},
},
},
});
Nota: El campo correcto en la Responses API es
text.format. La clave antiguaresponse_formatestá deprecada en la Responses API (Fuente: OpenAI Developer Community).
3.5 Structured Outputs en Function Calling
Para aplicar Structured Outputs a una llamada de herramienta, añade strict: true a la definición de función.
const response = await client.responses.create({
model: "gpt-4o",
input: "Dime la fecha de entrega del pedido #12345",
tools: [
{
type: "function",
name: "get_delivery_date",
description: "Obtener la fecha de entrega programada para un pedido.",
strict: true,
parameters: {
type: "object",
properties: {
order_id: { type: "string" },
},
required: ["order_id"],
additionalProperties: false,
},
},
],
});
Restricción: Al usar Structured Outputs para Function Calling,
parallel_tool_callsdebe establecerse afalse.
3.6 Qué garantiza Structured Outputs (y qué no)
| Elemento | Estado | Comentario |
|---|---|---|
| Sintaxis JSON correcta | ✅ Garantizado | — |
| Adherencia al esquema especificado | ✅ Garantizado (con strict: true) |
— |
| Presencia de campos requeridos | ✅ Garantizado | — |
| Uso de valores especificados en enum | ✅ Garantizado | — |
| Corrección factual | ❌ No garantizado | Pueden ocurrir alucinaciones para entradas no relacionadas con el esquema. |
| Exención de política de seguridad | ❌ No garantizado | El modelo puede devolver un refusal por razones de seguridad. |
Ejemplo de manejo de refusal:
const response = await client.responses.parse({
model: "gpt-4o",
input: [/* ... */],
text: { format: zodResponseFormat(MathResponse, "math_response") },
});
if (response.output[0].content[0].type === "refusal") {
console.log("El modelo rechazó:", response.output[0].content[0].refusal);
} else {
const result = response.output_parsed;
}
3.7 Restricciones del esquema en modo strict
En modo strict: true, algunas características de JSON Schema están restringidas (Fuente: Guía de Structured Outputs).
additionalProperties: falsees requerido.- Todas las propiedades deben incluirse en el array
required. - El uso directo de
anyOfen el objeto raíz no está permitido. - Se aplican restricciones a combinaciones como
oneOf,anyOf, etc.
Para evitar discrepancias entre esquemas y definiciones de tipos, OpenAI recomienda oficialmente y con firmeza usar el SDK con soporte nativo de Zod.
4. Realtime API
La Realtime API, que alcanzó Disponibilidad General (GA) en 2025, es una API especializada para streaming de voz y texto bidireccional de baja latencia vía WebRTC, WebSocket o SIP. Está diseñada para casos de uso de interacción en tiempo real como agentes de voz conectados directamente desde un navegador o integración con sistemas de telefonía (PBX), distinguiéndose claramente en su uso de la Responses API. Para más detalles, consulta la Guía Oficial de la Realtime API.
5. Streaming
La Responses API soporta streaming en formato Server-Sent Events (SSE), permitiéndote recibir respuestas largas de forma incremental.
const stream = await client.responses.stream({
model: "gpt-4o",
input: "Cuéntame en detalle sobre el inicio del universo.",
});
for await (const event of stream) {
if (
event.type === "response.output_text.delta" &&
event.delta
) {
process.stdout.write(event.delta);
}
}
Structured Outputs también puede combinarse con streaming, en cuyo caso se devuelve un JSON completo que cumple el esquema al final.
6. Cabeceras de respuesta HTTP
Las respuestas de la API incluyen cabeceras útiles para depuración y monitoreo de límites de tasa.
| Cabecera | Contenido |
|---|---|
x-request-id |
ID único para la solicitud (requerido para consultas de soporte). |
x-ratelimit-limit-requests |
Límite RPM actual aplicado. |
x-ratelimit-limit-tokens |
Límite TPM actual aplicado. |
x-ratelimit-remaining-requests |
Número restante de solicitudes. |
x-ratelimit-remaining-tokens |
Número restante de tokens. |
x-ratelimit-reset-requests |
Tiempo hasta que se reinicia el RPM. |
x-ratelimit-reset-tokens |
Tiempo hasta que se reinicia el TPM. |
Si quieres especificar un ID de solicitud desde el lado del cliente, añade la cabecera X-Client-Request-Id.
7. Límites de tasa
Los límites de tasa se aplican por Organización y Proyecto (no por usuario).
- RPM (Solicitudes Por Minuto): Número de solicitudes por minuto.
- TPM (Tokens Por Minuto): Número de tokens por minuto.
Los niveles de uso se actualizan automáticamente según los pagos acumulados y el historial de uso. Si se devuelve 429 Too Many Requests, se recomienda reintentar con backoff exponencial (Fuente: Guía de Límites de Tasa).
import retry from "async-retry";
async function callApiWithBackoff(params) {
return retry(
async () => {
return await client.responses.create(params);
},
{
retries: 6,
minTimeout: 1000,
maxTimeout: 60000,
randomize: true,
}
);
}
8. Estabilidad de versiones y fijación de modelos
Los alias como gpt-4o se actualizan periódicamente a nuevos snapshots, lo que puede cambiar la salida incluso para el mismo prompt. En producción, se recomienda fijar un nombre de snapshot como gpt-4o-2024-08-06 y siempre realizar evaluación (eval) al actualizar.
Resumen
| Punto | Contenido |
|---|---|
| Nuevos proyectos | Usar la Responses API (POST /v1/responses). |
| Chat Completions | Soporte continuo. No es necesaria migración inmediata. |
| Assistants API | Retirada el 26 de agosto de 2026. Migración a la Responses API recomendada. |
| Structured Outputs | Cumplimiento del 100% del esquema con strict: true + additionalProperties: false. |
| Uso de Responses API | Usar text.format en lugar de response_format. |
| Voz en tiempo real | Consultar la Realtime API (WebRTC / WebSocket / SIP). |
| Límites de tasa | Monitorear cabeceras y reintentar con backoff exponencial. |
| Versionado de modelos | Fijar snapshots y realizar evals en producción. |
Enlaces útiles
- Guía de Migración a Responses API — Guía de Migración Oficial.
- Guía de Structured Outputs — Guía Oficial de Structured Outputs.
- Introducing Structured Outputs in the API — Blog de lanzamiento oficial.
- Guía de Realtime API — Detalles sobre voz y texto bidireccional en tiempo real.
- Guía de Límites de Tasa — Detalles sobre límites de tasa.
- OpenAI Changelog — Historial de actualizaciones de la API.
