Si Codex muestra The model 'gpt-image-2' does not exist o la versión en español “El modelo 'gpt-image-2' no existe”, no empieces cambiando el nombre del modelo. Primero identifica la superficie que falló: OpenAI documenta gpt-image-2, pero Codex, Image API directa, Responses, un proveedor compatible y las puertas de acceso de la organización pueden fallar por separado.
Usa esta tabla como primera decisión:
| Dónde apareció el error | Primera comprobación | Siguiente paso |
|---|---|---|
| Codex app o CLI | OpenAI Status y sesión activa de Codex | Reintentar tras estado estable, refrescar auth o actualizar Codex |
| OpenAI Image API directa | Endpoint, key, org/project, acceso al modelo | Probar /images/generations mínimo con gpt-image-2 |
| Responses API | Modelo principal y forma de image_generation | No copiar la sintaxis de Image API sin revisar |
| Proveedor o proxy | Lista de modelos y base URL del proveedor | Probar OpenAI directo antes de culpar al modelo |
| Acceso de org/proyecto | Verificación, scope, región y key | Guardar request id, base URL, org/project, hora y repro mínimo |
Regla de parada: si solo falló Codex durante una ventana de incidente, revisa estado y reinicia sesión antes de cambiar código de producto.
Respuesta rápida
El mismo texto de error puede tener dueños distintos. En Codex puede ser estado, sesión o routing de herramientas. En una llamada directa puede ser endpoint, proyecto, verificación de organización o request shape. En un proveedor puede ser mapping del modelo, base URL o acceso upstream. El arreglo correcto empieza separando esas rutas.
En la revisión del 3 de junio de 2026, la documentación de generación de imágenes de OpenAI enumera gpt-image-2. Ese es el límite importante: un runtime puede no llegar a un modelo documentado, pero el texto “no existe” no demuestra que el modelo no exista globalmente.
| Situación | Mejor primer paso | Qué no hacer |
|---|---|---|
| Solo falla Codex | Revisar OpenAI Status, retry o reset de sesión | No editar código primero |
| Falla OpenAI directo | Revisar endpoint, key, org/project, access | No usar la respuesta del proveedor como evidencia de OpenAI |
| Falla Responses | Revisar modelo principal y tool image_generation | No poner gpt-image-2 en todos los campos model |
| Falla proveedor | Confirmar soporte y mapping de gpt-image-2 | No llamar precio de proveedor precio oficial |
| Falla acceso | Revisar verification, project, key scope | No rotar keys a ciegas |
Por qué Codex puede decirlo
Codex es una superficie de trabajo, no tu llamada directa a https://api.openai.com/v1/images/generations. Tiene estado de sesión, autenticación, disponibilidad de herramientas, routing y salud de servicio. Si esa capa no puede resolver una ruta de imagen, puede mostrar un mensaje de model-not-found aunque el modelo aparezca en la documentación oficial.
En español, las señales visibles mezclan actualización de Codex, API key, provider config y disponibilidad de imágenes. El lector local no necesita una historia del modelo; necesita saber si debe esperar, reiniciar Codex, probar Image API, revisar Responses o hablar con el proveedor.
Un error normal de API suele tener un dueño cercano al request: endpoint equivocado, key de otro proyecto, organización sin verificación, provider sin mapping o forma incorrecta de Responses. Un fallo solo de Codex puede estar antes de tu código. Si tu repositorio no llamó a Image API, cambiar application code es un primer paso lento y arriesgado.
Revisa Status y la sesión de Codex primero
Cuando el fallo está solo dentro de Codex, sigue este orden:
- Abre OpenAI Status y busca incidentes de Codex en la misma ventana horaria.
- Reintenta el mismo task después de monitoring o resolved.
- Crea una sesión nueva o refresca autenticación.
- Actualiza Codex CLI / app si no está al día.
- Guarda timestamp, error exacto, task y si Codex intentaba usar una herramienta de imagen.
- Pasa a pruebas API solo si el fallo sobrevive fuera de Codex o después de estado estable.
Esto evita el falso arreglo más común: cambiar un modelo válido, ocultar el problema real y crear una segunda diferencia en logs, billing o reproducibilidad.
Prueba OpenAI Image API directa
Para demostrar si tu ruta de OpenAI API llega a gpt-image-2, usa la base URL oficial con la misma organización y el mismo proyecto que esperas usar en producción.
bashcurl https://api.openai.com/v1/images/generations \ -H "Authorization: Bearer $OPENAI_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-image-2", "prompt": "A small lighthouse on a cliff, simple test image", "size": "1024x1024" }'
| Resultado | Significado | Siguiente paso |
|---|---|---|
| HTTP 200 e image data | OpenAI directo funciona | Tratar Codex como sesión/tooling |
| Error de modelo o acceso desde OpenAI | Problema de org, project o access | Revisar verification, key scope, account state |
| Provider model-not-found | El proveedor quizá no mapea el modelo | Comparar con OpenAI directo antes de cambiar nombres |
| Error de red o proxy | La petición quizá no llega a OpenAI | Log de base URL, proxy, region, request id |
Para el contrato completo de Image API, usa la guía hermana: GPT-Image-2 API Guide.
No confundas Image API y Responses
Image API directa y la herramienta de imagen de Responses tienen formas distintas. Un trabajo de imagen directo usa Image API con model: "gpt-image-2". Un flujo de asistente o agente suele usar un modelo principal con tools: [{ type: "image_generation" }].
El problema aparece cuando se mueve sintaxis entre superficies. Poner gpt-image-2 como modelo principal de Responses, o enviar la forma de Responses a /images/generations, produce errores que parecen de modelo pero en realidad son de request shape.
jsconst response = await client.responses.create({ model: "gpt-5.5", input: "Create a simple test image and explain the composition.", tools: [{ type: "image_generation" }] });
Trata el ejemplo como forma, no como recomendación congelada de modelo principal. El nombre del modelo principal puede cambiar; la separación estable es endpoint directo de imagen frente a herramienta de Responses.
Errores de proveedor o base URL personalizada
Un proveedor compatible con OpenAI puede exponer nombres parecidos, pero posee su propio mapa de modelos, facturación, disponibilidad, fallback y cuenta upstream. Si el proveedor devuelve The model 'gpt-image-2' does not exist, puede significar que no lo mapea, usa otro alias, restringe una región o no tiene acceso upstream.
Comprueba:
- ¿La base URL es realmente
https://api.openai.com/v1o una URL de proveedor/proxy? - ¿La lista actual del proveedor incluye
gpt-image-2exactamente? - ¿El proveedor exige otro endpoint, route name o modo de imagen?
- ¿Estás mezclando provider key con docs de OpenAI, o OpenAI key con docs del proveedor?
- ¿Precio, velocidad, disponibilidad, cuota o reembolso fueron verificados en este run?
Para laozhang.ai, mantén el límite limpio. Puede ser útil como route de proveedor para API, gateway y pagos, pero sus precios y cobertura son provider-owned claims, no precios oficiales de OpenAI.
Acceso, proyecto y organización
Que un modelo esté documentado no garantiza que todos los keys, proyectos u organizaciones lo puedan usar. Image API puede depender de organization verification, project scope, región, estado de cuenta y permisos del key. El acceso de ChatGPT o Codex tampoco garantiza Platform API access.
Si OpenAI directo también falla, guarda:
- endpoint y base URL
- model name
- request id o response headers
- organization y project
- verification state
- timestamp con timezone
- región, red o proxy
- request reproducible mínimo
Ese paquete vale más que una captura aislada. Permite decidir si el dueño es Codex, OpenAI API, proveedor, red o acceso.
Después de que Status quede resuelto
Si OpenAI Status ya está resolved pero Codex sigue mostrando el error, usa una escalera corta:
- Reintenta el mismo task una vez.
- Abre una sesión nueva o refresca auth.
- Actualiza Codex CLI / app.
- Ejecuta la prueba directa de Image API desde la misma red.
- Si usas proveedor, revisa model list y base URL aparte.
- Abre ticket con minimal repro y request IDs.
Detente cuando una superficie pase. Si OpenAI directo pasa y provider falla, el proveedor es el owner. Si una sesión nueva de Codex pasa, era session/route state. Si OpenAI directo devuelve access error, vuelve a org/project.
Preguntas frecuentes
¿gpt-image-2 es un modelo real de OpenAI?
Sí. La documentación de generación de imágenes de OpenAI lo enumera en este run. Un mensaje de Codex no demuestra por sí solo que el modelo no exista.
¿Debo renombrar gpt-image-2 a otro modelo?
No como primera acción. Cambia el nombre solo si la ruta que usas documenta otro modelo soportado o alias.
La API directa funciona pero Codex falla
Entonces tu route de aplicación probablemente no es el primer dueño. Refresca Codex, reintenta con estado estable y conserva el éxito directo como evidencia.
El proveedor devuelve HTTP 400 o model_not_found
Revisa lista de modelos, base URL, endpoint, billing y access upstream del proveedor. Si OpenAI directo funciona, trátalo como problema de cobertura o mapping del proveedor.
¿Un plan ChatGPT o Codex garantiza Image API access?
No. ChatGPT product access, Codex tool y Platform API key son superficies distintas.
¿Qué evidencia debo guardar?
Guarda error exacto, surface, model name, base URL, endpoint, org/project, timestamp, request id, status state y minimal reproduction.