Codex Usage Limits: How Far a /goal Actually Gets You

Codex usage limits are a five hour window shared by the work you run locally and the work you send to the cloud, with weekly limits that may apply on top. The lever that gets the most attention is /goal, a command that keeps one objective alive across turns until a finish line you write says the work is done. Claude Code carries its own version of the same idea, on a different set of limits.

Does it get you past your usage limit? At the time of writing, yes. Whatever Codex is already working on when you hit 100% is allowed to finish, and a goal keeps it working for a long stretch, so a goal you started before the wall carries on past it. That reach is real, documented, and not unlimited. This space moves quickly, so check the linked source before you plan around a number.

Key Takeaways

• A goal keeps one objective alive across turns with a finish line you write yourself.
• That finish line is what decides the run. A goal with no way to check itself works until it decides it is done or burns its budget, and neither one means the work is finished.
• Goals carry a budget of their own, and OpenAI does not publish how it is set. Treat it as a stop you will discover, not one you can plan.
• Yes, a goal gets you past the limit, one turn deep. Start it before you hit the wall: a turn already running may continue, subject to fair use limits the pricing page never defines, and a goal makes turns long.
• A smaller model makes your allowance last longer, and OpenAI says so on the same page.
• Plus and Pro users can buy credits once the cap is reached. That is spending past the subscription, not more of it.
• I keep goals short on purpose, with checkpoints between them. The longest I have run are a few hours, not overnight.

In a hurry? Jump to the 3 checks I put in almost every goal. That is the part that changes what you get back.

What Are Codex Usage Limits?

Codex usage limits are the caps on how much work OpenAI's Codex will do for you on a paid ChatGPT plan before it stops and asks you to wait. OpenAI's own pricing page states the shape in two sentences: "The usage limits for local messages and cloud chats share a five-hour window. Additional weekly limits may apply."

Read the first one twice. Local and cloud share the window, so pushing a long job to the cloud to spare your terminal allowance buys you nothing. It is one meter for the five hour window. That is also all OpenAI publishes about its shape: there is no published account of how quickly the window empties, so treat any confident description of the refill behavior as inference rather than the vendor's answer. Claude's Max tiers draw the same two limits in a different place.

What the page implies, without saying it outright, is that the meter follows the work rather than the message count: it tells you a smaller model stretches the same allowance further. One request that sends the agent off to reason for a long stretch costs far more of the window than a one line question does, which is why two people on the same plan can have completely different experiences of the same limit.

None of that is under your control. The shape of the work you hand over is, and that is where /goal comes in.

What the Codex /goal Command Does

The /goal command in Codex sets a persistent objective that keeps the thread working toward an end state you describe, across as many turns as it takes. You type /goal followed by what you want, and Codex takes over the loop you would otherwise be driving one prompt at a time. It is on by default, so if you are on a current build you already have it.

Two things about how a goal runs are worth knowing before you write one.

The first is that a goal does not spin in a tight loop. OpenAI describes continuation as "event-driven rather than a simple loop", with Codex checking whether to carry on only at safe boundaries: after a turn has finished, when no other work is pending, when no user input is queued, and when the thread is idle. A turn here is one request plus everything Codex does before it hands control back to you. So the boundaries control when Codex decides, not how long it keeps deciding yes.

The second is the standard OpenAI says a goal should meet. Their own cookbook is blunt about it: "Completion must be evidence-based. A Goal should not be marked complete because the model believes it is probably done." Read the verb. That is a standard OpenAI wants goals held to, not a guarantee the tool enforces for you, which is why the way you write the goal text matters more than anything else in this post.

While a goal is running, Codex shows a status indicator with a live elapsed timer, and the numbers on it get large. Runs of twelve hours and more get reported once a goal has no way to stop itself.

How to Write a Goal That Actually Finishes

A good goal names an outcome and the evidence that proves it. In OpenAI's words, "the strongest Goals usually define six things", and every one of them closes off a way the run can drift.

Here is that as a skeleton you can paste. Fill the angle brackets and keep every sentence, because the sentences are what stop the drift. The next section fills the checks placeholder.

/goal <what done looks like>, verified by <the command that proves it>, while keeping <what must not break>. Work only in <the files, folders, or tools you may touch>. Between attempts, record what you changed, what the check showed, and what you will try next, and commit after each step that passes. Before declaring the goal met, <the checks that have to pass>. If you get blocked, stop and report what you tried, what the evidence showed, and what you need from me.

OpenAI's own worked example shows the gap between a goal that sounds specific and one that is. This is the version they call "workable but still fairly thin":

/goal Reduce p95 checkout latency below 120 ms without regressing correctness tests

That already carries an outcome and a constraint. The version they say "gives Codex a fuller operating contract" keeps both and adds the four that were missing: verified by the checkout benchmark, using only the checkout service and its fixtures, recording what changed between iterations, and stopping with the evidence and the blocker if the benchmark cannot run.

Of those four, "verified by" is the one that changes what comes back. Everything else is a wish until that clause names a command the agent can run without you.

OpenAI names three cases where a goal is the wrong tool: work that wants one answer and then a stop, such as a one line edit, a simple explanation, or a short code review; a goal whose finish line is vague; and a goal used to paper over uncertainty. "Make this better", in their words, "gives Codex no reliable completion condition."

The Verification Clause Is Where the Real Work Sits

The objective is the part that feels like the work. The clause after it is the part that decides the run. Three checks go into almost every goal I write, and each only counts once it names something the agent can run.

That third row is the one I would not drop and the one easiest to fool. A file the agent writes is a file it can write empty, so an empty review is a failed review, not a pass. The grep is what turns the review into a stop it has to satisfy rather than assert.

It is still the agent grading itself, and that is the limit of what the goal text can do. A review run by the same thread that wrote the code inherits its blind spot. So when the goal reports done, open the diff in a fresh session and run the review again yourself before you accept it. That part is yours, not the goal's. It is the same limit I keep running into building agents for other work: whatever step is supposed to catch the mistake needs to be checkable, not just confident, a point I go into more with AI agents.

I run /plan before any of this. The plan is where the ambiguity gets settled, so by the time I type /goal the agent is executing something already agreed and proving it worked. OpenAI's note that "plan-only work does not trigger continuation" makes the split clean: planning does not start the clock.

Written out, a goal of mine looks closer to this:

/goal Ship the export feature described in the /plan output, verified by `npm test` passing on a clean checkout and the export smoke script writing a valid file, while keeping existing behavior unchanged. Work only in the export module and its tests. Where you find an issue, fix the root cause: commit a failing test that reproduces it before the fix, and leave `git diff` on existing test files empty. Between attempts, record what you changed, what the check showed, and what you will try next, and commit after each step that passes. Before declaring the goal met, review the diff adversarially and write findings to review-findings.md, each line starting STATUS: OPEN or STATUS: CLOSED, and do not close while `grep -c '^STATUS: OPEN'` returns anything but 0. If blocked, stop and report what you tried, what the evidence showed, and what you need from me.

What surprised me is how much of the outcome is decided by those middle clauses, the checks and the standard they are held to, rather than by the objective at the top. A one line goal with a good objective still drifts. A goal with an average objective and three hard checks comes back with work I can use.

Steering a Goal, and What Stops It

Codex gives you a short list of commands for a goal's lifecycle. Learn them before you start a long run rather than after.

A goal ends in one of several ways, and OpenAI lists them: "success, pause, clear, interruption, budget limit, or a blocker that requires user input."

That fifth one deserves attention. A goal carries a budget of its own, and OpenAI is explicit about what happens when it runs out: Codex "should stop substantive work, summarize progress and blockers, and identify the next useful step", because "reaching a budget limit is not the same as completing the objective". What OpenAI does not publish is how that budget is set, whether you can see it, or whether you can change it. It is a second stop sitting on top of your subscription's, and you cannot see it coming. Claude Code has a comparable ceiling on the other side of a run: the setting that caps how many agents a dynamic workflow fans out to before it stops spawning more.

Does /goal Get You Past a Codex Usage Limit?

Short answer: yes, at the time of writing. Type /goal before you hit your limit, and the run keeps working after the limit lands. I have had this happen. It is not unlimited and it is not a free pass, but the work does carry on.

Here is the mechanism, because it decides how you use it.

Can work keep landing after you hit the wall? Yes, and it is documented. The same pricing page says that "if you reach your usage limits during an active turn, the agent will be able to continue working on that turn, subject to fair use limits." A goal makes turns long, so a goal that is mid turn when your window empties keeps going until that turn is done. That is the mechanism behind a run still working after the limit landed. It is not a loophole, it is the rule working as written, and it is why typing /goal at 99% is a better move than typing it at 101%.

Is it a free pass? No. The work still draws on your allowance, the goal still has a budget of its own, and the protection is written around a turn rather than around the goal. Continuation is checked once a turn has finished and the thread is idle, which is a new turn starting, and a new turn is what a spent allowance blocks. The reach is one turn deep. "Fair use limits" is defined nowhere on the page, and OpenAI does not say whether a goal picks up when your window refills, so assume you will restart it by hand. That is what committing after each passing step buys you: a restart resumes from the last verified state instead of the top.

Two levers are documented. The free one is the model: "If you are approaching usage limits, you can also switch to a smaller model to make your usage limits last longer." Pick it before you start the long run rather than after you hit the wall. To drop to a cheaper model without losing much, the advisor setup I use in Claude Code keeps the hard calls on a smarter model while the cheap one does the volume, and that split works anywhere you pick a model per session. The paid lever is credits, which Plus and Pro users can buy once the cap is reached. That is real headroom and it is spending past the subscription, so treat it as a decision rather than a setting. Worth knowing about a lever that runs the other way, too: raising the Codex context window past its default pushes long requests into a higher rate, so it empties the same allowance faster.

The community reports are louder than the documentation. A Codex user on what they call the "20x Pro" allowance reported in June 2026 that a 12 hour goal run used more than 70% of their weekly limit, "not even counting the credits", and added that for "5x Pro or Plus users, this makes /goal mode almost impractical". A goal does not make the work free. It makes the work continuous.

My own use is deliberately smaller than that. The longest goals I have run are a few hours, because I keep goals short and tangible with checkpoints between them. A goal I can inspect at the end of an afternoon is worth more than one that runs overnight and hands back a pile I have to unpick.