OpenAI Restores Codex’s 5-Hour Limit

By Rogier Muller08.26.26

OpenAI brought back five-hour usage limits for Codex and Work on ChatGPT Plus, according to a 9to5Mac report. It deals with a practical developer question: is a powerful coding agent still dependable when access is shaped by five-hour windows? The answer is yes for many Codex CLI workflows, but only if you treat agent time like a scarce build resource instead of an always-on pair programmer.

Codex CLI is OpenAI’s terminal interface for asking Codex to inspect, edit, and reason about code inside a local development workflow. That matters here because the pain is not abstract “AI usage.” It shows up when you are halfway through a failing test, a refactor, or a review pass and the clock becomes part of the system design. GitHub Copilot Workshop is part of Harness Institute.

Understand what OpenAI changed

The story is simple, and the reaction was not. OpenAI restored five-hour limits for Codex and Work usage on ChatGPT Plus, which means some users again have to think in shorter consumption windows rather than one loose monthly or weekly pool.

Developers cared because Codex is not used like a chatbot once it enters a repo. A Codex agent can read files, propose edits, run commands, and help walk a change from “I think this bug lives here” to “the tests pass.” A five-hour window can be generous for a focused task and awkward for a messy afternoon.

The strongest defense is also straightforward. Short windows help OpenAI smooth demand for expensive compute. If many Plus users run long agent sessions at the same time, the service either needs more capacity, stricter limits, higher prices, or degraded availability.

The trap is pretending this is only a pricing complaint. It is also a workflow shape complaint. A coding agent that disappears mid-loop changes how people plan work, especially when the work involves context-heavy debugging rather than quick code generation.

Read the community debate fairly

One side says the restored limit is reasonable. Plus is a consumer-priced plan, and sustained coding-agent work is compute-heavy. From that view, the five-hour boundary is a pressure valve that keeps the plan usable for more people instead of letting a small number of heavy users consume the pool.

The other side says the boundary hits exactly the people who are not casual. Some developers in lower-income markets said they rely on Plus because higher tiers are simply out of reach. Others said company purchasing paths made higher individual subscriptions impractical, so the restored window felt like a limit on serious work, not casual play.

A more technical objection came up too: if the five-hour limit exists to smooth load, should usage drain differently during off-peak hours? That is a fair question. If the real constraint is peak compute pressure, a flat clock can feel blunt, even if it is easier to explain and enforce.

A few commenters compared the situation with Cursor, Anysphere’s AI code editor, because a single monthly limit can be easier to reason about than multiple short windows. That comparison is not perfect. Codex and Cursor are different products with different surfaces, but the frustration is real: developers prefer limits they can budget before they start a task.

Budget agent time like CI time

The useful move is not to argue from vibes. Pick one real Codex workflow and measure where the five-hour window actually bites. A good candidate is a task that includes reading, editing, and verification, not a one-shot prompt.

For example, take a small service repo with a failing integration test. Ask Codex CLI to inspect the failure, propose a plan, make a minimal patch, and run the test command. Time the loop from first prompt to verified diff, and note how many turns were spent on discovery versus actual editing.

This is where the related training topic becomes practical. The best Codex CLI work is usually bounded before it starts: clear repo rules, a known test command, and a narrow permission surface. If you want a deeper story about Codex’s agent surface, see Codex Opens Its Agent Harness.

The trap is using the first hour as a brainstorming session. Save that for cheaper context. Feed Codex a short handoff instead: the failing command, the files you suspect, the constraints it must obey, and the verification command that counts as done.

Put the boundary in AGENTS.md

A five-hour cap gets less painful when the repo tells Codex how to spend attention. The simplest artifact is an AGENTS.md file with local rules for planning, editing, and verification. Keep it boring. Boring is good here.

# AGENTS.md

## Working style
- Start with a 3-step plan before editing.
- Prefer the smallest diff that fixes the failing behavior.
- Do not reformat unrelated files.
- Ask before changing public APIs, migrations, or auth logic.

## Verification
- For backend changes, run: npm test -- --runInBand
- For lint-sensitive changes, run: npm run lint
- Paste the failing command and the passing command in the final handoff.

## MCP boundary
- Treat GitHub, Jira, and docs MCP servers as read-only unless explicitly approved.
- Do not create tickets, push branches, or modify remote state from an agent session.

This does not make limits disappear. It reduces waste. Codex spends fewer turns rediscovering your conventions and fewer cycles producing beautiful diffs you cannot merge.

The trap is stuffing AGENTS.md with every preference your repo has ever had. Put durable rules there. Keep task-specific context in the prompt or handoff.

Try one small experiment before arguing

Use one repo, one task type, and one week of observation. The goal is not to prove OpenAI right or wrong. The goal is to learn whether the restored five-hour window breaks your actual Codex work.

Question developers are arguing about	Strongest version of the point	Local test
Is the limit fair?	Compute-heavy agent work needs a cap so Plus stays available.	Track whether sessions fail because of limit timing or because the task was too broad.
Is the limit too blunt?	Peak-load smoothing should not feel the same at every hour.	Run the same task type at two different times and record completion time, not just subjective speed.
Does it hurt serious users?	Some serious developers cannot buy higher tiers personally or through work.	Measure how often a normal workday needs more than one focused Codex window.
Should teams switch tools?	A simpler monthly pool may be easier to plan than five-hour windows.	Compare one verified task: same repo, same acceptance test, same handoff, same review bar.

Starter checklist:

Pick one recurring task: failing test fix, small refactor, dependency upgrade, or review cleanup.
Write the acceptance command before opening Codex CLI.
Add or trim AGENTS.md so Codex knows the repo rules.
Keep MCP connections read-only unless the task requires writes.
Record start time, end time, number of agent turns, commands run, and final verification.
Stop counting if the task changes shape halfway through. That is a planning miss, not a limit result.

The limitation is obvious: one week will not model every incident or release crunch. It will, however, tell you whether the argument is theoretical in your repo or already showing up in normal work.

Common questions

Does the restored five-hour limit make Codex CLI unusable?

No, it makes unbounded Codex CLI sessions harder to rely on. A focused loop with a clear failing command, small diff target, and verification step can still fit comfortably inside a five-hour window. The risky pattern is open-ended exploration where Codex spends most of the session finding the task.

Why would OpenAI restore a short-window limit at all?

The practical reason is compute management. Coding agents can run long, context-heavy sessions, and short windows are one way to smooth demand across many Plus users. The tradeoff is that a simple five-hour boundary may feel unfair when a user works off-peak or cannot access a higher plan.

Should I move serious coding work off ChatGPT Plus?

Maybe, but only after measuring your own tasks. If your normal Codex work is small fixes, review cleanup, and test-guided edits, Plus may still be enough. If you regularly need multi-hour agent sessions across several repos, compare plans and tools using the same acceptance tests instead of anecdotes.

What should go in AGENTS.md for limited Codex sessions?

Put durable repo rules, edit boundaries, and verification commands in AGENTS.md. For example: “do not change public APIs without asking,” “run npm test -- --runInBand,” and “keep GitHub MCP read-only.” Do not put one-off task context there; that belongs in the prompt or handoff.

Best ways to use this research

Best for: Codex users deciding whether the restored Plus limits are a real workflow problem or just an annoying policy change.
Best first artifact: A short AGENTS.md file with planning rules, edit boundaries, MCP permissions, and verification commands.
Best comparison angle: Compare verified tasks, not advertised limits. Same repo, same failing test, same review bar.
Best practical takeaway: Treat agent time like CI time. Make the expensive loop start after the task is scoped, not while you are still wandering.

Next step

Run the one-week experiment on a real repo before changing tools or plans. If the limit hurts, you will have a receipt; if it does not, you just tightened your Codex workflow for free.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.