Selected model is at capacity: soluciones en Codex y límites de uso

«Selected model is at capacity» es un error que Codex clasifica como sobrecarga del servidor. Comprobamos la correspondencia del mensaje con el código público de OpenAI y encontramos el mismo mensaje completo junto a serverOverloaded en el historial de ejecución de este equipo. Conviene distinguirlo del agotamiento del cupo de uso o de un fallo del PC. Sin embargo, ni la información pública ni los registros del equipo permitieron determinar qué causó la sobrecarga.

Selected model is at capacity. Please try a different model.

¿Qué ocurre? Qué muestran los registros oficiales

El mensaje indica que el modelo seleccionado ha alcanzado su capacidad y pide probar otro. No hay fundamento para interpretar «capacity» como la memoria o el espacio en disco de tu PC. La página oficial de estado de OpenAI registra incidencias del servicio que muestran este mensaje.

Estos dos registros demuestran que el mismo mensaje puede aparecer durante incidencias del servicio y que cambiar de modelo no siempre ayuda. El número de incidencias publicadas no permite determinar la frecuencia del error ni demuestra que tu error tuviera la misma causa que una incidencia anterior. Las fechas siguen las páginas oficiales; no hemos convertido sus horas a la hora estándar de Japón.

Ninguno de los dos registros publica una causa raíz, como una escasez concreta de hardware o un fallo al cambiar de cuenta. Afirmaciones como «faltan GPU» o «la autenticación de Pro está fallando» van más allá de la información comprobada. Consultamos las fuentes oficiales originales el 1 de octubre de 2026 y distinguimos los hechos establecidos de nuestras recomendaciones.

Diferencias frente a los límites de uso, 401 y thread not found

Todos estos problemas pueden parecer una interrupción del trabajo, pero requieren comprobaciones distintas. Ante un error de capacidad, empieza por comprobar tanto el mensaje completo en pantalla como tu estado de uso. En una misma cuenta pueden producirse varios tipos de problemas.

Consulta el cupo restante en la pantalla de uso

La guía de precios y uso de OpenAI remite al panel de uso para comprobar los límites actuales. Durante una sesión de Codex CLI también puedes usar /status. Consultarlo inmediatamente después del error facilita compararlo con el cupo que quedaba en ese momento.

La guía oficial también explica que un trabajo ya en curso puede continuar bajo las restricciones de uso razonable aunque se alcance un límite durante el procesamiento. Por tanto, un error seguido de un informe de finalización no permite establecer por sí solo si se alcanzó un límite. A la inversa, puede haber una incidencia del servicio aunque quede mucho cupo. Consulta nuestra comparativa de planes ChatGPT Pro para conocer los cupos incluidos y los créditos adicionales.

Ante un error 401, comprueba primero cómo has iniciado sesión

La guía de autenticación de Codex distingue entre iniciar sesión con ChatGPT y hacerlo con una clave de API. En la aplicación de escritorio, el menú del perfil muestra la cuenta activa o el estado de la clave de API. En la CLI, usa codex login status.

Aunque aparezca «Incorrect API key» cuando has iniciado sesión con ChatGPT, esa pantalla no demuestra por sí sola que hayas configurado una clave incorrecta. Identificar qué credenciales se rechazaron requiere una investigación adicional. Un error de capacidad no justifica cerrar sesión de inmediato ni eliminar archivos de autenticación. Usar una clave de API genera cargos ordinarios de API separados de tu suscripción a ChatGPT.

Si el mensaje es thread not found, consulta nuestra investigación y guía de resolución del error «thread not found» de Codex. Los errores anteriores de autenticación o de chat en el mismo PC no establecen una relación causal con el error de capacidad actual.

Distingue los errores HTTP 503 de la API del mensaje de la aplicación

La guía de códigos de error de la API de OpenAI explica HTTP 503, service_unavailable_error y server_is_overloaded como indicadores de sobrecarga temporal del modelo. HTTP 429 incluye errores de frecuencia de solicitudes o límites de uso, mientras que HTTP 401 se refiere a la autenticación.

Pasos para retomar el trabajo

Estas recomendaciones se basan en registros oficiales de incidencias, guías de uso y documentación general de resolución de problemas. No se publican como una solución garantizada específicamente para este error.

1. Guarda tu solicitud y el último trabajo completado

Si el texto de la solicitud sin enviar sigue visible, cópialo y conserva el último informe de finalización o el estado de los archivos modificados. Antes de cerrar o sustituir el chat, registra qué pediste y cuánto se terminó. Así será más fácil retomarlo.

Un mensaje de error por sí solo no demuestra que no se editaran archivos ni se ejecutaran comandos. En un desarrollo con Git, revisa las diferencias o ejecuta git status antes de pedir de nuevo el mismo cambio. Si el trabajo implica publicar, enviar mensajes o comprar, no repitas la instrucción sin comprobar primero su resultado.

2. Espera un poco y consulta la página oficial de estado

Abre OpenAI Status y comprueba si hay incidencias que afecten a Codex o a la selección de modelos. Compara la hora de tu error con el intervalo de la incidencia, en vez de mirar solo su estado actual. Una incidencia pasada con el mismo nombre no significa que siga ocurriendo.

Para la sobrecarga de la API, las instrucciones oficiales indican esperar como mínimo el tiempo especificado por Retry-After, si aparece, o aumentar el intervalo entre reintentos si no aparece. No pudimos verificar un número fijo de segundos que los usuarios de la aplicación deban esperar cuando no se muestra un plazo. Recomendamos esperar un poco antes de reintentar, en lugar de enviar solicitudes repetidamente en rápida sucesión. Durante una incidencia registrada, consulta las actualizaciones oficiales de recuperación.

La página de estado presenta información agregada. Puede no reflejar por completo la situación de una cuenta o un modelo concretos. Que no figure una incidencia no demuestra que tu PC esté averiado.

3. Comprueba el uso y considera otro modelo si el trabajo urge

Comprueba tu cupo restante y la hora de restablecimiento. Si se informa expresamente de un límite de uso, sigue ese aviso al decidir qué hacer. No consideres la compra de créditos adicionales ni un restablecimiento de pago como solución cuando el único mensaje sea el error de capacidad. Recuperar tu propio cupo y que el modelo pueda aceptar solicitudes son cuestiones distintas.

La guía oficial de selección de modelos explica que los controles de modelo y esfuerzo de razonamiento de la aplicación de escritorio están debajo del campo de entrada. En la CLI interactiva, usa /model. Los modelos disponibles varían según la cuenta, el cliente y otros factores; no des por disponible uno que no aparece en tu interfaz.

Cambiar de modelo puede alterar el carácter de las respuestas y el consumo del cupo. No hay fundamento para elegir siempre el modelo de mayor gama con el fin de evitar errores de capacidad. Al transferir trabajos complejos de implementación o diseño, revisa el nuevo resultado mediante diferencias y pruebas. Nuestra comparativa de generaciones de GPT Sol y guía de selección aporta contexto adicional.

4. Investiga por separado la respuesta de la aplicación si está bloqueada

Distingue un error de capacidad de la falta de respuesta del campo de entrada, del terminal o de la interfaz. Para los chats que parecen atascados, la guía oficial de resolución de problemas recomienda comprobar si hay aprobaciones pendientes, probar el terminal con un comando básico e intentar una solicitud pequeña en un chat nuevo.

Si el terminal sigue bloqueado, la guía recomienda esperar a que terminen los chats activos antes de reiniciar la aplicación. Esto aborda una falta de respuesta general; no afirma que reiniciar resuelva una falta de capacidad en el servidor. Comprueba primero el estado de los demás chats que sigan ejecutándose.

Si retomas el trabajo en un chat nuevo, indica brevemente el objetivo, la carpeta de trabajo, los cambios completados y las tareas pendientes. No envíes solo «continúa» suponiendo que toda la conversación anterior está disponible. Un chat nuevo utiliza el mismo servicio, por lo que no garantiza evitar el error de capacidad.

Qué registrar si vuelve a ocurrir

Si el error se repite, conserva pruebas que faciliten investigarlo más adelante. Registrarlas antes de cambiar repetidamente la configuración aclara las condiciones del fallo.

Según los registros disponibles, quizá no puedas confirmar que el modelo seleccionado en la configuración fuera el utilizado realmente en la solicitud fallida. Si solo registraste la selección visible, describe únicamente esa prueba. Del mismo modo, que el servicio se recupere justo después de cambiar de modelo no demuestra que el cambio lo solucionara: el servicio pudo recuperarse al mismo tiempo.

La guía oficial explica cómo enviar comentarios introduciendo / en el campo de mensajes. Al hacerlo desde un chat existente, puedes elegir si compartes la conversación. Elimina claves de API, direcciones de correo, conversaciones privadas e información interna de la empresa de los registros o capturas que envíes. No necesitas publicar los valores de las claves ni los propios archivos de autenticación.

Un informe con fecha, modelo, mensaje exacto y cupo restante mostrado es más útil que decir simplemente «no deja de fallar». Un código HTTP o identificador de solicitud, si se ha obtenido, puede ayudar al soporte, pero no rellenes los datos que faltan con suposiciones.

Qué encontramos en este equipo y qué sigue sin saberse

Después de que un usuario notificara errores repetidos con capturas, AI Arte encargó a Codex en este equipo una investigación de solo lectura del uso y los registros locales el 1 de octubre de 2026. La versión del paquete de la aplicación de Windows era 26.928.3736.0. No verificamos que esa misma versión estuviera instalada cuando ocurrieron los errores.

La búsqueda inicial no encontró el error en 32.737 registros de la base de datos ordinaria de logs, 15 archivos de logs de escritorio ni 143 archivos de sesión actualizados. Después de que un lector cuestionara las conclusiones, comprobamos otras ubicaciones y encontramos registros de fallos en una base de datos separada de historial de ejecución. El alcance de la búsqueda inicial era insuficiente.

En la investigación posterior, 35 de los 6.781 turnos del historial de ejecución eran fallos. En todo el período registrado, 13 contenían el mismo mensaje completo y codexErrorInfo: serverOverloaded. De ellos, 12 ocurrieron en cinco chats entre el 30 de septiembre de 2026 a las 22:10:01 y el 1 de octubre a las 00:24:55 (JST). El chat donde el usuario adjuntó las capturas del error también contenía cuatro fallos del 30 de septiembre, a las 22:15:06, 22:57:58, 23:12:31 y 23:24:38, con mensajes y clasificaciones coincidentes. Estas horas son las de finalización registradas de los turnos fallidos, no las de las capturas. Describen los registros de este equipo, no una tasa de error de todos los usuarios.

La Codex CLI incluida en la aplicación era la versión 0.159.2. En las definiciones de errores de la etiqueta pública correspondiente, el mensaje completo corresponde a ServerOverloaded, clasificado por separado del agotamiento del cupo de uso. El código de procesamiento del flujo convierte server_is_overloaded en un error de sobrecarga, y el código de conversión para la visualización lo vincula al mensaje completo del inicio del artículo. También existe una ruta que convierte respuestas HTTP 503 con el mismo código de error, pero los errores pueden llegar dentro de un flujo. Por tanto, el mensaje mostrado no demuestra que la respuesta fuera HTTP 503.

Lo establecido es que los fallos se clasificaron y almacenaron como sobrecarga del servidor. Los registros no indican si se debieron a una escasez real de GPU, al enrutamiento de solicitudes o a problemas de control de capacidad. Los detalles adicionales de los cuatro fallos estaban vacíos y no se registró ningún código HTTP. Durante la investigación inicial quedaba el 31% del cupo semanal y se permitía el uso ordinario. Ese no era el cupo en el momento de los errores; tampoco se estableció el modelo utilizado realmente en esas solicitudes fallidas.

En cuanto a los errores de autenticación, el informe oficial de causa raíz de otra incidencia del 25 de septiembre explica que la detección errónea y la invalidación de credenciales internas del servicio provocaron errores 401 y 502 en Codex con sesión iniciada mediante ChatGPT. Esto no establece la causa de los errores de sobrecarga examinados aquí. No confundas una incidencia interna de autenticación explicada oficialmente con estos errores de sobrecarga.

En esta investigación no cambiamos modelos ni suscripciones, no usamos restablecimientos de pago ni eliminamos credenciales. Tampoco enviamos deliberadamente solicitudes rápidas y repetidas para reproducir el problema, así que no tenemos una comparación experimental de qué acciones restablecen el servicio. Distinguimos los ejemplos de incidencias verificados oficialmente de las observaciones en este único equipo.

Resumen: identifica el error antes de actuar

Si aparece «Selected model is at capacity», guarda tu solicitud, espera un poco y comprueba las incidencias y el uso. Si el trabajo urge, puedes considerar otro modelo disponible, pero algunas incidencias afectan a varios. El error de capacidad por sí solo no justifica gastar más, comprar un restablecimiento de pago ni eliminar credenciales.

Comprueba la autenticación ante un 401, el estado del chat ante thread not found y el estado de uso ante un aviso de límite. Registrar la hora, el mensaje completo, el modelo y el cupo restante cuando se repita el error ayuda más a la siguiente investigación que cambiar la configuración sin conocer la causa.

Preguntas frecuentes

¿Puede ocurrir con una suscripción Pro?

El usuario de este artículo notificó el mismo mensaje con una suscripción Pro. Sin embargo, un caso no permite establecer tasas de incidencia por plan. Los registros oficiales no afirman que Pro esté exento. Comprueba el cupo restante de la suscripción por separado de si el modelo puede aceptar trabajo en ese momento.

¿Se soluciona con créditos adicionales o un restablecimiento de pago?

No encontramos pruebas oficiales de que estas acciones resuelvan este error de capacidad. Los créditos adicionales y mecanismos similares afectan a tu propio cupo. Comprueba primero si realmente has alcanzado un límite y no confundas recuperar el cupo con recuperarse de un error de capacidad.

¿Por qué sigue ocurriendo después de cambiar de modelo?

Los registros oficiales describen el mismo mensaje en varios modelos. Que aparezca con otro modelo no demuestra por sí solo un fallo del PC o de la cuenta. Comprueba las incidencias y el cupo restante, y registra los resultados de los reintentos. La documentación pública no establece un modelo que garantice evitar el error.

¿Debo reiniciar la aplicación o abrir un chat nuevo?

No pudimos establecer que ninguna de las dos acciones sea necesaria. Pueden ayudar a investigar una aplicación o terminal que no responde, pero no garantizan resolver un problema de capacidad del servicio. Comprueba el resto del trabajo en curso y conserva tu solicitud, los cambios y las tareas pendientes antes de decidir.