One find-and-replace task drained Codex's five-hour Plus limit in 24 minutes, dev.to post says

OpenAI has brought back a five-hour usage window for Codex on its Plus plan, and a developer who ran into it says a single modest coding task exhausted the entire allowance in about 24 minutes, leaving the feature half-finished and the agent locked out until the quota reset. The account, published on dev.to, mirrors complaints from other Plus subscribers on the OpenAI community forums.

One task drained the whole window

The author's test case was deliberately small: add Find and Replace to a Markdown notes app, covering a menu entry, keyboard shortcuts, match navigation, Replace and Replace All. According to the post, Codex implemented most of the feature, wrote tests, ran the build and lint checks, and had started verifying the interface in a browser when the usage-limit error appeared. Roughly 24 minutes of elapsed time had passed. Search highlighting was still incomplete, and because the cap had been hit, the developer could not ask Codex to finish its own changes until the window reset, which the author treats as the point where the arrangement stops functioning as a tool.

Five hours is not five hours

The author accepts that agentic usage is metered by factors such as context size, reasoning effort, tool calls and test runs rather than wall-clock time. The objection is one of scale: there is a large gap between a window that might not last exactly five hours and one that a single routine task can consume in under half an hour. Without any sense of how long the allowance will hold, the developer writes, planning becomes impossible, since opening Codex might buy an afternoon of work or a single short task.

Users preferred the weekly-only arrangement

For a short period, Plus users effectively worked under a weekly limit without the five-hour window, and the author preferred that model: spend heavily on a weekend, accept that the quota is gone for the rest of the week, and keep control over when to be productive. Under the current setup, users can be locked out while substantial weekly quota remains, because one agentic task emptied the smaller rolling bucket. The post points to multiple Plus users on the OpenAI community describing the same pattern: ordinary development sessions consuming most or all of the five-hour allowance, sometimes with Codex stopping before the work was complete.

What OpenAI's documentation says

Citing OpenAI's current documentation, the post notes that usage varies with the model, task complexity, context, reasoning, speed and tools, and that an active Codex turn may continue after a limit is reached, subject to fair-use restrictions. That carve-out did not help in this case: the session still ended with a usage-limit error while the feature remained unfinished.

The author also flags a perverse incentive. Thorough work, including exploring the codebase, running tests and verifying changes in a browser, is precisely what consumes quota fastest, so the more diligently the agent behaves, the sooner the user is locked out mid-session. Skipping tests or verification to conserve allowance would undermine the main reasons to use a coding agent in the first place. The stated ask is not unlimited access: a weekly compute budget, a generous rolling anti-abuse cap, or throttling of extreme workloads would all be acceptable, provided users can decide when to spend their quota.

Why it matters

Codex is positioned as a tool for sustained, autonomous software work, yet a quota that one find-and-replace feature can exhaust undercuts that premise for paying Plus users. It also risks nudging people toward shallower agent runs, with fewer tests and less verification, degrading exactly the output quality that justifies agentic coding. More broadly, the episode captures a growing-pains moment for AI coding tools as they move from demos into daily workflows: metering designed around chat-style interactions may not map onto agentic sessions where a single turn spans builds, test suites and browser checks. If mid-tier plans cannot carry one focused feature implementation, developers may conclude that quota design, rather than model capability, is the binding constraint on real work.