Actualización — verano de 2026: dejó de funcionarme
Para el verano de 2026 este flujo dejó de funcionarme de forma fiable. En mi cuenta desapareció el contador de uso de 5 horas y quedó visible el límite semanal. En la práctica, eso eliminó la ventana de reinicio corta alrededor de la cual había organizado este método.
El cambio más importante fue el comportamiento de las tareas largas. Cuando una tarea grande de Codex llegaba al final de mi límite semanal, vi que el trabajo se detenía en lugar de seguir hasta terminar. Por eso mi antigua regla de “lanzar la tarea más pesada en el último 3–5 %” perdió gran parte de su utilidad: ya no podía contar con que una tarea en curso sobreviviera al final del límite semanal.
Quiero separar con cuidado mi observación de una regla oficial del producto. Puedo confirmar lo que vi en mi cuenta y mi flujo de trabajo, pero no puedo demostrar que OpenAI eliminara de forma permanente la ventana de 5 horas para todos los usuarios. De hecho, la documentación actual de Codex de OpenAI sigue mencionando ventanas de 5 horas y semanales, y dice que un turno activo puede continuar tras alcanzar un límite, sujeto a condiciones de uso justo. Por eso presento lo ocurrido en el verano de 2026 como un cambio real que experimenté, no como una regla universal para todas las cuentas.
El resto del artículo se conserva como descripción del flujo que sí me funcionaba antes de ese cambio. Esta actualización sustituye las recomendaciones en presente del texto original.
Cuando el contador de uso de Codex de mi plan ChatGPT Plus baja aproximadamente al 3–5 %, dejo de gastar lo que queda en prompts pequeños. Hago lo contrario: inicio la tarea de ingeniería más grande que ya tengo preparada.
En mi caso suele ser una migración completa a TypeScript, una limpieza de ESLint en todo el repositorio, una revisión profunda de bugs en una codebase o un gran refactor estructural. A menudo tengo varios proyectos preparados de antemano, de modo que el último tramo de uso puede ir a la tarea pesada que realmente esté lista.
La razón es una observación repetida. Más de una vez he iniciado trabajo importante cerca del final del límite visible y he visto a Codex seguir trabajando después de que ese límite pareciera agotado. En algunos casos la tarea avanzó lo suficiente como para terminar. Ocurrió las suficientes veces para cambiar mi forma de planificar, pero no para convertirlo en una garantía del producto.
La observación que cambió mi workflow
La reacción natural cerca de un límite es volverse conservador: gastar el último margen en solicitudes pequeñas porque una tarea grande podría quedar interrumpida. Yo ahora trato ese 3–5 % final de otra manera. Para mí es una ventana de lanzamiento.
La pregunta útil ya no es «¿cuántos prompts pequeños me quedan?», sino «¿cuál es la tarea preparada más valiosa que puedo iniciar mientras todavía tengo uso incluido?».
Esto solo funciona porque el proyecto ya está listo y la tarea está claramente definida. No uso esos últimos puntos para descubrir qué hay que hacer. Los uso para empezar a ejecutar.
Una aclaración importante sobre el nombre y los límites
Al principio llamé a esto “Codex Plus”, pero es una abreviatura informal, no el nombre oficial del producto. OpenAI describe Codex como una función incluida con ChatGPT Plus. Corregirlo evita dar a entender que Codex Plus es un plan o producto separado.
La documentación actual de OpenAI sobre el uso de Codex también explica que el consumo depende del tamaño y la complejidad del trabajo, del modelo y de dónde se ejecuta la tarea, y documenta ventanas de uso que incluyen una de 5 horas y otra semanal. Por eso, cuando digo «3–5 %», me refiero al porcentaje restante que muestra la interfaz de uso, no al 3–5 % del tiempo real, de los tokens ni de una cantidad garantizada de trabajo.
Los usuarios elegibles de Plus también pueden ampliar el uso de Codex con créditos después de agotar lo incluido. Eso no invalida este workflow; simplemente deja claro el alcance. Estoy hablando de cómo reparto mi uso incluido, no de un método para saltarse una cuota.
Qué lanzo en el último 3–5 %
Las tareas que suelo reservar para ese momento son operaciones de ingeniería amplias:
- migraciones completas a TypeScript
- limpieza de ESLint en todo el repositorio
- revisiones profundas de bugs en codebases grandes
- grandes refactors estructurales
Prefiero arrancar uno de estos trabajos como una pieza sustancial en lugar de repartir el margen restante entre una secuencia de peticiones de poco valor. En este tipo de tareas, un repositorio preparado y un objetivo claro importan más que una formulación especialmente ingeniosa del prompt.
Tener varios proyectos preparados ayuda por la misma razón. Si un repositorio todavía necesita decisiones o configuración, no gasto la última ventana en prepararlo; puedo empezar en otro proyecto que ya esté listo.
La preparación es la restricción real
El truco no es «esperar al 3 % y pegar un prompt enorme». Si la tarea es ambigua, un presupuesto limitado puede desaparecer en exploración, aclaraciones o trabajo en la dirección equivocada. Mi patrón solo es útil cuando el proyecto está listo para ejecutarse y la tarea está bien acotada.
Para quien quiera probar algo parecido, conviene hacer explícitos el alcance, lo que debe cambiar y lo que no, las restricciones, cómo se validará el resultado y qué salida se espera del agente. Son salvaguardas de ingeniería generales, no una prueba de que un formato concreto de prompt desbloquee más uso.
Esto también facilita reanudar una tarea grande si el límite realmente la interrumpe. Una migración o revisión parcial se retoma mucho mejor cuando el alcance y los criterios de validación estaban claros desde el principio.
Lo que puedo confirmar — y lo que no
Lo que puedo confirmar por experiencia propia es muy concreto: en varias ocasiones, una tarea que ya había iniciado siguió progresando después de que el límite visible pareciera agotado y, a veces, llegó a completarse.
Lo que no puedo confirmar es el mecanismo. No puedo afirmar que OpenAI dé a toda tarea en curso un período de gracia oculto, que el último 3–5 % garantice terminar un trabajo de cualquier tamaño, que el comportamiento sea estable ni que sirva para eludir el límite. La documentación de OpenAI no promete nada de eso.
La distinción importa. Planifico teniendo en cuenta un comportamiento que he visto varias veces, pero no dependo de él. Si la tarea se detiene al llegar al límite, no significa que algo haya fallado. La estrategia sigue cumpliendo su objetivo si utilicé el margen incluido en algo más importante que unos cuantos prompts pequeños.
Una tarea terminada no es una tarea verificada
Cuanto mayor es el trabajo, más importante es otra distinción: terminar no significa estar correcto. Una migración a TypeScript que compila no demuestra que el comportamiento en runtime sea correcto. Un ESLint limpio no demuestra la lógica de negocio. Que una revisión marque un patrón sospechoso no confirma un bug. Incluso un refactor con tests verdes solo es tan fiable como los tests y checks que lo cubren.
Este workflow cambia cuándo inicio el trabajo. No reduce el estándar de validación. Los cambios agentic grandes siguen necesitando controles acordes al riesgo: revisión del diff, typecheck, tests, build, comprobaciones en runtime u otra verificación específica del proyecto.
Cuándo este patrón encaja mal
No considero que cualquier tarea grande sea adecuada para el final del límite. El enfoque es más débil si el trabajo aún no está claro, requiere decisiones de producto frecuentes, implica operaciones destructivas o sensibles en producción, o deja el repositorio en un estado peligroso si se corta a mitad.
En esos casos suele ser mejor una tarea más pequeña y bien acotada o una ventana de uso nueva. El objetivo no es hacer el último prompt más espectacular, sino invertir el uso incluido escaso en trabajo que pueda producir progreso útil de forma segura.
Mi regla actual
Cuando mi uso incluido de Codex en ChatGPT Plus baja aproximadamente al 3–5 %, dejo de optimizar por número de prompts restantes. Miro los proyectos que preparé y comienzo la tarea de ingeniería más pesada, claramente acotada y que realmente merece la pena.
Si Codex sigue trabajando después de que el contador visible llegue a cero, lo trato como un comportamiento útil que he observado, no como un derecho. Si se detiene, no me sorprende. No encontré una forma de saltarme el límite. Encontré una forma mejor de decidir qué empezar antes de alcanzarlo.