Codex Selected model is at capacity: cómo solucionarlo

1. Cambia a un modelo disponible

Usa los controles oficiales de selección de tu cliente:

• Aplicación de escritorio: abre el control de modelo bajo el cuadro de entrada y elige una alternativa disponible.
• CLI interactiva: escribe /model y selecciona una opción ofrecida en esa sesión.
• Extensión del IDE: usa el selector bajo el cuadro de entrada cuando esté disponible.

Comprueba el modelo elegido y envía un siguiente paso pequeño. La alternativa debe servir para la tarea; ningún modelo concreto garantiza capacidad permanente. Reducir solo el esfuerzo de razonamiento no equivale a cambiar de modelo.

Las opciones dependen del plan, espacio de trabajo, autenticación y cliente. Si falta un modelo, sigue las comprobaciones de acceso. No traslades estos controles a todos los flujos en la nube: el selector local no cambia el modelo predeterminado de Codex cloud.

2. Si necesitas el original, espera

Detén los envíos repetidos y prueba un siguiente paso pequeño más tarde. Respeta cualquier espera indicada en un error más detallado. Este texto no promete recuperación en cinco minutos, cinco horas ni con el próximo reinicio semanal.

Mientras esperas, revisa cambios locales, ejecuta pruebas existentes o prepara la siguiente tarea. Un temporizador personal no mide la capacidad del modelo ni determina cuándo volverá a aceptar solicitudes.

3. ¿Por qué ocurre si todavía tengo cuota?

La cuota restante de la cuenta y la capacidad disponible del modelo son comprobaciones diferentes. Consulta el uso de Codex para verificar tus límites. No supongas que comprar créditos, usar un reinicio o abrir un chat devuelve capacidad al modelo.

La referencia de errores de OpenAI API distingue sobrecarga temporal, frecuencia de solicitudes y cuota. Sin embargo, este mensaje de Codex no determina por sí solo el estado HTTP. Si el error completo indica 429, sigue el diagnóstico de 429; si confirma cuota agotada, usa los pasos de recuperación.

4. Continúa desde el progreso verificado

Conserva la conversación si tu cliente permite cambiar allí de modelo. Antes de reenviar trabajo, comprueba archivos modificados, resultados de comandos y acciones externas terminadas. Un fallo de respuesta no significa que se haya deshecho el trabajo anterior, y cambiar de modelo no garantiza reanudar automáticamente en el paso fallido.

Puedes continuar con una instrucción como esta:

Revisa los archivos actuales y los pasos completados. Continúa solo el trabajo pendiente. Antes de repetir una acción externa, verifica si el intento anterior ya tuvo éxito.

Si necesitas otra conversación, lleva el objetivo, las restricciones, los archivos pertinentes, el progreso verificado y el siguiente paso. No presupongas que heredará el contexto anterior.

5. Si fallan varios modelos

Confirma cuenta, espacio de trabajo, versión del cliente y autenticación. Con una clave de API o pasarela propia, identifica qué servicio devolvió el error y revisa el acceso y el estado de ese proveedor. El reinicio de la suscripción no diagnostica un proyecto de API ni una pasarela.

Consulta la página de estado de OpenAI para detectar incidentes más amplios. Un estado operativo no descarta un fallo de una cuenta o modelo concretos. No hagas reintentos continuos ni restablezcas tu configuración local basándote solo en este mensaje.

Qué registrar si persiste

Guarda el error exacto, modelo, cliente y versión, fecha y zona horaria, autenticación, identificador de solicitud si existe, y si falla también una petición pequeña u otra alternativa. Elimina credenciales y contenido privado antes de compartirlo con el soporte correspondiente. No añadas un código HTTP supuesto ni una hora de recuperación inventada.