Usage Limits on KnightLi Blog

Por qué se reinician de repente los límites de Codex: historial y fuentes

Sun, 17 May 2026 08:36:15 +0800

Los usuarios de Codex a veces se encuentran con algo extraño: sus usage limits vuelven a estar disponibles aunque todavía no haya llegado su hora normal de reset. Este tipo de reinicio sin aviso no es nuevo, y no significa necesariamente que las reglas de cuota se hayan vuelto más generosas de forma permanente. Puede deberse a compensación por incidentes, promociones de producto, hitos de crecimiento o a un reset interno que solo afecta a ciertas ventanas o estados de cuenta.

La captura proviene de una publicación en X de Tibo Sottiaux (@thsottiaux), responsable del equipo de OpenAI Codex. Para quienes siguen de cerca sus límites, la parte clave no es el detalle del modelo, sino que Tibo dijo que resetearía los usage limits esa misma noche. Por el contexto, se trató de un reset compensatorio, no de una renovación normal del ciclo.

Resumen rápido

Los reinicios repentinos de límites en Codex suelen entrar en estas categorías:

Compensación por incidente: un problema en Codex o en un modelo hace que los usuarios gasten cuota de forma anormal, y OpenAI reinicia límites para compensar.
Lanzamiento o promoción: un nuevo modelo, cliente o función se acompaña de más capacidad temporal o de un reset.
Hito de crecimiento: OpenAI reinicia o aumenta límites cuando Codex alcanza cierto nivel de adopción.
Cambio de política interna: solo se resetean algunas ventanas de cuota o ciertos estados de cuenta, y la UI no siempre explica el alcance.

El malentendido más común es creer que “reset” significa que todas las ventanas visibles se han recuperado. En la práctica, Codex puede tener ventanas cortas, weekly limit, pesos de consumo por modelo y reglas por plan. Un reset especial puede afectar solo a una parte del sistema.

Qué muestra esta captura

La captura muestra que Tibo publicó una actualización el 15 de mayo de 2026, diciendo que el equipo seguiría monitoreando y que reiniciaría los usage limits esa noche. La publicación cita un mensaje anterior en el que el equipo decía estar investigando reportes de algunos usuarios.

Para el usuario, hay tres ideas prácticas:

No fue el ciclo normal de reset de cada cuenta; fue un reset activo del equipo.
El reset tuvo un contexto concreto y no fue un aumento permanente de límites.
La expresión “usage limits” no aclara por sí sola si incluía tanto la ventana de 5 horas como el weekly limit.

Por eso, si tu cuota se recuperó, conviene tratarlo primero como un reset event especial, no como prueba de que las reglas futuras cambiaron.

Por qué los resets de Codex pueden parecer inesperados

Los límites de Codex no funcionan simplemente como “se actualizan todos los días a una hora fija”. El backend puede rastrear varias cosas a la vez:

Ventanas cortas de uso, por ejemplo de unas horas.
Límites semanales o de periodos más largos.
Pesos de consumo distintos para diferentes modelos.
Entradas distintas, como Codex local, Cloud Tasks, IDE y CLI.
Diferencias entre Plus, Pro, Business y Team.
Si una cuenta es elegible para un reset especial.

Cuando OpenAI aplica un reset especial, la UI puede no decir con claridad si se trata de una renovación normal o de una compensación. Si solo se reinicia la ventana corta, algunos usuarios pueden asumir que el weekly limit también debería recuperarse. Si el weekly no cambia, parece que el reset falló.

En el repositorio de OpenAI Codex en GitHub también se planteó este problema de transparencia: el mensaje público decía que se habían reseteado los Codex rate limits, pero la UI no mostraba claramente qué ventanas se habían reiniciado, si el weekly limit estaba incluido o si todos los planes de pago se veían afectados de la misma forma.

Patrones históricos

1. Febrero de 2026: periodo de lanzamiento y capacidad temporal

Durante el periodo de promoción de la app de escritorio de Codex y GPT-5.3-Codex, usuarios de la comunidad hablaron de usage limit reset y de 2x rate limits temporales. En Reddit, algunos mencionaron que el lanzamiento de Codex app incluyó 2x rate limits por tiempo limitado y un usage limit reset.

Este tipo de reset parece una acción de lanzamiento: animar a más usuarios a probar el nuevo cliente, modelo o flujo de trabajo.

2. Marzo de 2026: resets aleatorios y consumo anormal

Alrededor de marzo, la comunidad discutió varias veces comportamientos como “random usage reset” y “weekly limit reset daily”. Algunos usuarios dijeron que su weekly limit se recuperó antes de tiempo, mientras que otros lo relacionaron con nuevos modelos de Codex, bloqueos de seguridad, consumo anormal de cuota o correcciones de bugs.

Estas discusiones no son anuncios oficiales, pero muestran que los usuarios ya habían observado recuperaciones fuera del calendario normal.

3. Abril de 2026: hitos de crecimiento y resets para planes de pago

A finales de abril, algunos reportes públicos indicaron que Codex alcanzó 3 millones de usuarios activos semanales y que OpenAI reseteó rate limits, con la intención de dar más margen en futuros hitos de crecimiento.

Un issue de GitHub también citó una publicación de Tibo del 28 de abril, donde decía que había reseteado los Codex rate limits para planes de pago tras una “good week”, para que los usuarios pudieran crear más con GPT-5.5. Ese mismo issue señalaba que la UI no explicaba con claridad qué ventanas se habían reseteado ni si el weekly limit estaba incluido.

Esto muestra por qué los resets vinculados a actividad o crecimiento también pueden confundir: los usuarios oyen un mensaje amplio, pero ven resultados distintos en su cuenta.

4. Mayo de 2026: reset compensatorio

La captura de este artículo es un ejemplo más claro de reset compensatorio. Tibo dijo que el equipo había encontrado problemas y que resetearía los usage limits esa noche. OpenAI Status también registró errores elevados y latencia degradada relacionados con Codex el 13 de mayo de 2026.

Para usuarios normales, lo importante no es el detalle exacto del modelo. La lección es que, cuando un problema del servicio hace que los usuarios quemen cuota de forma anormal, OpenAI puede compensar con un reset especial.

Cómo interpretar un reset repentino

Si tu cuota de Codex se recupera de repente, revisa en este orden:

Comprueba si llegó tu hora normal de reset.
Revisa OpenAI Status para ver incidentes de Codex, errores de modelo, latencia o rendimiento degradado.
Busca actualizaciones de Tibo, cuentas oficiales de OpenAI o issues de Codex en GitHub.
Mira si la comunidad reporta el mismo reset, consumo anormal o confusión con el weekly limit.
Separa las ventanas cortas del weekly limit; no asumas que siempre se mueven juntas.

Si es compensación oficial por un incidente, normalmente habrá una entrada en la página de estado, un anuncio del equipo o muchos reportes concentrados. Si solo es una actualización parcial del backend, puede que no haya anuncio claro.

Cómo evaluar la fiabilidad de las fuentes

Conviene separar las fuentes por nivel de fiabilidad:

OpenAI Status: mejor para confirmar incidentes, tasas de error, latencia y tiempos de recuperación.
Tibo / cuentas oficiales de OpenAI: útiles para confirmar resets especiales, compensaciones o promociones.
OpenAI Codex GitHub issues: útiles para ver reportes de usuarios sobre UI, ventanas de cuota y comportamiento real del producto.
Reddit / X: útiles para detectar patrones amplios entre usuarios, pero no son confirmación oficial.
Noticias o blogs de terceros: útiles para completar la línea temporal, pero conviene contrastarlos con fuentes originales.

Al escribir o tomar decisiones, conviene mantener separadas estas capas. “OpenAI Status registró un incidente” es una señal oficial. “Usuarios de Reddit reportaron resets aleatorios” es una observación de la comunidad. “Un GitHub issue señaló falta de transparencia en la UI” es un problema reportado por un usuario.

Resumen

Un reset repentino de usage limits en Codex no suele ser simplemente “cuota gratis”. Puede venir de compensación por incidentes, promociones de lanzamiento, actividades de crecimiento o cambios internos. Lo confuso es que Codex tiene varias ventanas de cuota, y un reset especial no siempre las incluye todas. La UI tampoco siempre muestra claramente el reset scope.

Cuando ocurra, revisa primero la cuota real en el cliente, luego compárala con OpenAI Status, publicaciones de Tibo, GitHub issues de Codex y reportes de la comunidad. No asumas que un reset cambia las reglas a largo plazo, ni que weekly limit, ventanas cortas y todos los planes se recuperan al mismo tiempo.

Referencias:

Cómo funcionan los límites de uso de Codex: límites de 5 horas, límites semanales y créditos

Wed, 15 Apr 2026 22:50:00 +0800

Cuando la gente mira por primera vez los límites de uso de Codex, es fácil asumir que el 5-hour limit es un saldo de corto plazo y que el weekly limit solo empieza a bajar cuando se agota la cuota de 5 horas.

No funciona así. Codex se entiende mejor como un sistema que revisa varias ventanas de límite al mismo tiempo: una ventana corta evita el uso en ráfaga, mientras la ventana semanal controla el uso total de la semana. Una solicitud de Codex normalmente cuenta contra ambas.

Así que esta situación suele ser normal:

1
2

5-hour quota still has plenty left
but weekly quota has already decreased

01 Versión corta

Puedes entender el uso de Codex con tres reglas:

El 5-hour limit y el weekly limit se aplican al mismo tiempo.
Si se agota el límite semanal, normalmente no puedes seguir usando el mismo pool de cuota de suscripción aunque la cuota de 5 horas aún tenga margen.
Codex no se cobra por simple número de mensajes. El uso depende del modelo, tokens, complejidad de tarea, tamaño de contexto y ubicación de ejecución.

En pseudocódigo:

can_use_codex =
    five_hour_remaining > 0
    && weekly_remaining > 0
    && no other product policy is triggered

Cuando se reinicia la ventana de 5 horas, solo se restaura esa cuota. No restaura la cuota semanal. La cuota semanal se reinicia según su propio calendario, o puede que puedas comprar créditos extra en planes compatibles.

02 Por qué bajan ambas ventanas

Piensa en los límites de Codex como dos puertas:

Window	Purpose
5-hour window	Prevents high-frequency burst usage
Weekly window	Controls total weekly usage

Cada tarea de Codex crea uso real. Ese uso se refleja en las ventanas de rate limit relevantes.

No es:

1
2
3

Use 5-hour quota first
After the 5-hour quota runs out
Start using weekly quota

Se parece más a:

1
2
3

One Codex request
=> counts toward the 5-hour window
=> also counts toward the weekly window

Por eso el uso semanal puede bajar aunque la cuota de 5 horas no esté agotada.

03 Mira los créditos basados en tokens

OpenAI no publica una fórmula que permita a los usuarios reproducir exactamente el cargo de Codex. Lo público es la rate card, los factores principales y el precio de créditos por modelo.

A fecha de 2026-04-15, el modelo principal de la rate card de Codex es token-based credits. El uso se estima a partir de tokens de entrada, tokens de entrada cacheados y tokens de salida.

Ejemplos de tarifas oficiales:

Model	Input / 1M tokens	Cached input / 1M tokens	Output / 1M tokens
GPT-5.4	62.50 credits	6.250 credits	375 credits
GPT-5.4-Mini	18.75 credits	1.875 credits	113 credits
GPT-5.3-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.2-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.1-Codex-Max	31.25 credits	3.125 credits	250 credits
GPT-5.1-Codex-mini	6.25 credits	0.625 credits	50 credits

Una estimación aproximada es:

usage
~= input tokens / 1,000,000 * model input price
+ cached input tokens / 1,000,000 * model cached input price
+ output tokens / 1,000,000 * model output price

No es una fórmula exacta de facturación, pero explica la tendencia: la salida es cara, el contexto largo es caro y los modelos más potentes cuestan más. La rate card oficial también dice que Fast mode usa 2x créditos y que Code review usa precios de GPT-5.3-Codex.

04 No cuentes solo mensajes

Diez mensajes de Codex pueden consumir cantidades muy distintas.

Las tareas ligeras suelen ser más baratas:

Editar una función pequeña
Explicar un snippet corto
Escribir un párrafo breve
Hacer un cambio local en un archivo claramente especificado

Las tareas pesadas cuestan más:

Escanear una codebase grande
Ejecutar una sesión larga de agente
Bucles repetidos de leer, editar, probar y corregir
Generar mucho código o un informe largo
Usar tareas cloud
Activar fast mode

Así que el número de mensajes solo da una impresión aproximada. No refleja el uso real.

05 Tareas locales frente a tareas cloud

La ubicación de ejecución puede marcar una gran diferencia.

Una local task trabaja en tu workspace local: lee archivos, edita código y ejecuta comandos. Una cloud task se delega a un entorno cloud alojado, mejor para flujos más largos y automatizados.

Las tareas cloud suelen ser más caras porque implican:

Un entorno de ejecución alojado
Tareas más largas
Más llamadas a herramientas
Contexto más grande
Un bucle de automatización más completo

Para ediciones normales de código, limpieza de artículos o correcciones pequeñas, las tareas locales suelen ser más baratas. Usa tareas cloud cuando el trabajo realmente necesite ejecución alojada.

06 Por qué el uso semanal baja rápido

Si tu cuota de 5 horas apenas se mueve pero el uso semanal baja mucho, causas comunes incluyen:

Usaste tareas cloud.
Usaste un modelo más caro.
Activaste fast mode.
El contexto era grande, con muchos archivos o una conversación larga.
La salida fue larga, como mucho código, un informe extenso o análisis de logs.
La cadena de tareas fue larga: buscar, editar, probar, corregir y probar otra vez.
Tu script de cuota etiquetó mal las ventanas de límite.

Si lees campos desde algo como /backend-api/wham/usage, no confíes solo en etiquetas procesadas como five_hour% o weekly%. Revisa los campos raw JSON:

limit_window_seconds
percent_left
reset_at
bucket / feature name

Ventanas típicas:

limit_window_seconds = 18000
=> about 5 hours

limit_window_seconds = 604800
=> about 7 days

Si tu script etiqueta las ventanas al revés, la visualización de cuota será engañosa.

07 Cómo ahorrar cuota

Para hacer que la cuota semanal dure más:

Divide trabajos grandes en tareas más pequeñas.
Prefiere tareas locales cuando sea posible.
Indica a Codex las rutas relevantes para reducir escaneo innecesario.
Evita volcar logs enormes, archivos largos o contexto no relacionado.
Usa modelos mini más baratos para trabajo ligero.
Pide un plan antes de empezar una tarea larga.
Pide respuestas concisas cuando no necesites un informe largo.

Un modelo mental útil:

can continue using
= short window has quota
&& weekly window has quota

usage speed
= model price
* tokens
* output length
* task complexity
* execution location

No es matemática exacta de facturación, pero explica la mayoría del comportamiento de límites de uso de Codex.