OpenAI Restores Codex’s 5-Hour Limit

OpenAI brought back five-hour usage limits for Codex and Work on ChatGPT Plus, according to a 9to5Mac report. 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.

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.

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.

Watch for 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 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 CLI workflows 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.

Don't use 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.

Watch for 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.

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.

Further reading

• Codex CLI docs
• OpenAI restores 5-hour Codex and Work limits for ChatGPT Plus users

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.