Update — Summer 2026: this stopped working for me
By summer 2026, this workflow had stopped working reliably for me. The 5-hour usage counter disappeared from my account, while the weekly allowance remained. In practice, that removed the shorter reset window I had been timing this workflow around.
The more important change was what happened to long-running work. When a substantial Codex task reached the end of my weekly allowance, I saw the work stop instead of continuing far enough to finish. That made my old “start the heaviest task at the final 3–5%” rule much less useful: I could no longer count on an already-running task surviving the end of the weekly allowance.
I want to be precise about what I can prove. This is what I observed in my account and workflow; I cannot prove that OpenAI permanently removed the 5-hour window for every user. In fact, OpenAI’s current Codex documentation still refers to both 5-hour and weekly usage windows, and says an active turn can sometimes continue after a limit is reached, subject to fair-use limits. So I treat the summer 2026 behavior as a real product change I experienced, not as a universal rule I can document for every account.
The rest of this article is preserved as a description of the workflow that worked for me before that change. The update above supersedes the present-tense recommendation in the original text.
When the Codex usage counter on my ChatGPT Plus plan gets down to roughly 3–5%, I stop using the remaining allowance on tiny prompts. I do the opposite: I start the biggest engineering task I already have prepared.
In my case, that usually means a full TypeScript migration, repository-wide ESLint cleanup, a deep bug review across a codebase, or a large structural refactor. I often have several projects prepared in advance, so the final slice of usage can go to whichever heavy task is ready to run.
The reason is a repeated observation. More than once, I have started substantial work near the end of the visible limit and then watched Codex continue working after that limit appeared exhausted. Sometimes the task kept moving far enough to finish. That happened often enough to change how I schedule work, but it is important not to turn the observation into a product guarantee.
The observation that changed my workflow
The natural instinct near a usage limit is to become conservative: use the last bit on small requests because a large task might be interrupted. I now treat that final 3–5% differently. For me, it is a launch window.
The useful question is no longer, “How many small prompts can I still fit in?” It is, “What is the most valuable prepared task I can start while I still have included usage available?”
That only works because the project is already ready and the task is clearly defined. I am not using the final few percent to discover what should be done. I am using them to begin execution.
A terminology and limit caveat
I originally called this “Codex Plus,” but that is shorthand rather than the official product name. OpenAI describes Codex as included with ChatGPT Plus. That distinction is worth fixing because it avoids making Codex Plus sound like a separate plan or product.
OpenAI’s current Codex usage documentation also says that consumption varies with the size and complexity of the work, the model, and where the task runs. The product uses usage windows that include a 5-hour window and a weekly window. So when I say “3–5%,” I mean the remaining percentage shown by the usage interface. I do not mean 3–5% of wall-clock time, tokens, or a guaranteed amount of engineering work.
Eligible Plus users can also extend Codex usage with credits after included plan limits are reached. That does not invalidate this workflow; it just makes the boundary clearer. I am describing how I allocate my included usage, not a method for bypassing a quota.
What I launch in the final 3–5%
The tasks I tend to reserve for this moment are broad engineering operations:
- full TypeScript migrations
- repository-wide ESLint cleanup
- deep bug reviews across large codebases
- large structural refactors
These are the kinds of jobs I would rather start as one substantial piece of work than spend the remaining allowance on a sequence of low-value requests. They are also tasks where a prepared repository and a clear target matter more than clever prompt wording.
Having several projects ready is useful for the same reason. If one repository still needs decisions or setup, I do not have to waste the final window getting it ready; I can launch work in another project that is already prepared.
Preparation is the real constraint
The trick is not “wait until 3% and paste an enormous prompt.” If the task is ambiguous, a limited budget can disappear into exploration, clarification, or work in the wrong direction. My pattern is useful only when the project is ready for execution and the task itself is well scoped.
For developers trying a similar workflow, a practical preflight is to make the scope explicit: what should change, what should not change, what constraints matter, how the result should be validated, and what output you expect from the agent. Those are general engineering safeguards, not evidence that a particular prompt format unlocks more usage.
This also makes a large task easier to resume if the limit actually stops it. A partially completed migration or review is much easier to continue when the intended scope and validation criteria were clear from the beginning.
What I can confirm — and what I cannot
What I can confirm from my own use is narrow: on multiple occasions, a task that I had already started continued to make progress after the visible usage limit looked exhausted, and sometimes it completed.
What I cannot confirm is the mechanism. I cannot claim that OpenAI gives every running task a hidden grace period, that the final 3–5% is enough to finish an arbitrarily large job, that this behavior is stable, or that it is a way around the limit. OpenAI’s documentation does not promise any of those things.
That distinction matters. I plan around a behavior I have repeatedly observed, but I do not depend on it. If a task stops when the limit is reached, that is not evidence that something broke. The strategy still did what I wanted if I spent the remaining included usage on a task that mattered more than a handful of tiny prompts.
A finished task is not a verified task
There is a second distinction that becomes more important as the task gets larger: completion is not correctness. A TypeScript migration that builds is not proof of correct runtime behavior. A clean ESLint run is not proof that business logic is correct. A bug review that flags a suspicious pattern has not necessarily found a real bug. Even a refactor with passing tests is only as strong as the tests and checks that cover it.
This workflow changes when I start work. It does not lower the validation standard. Large agentic changes still need the checks appropriate to their risk: diff review, typechecking, tests, builds, runtime checks, or other project-specific verification.
When this pattern is a bad fit
I would not treat every large task as a good end-of-limit task. The approach is weaker when the work is still unclear, requires frequent product decisions, involves destructive or production-sensitive operations, or leaves the repository in a dangerous state if interrupted halfway through.
In those situations, a smaller well-bounded task or a fresh usage window is usually a better engineering choice. The goal is not to maximize how dramatic the final prompt is. The goal is to spend scarce included usage on work that can make useful progress safely.
My rule now
When my included Codex usage on ChatGPT Plus falls to roughly 3–5%, I stop optimizing for the number of prompts I have left. I look at the projects I prepared in advance and start the heaviest clearly scoped engineering task that is worth doing.
If Codex keeps working after the visible counter reaches zero, I treat that as useful observed behavior, not an entitlement. If it stops, I am not surprised. I did not discover a way around the limit. I found a better way to decide what to start before I hit it.