# Codex's 5-Hour Window: What Counts and What Resets

Codex meters usage over a rolling window of roughly five hours. What draws it down, including reasoning time, how resets behave, and how to pace heavy sessions.

*Published 2026-06-12 · https://proxyllm.ai/blog/codex-5-hour-limit-explained*

Every ChatGPT plan meters Codex over a rolling window of roughly five hours: work you do counts against the window for about five hours and then ages out, so capacity returns continuously instead of all at once at midnight. The window's size varies by plan and model and changes over time, which is why OpenAI publishes the current figures at developers.openai.com/codex/pricing rather than a fixed number we could quote here. This page covers what draws the window down, how resets actually behave, and how to pace work so the window stays out of your way. The full limit system, including weekly caps and credits, is in [Codex usage limits, explained](/blog/codex-usage-limits-explained).

## How a rolling window behaves

A rolling window is a different animal from a daily quota. There is no shared reset hour when everyone's meter clears. Instead, the system looks back about five hours from right now and asks how much you have used in that span. Heavy work from this morning stops counting against you by mid-afternoon, automatically.

Two practical consequences:

- **Recovery is gradual.** If you hit the ceiling, you do not need to wait five full hours; you need to wait until enough of your earlier usage ages out. A lockout after a burst often eases within the hour.
- **Pacing beats bursting.** The same total work spread across a day may never touch the limit, while the identical work compressed into ninety minutes will. The 5-hour window is a pace limiter, not a daily allowance.

The CLI's `/status` command shows your live position against the window and a reset estimate. Make it a reflex before large runs; the other places usage shows up are covered in [how to check your Codex usage](/blog/check-codex-usage).

## What actually draws the window down

Codex meters work, and most of the work is invisible. Reasoning time bills the same whether you read the output or not, and an agent loop that edits, tests, fails, and retries is metering the whole time. A rough qualitative map (these are behavior descriptions, not quoted figures):

| Activity                                            | Window draw            |
| --------------------------------------------------- | ---------------------- |
| Short question about code                           | Small                  |
| Single agent task that edits and runs tests         | Moderate               |
| Long agentic run, retries on, high reasoning effort | Large                  |
| Several of those in parallel                        | The whole window, fast |

Three multipliers deserve respect. Reasoning effort settings scale the cost of every task, so the deep-thinking mode spends the window faster on identical prompts. Retries meter as full work even when they fail. And the window is shared across every Codex surface on your account: CLI sessions, the IDE extension, cloud tasks, and code review all pull from one pool, counted toward a shared agentic usage limit.

## Observed patterns

Treating community reports as anecdotes rather than specifications, the consistent ones look like this:

- Light interactive users say they rarely or never see the 5-hour limit.
- People running parallel agent sessions report hitting it within one to two hours of starting.
- Users who step away after a lockout report meaningful capacity back within the hour, which matches rolling-window behavior.
- Heavy users often discover the 5-hour window was never their real problem: the weekly cap underneath it was. That layer is covered in [the Codex weekly limit](/blog/codex-weekly-limit-explained).

## When it runs out mid-task

For a person at a keyboard, the honest answer is a coffee. The window rolls, capacity returns, and interactive work resumes shortly.

For automation, waiting is not a strategy. A pipeline that stalls whenever a window fills is a pipeline you stop trusting. The operational fix is lanes: overflow routes to a second ChatGPT account you own, then to your own OpenAI API key, and returns to the subscription lane once the window recovers. That failover, and what it looks like in a request log, is walked through in [what happens when you hit your Codex usage limit](/blog/what-happens-when-you-hit-codex-usage-limit).

## The window in one paragraph

Codex's short limit is a rolling meter of roughly five hours that measures work, including reasoning time, across every Codex surface on your account. It refills continuously, punishes bursts, forgives pacing, and sits on top of a weekly cap on some plans. Check `/status` before big runs, spread what can be spread, and give anything unattended a fallback lane.

We run that fallback as a product: [Codex Hosted](/) keeps the official CLI signed in with your own account and fails over between lanes automatically, so a full window slows nothing down.