Codex does not reset at a fixed hour. It meters usage in 5-hour windows, and a window begins with your first request rather than with the clock. That single detail is what makes the reset time something you can position rather than something that happens to you.

It is also the detail most people get wrong, because they treat the window like a daily quota and then wait for a boundary that only their own activity can create.

What is documented, and what is not

The documented part is small, and it is worth knowing exactly how small. OpenAI's pricing and usage documentation describes Codex usage as limited by a short window measured in hours plus a longer weekly cap, and the in-product usage panel shows where you sit in both.

One thing is widely reported but not documented as a rule: that when a window expires, the next window opens on your next request rather than automatically at the expiry instant. Users who have watched their own reset timestamps report this consistently, and it is the behaviour the arithmetic below depends on.

Treat that second point as something to verify on your own account rather than something to take from any page, this one included. The check takes about a minute: note the reset timestamp, let the window lapse without sending anything, send one request, and look at the new timestamp. If the new window counts from your request, the technique works. If it counts from the old expiry, it does not, and you have lost nothing but the experiment.

The arithmetic, with real times

Suppose your working session runs 14:00 to 18:00, and you use Codex heavily enough to spend a full window's allowance in about 90 minutes of agent work.

Without positioning, you start at 14:00.

WindowCoversWhat happens
A14:00 – 19:00You spend the allowance by 15:30

You are blocked from 15:30 until 19:00 — 3.5 hours of the day in which you cannot use the tool, and your working session was already over at 18:00. The allowance you were given for the afternoon arrived partly after you stopped.

With positioning, you open a window early with one request.

WindowCoversWhat happens
A11:00 – 16:00Opened by a single trivial request at 11:00; almost all of its allowance is still unspent when you sit down
B16:00 – 21:00Opened by your first request after 16:00

Between 14:00 and 16:00 you draw on the tail of window A. At 16:00 that window expires, and your next request opens window B with a full allowance — which is available for the rest of your working day and beyond it.

The same afternoon, the same plan, and access from 14:00 straight through to 21:00 instead of an hour and a half followed by nothing. A window boundary now falls in the middle of your session, which is the whole point.

Why this is a margin trick and not free capacity

It would be dishonest to present that as doubling your quota. It is not, for three reasons.

The weekly cap still governs. The 5-hour window is the inner limit. If you exhaust the weekly allowance — the outer one — no amount of window positioning restores anything. Positioning only helps when the constraint you are actually hitting is the short window.

An unopened window banks nothing. Opening a window early and not using it does not accumulate capacity for later. You are moving a boundary, not storing anything.

The early request is not entirely free. It consumes a small amount of allowance, and on a plan where every request counts, that is a real cost — trivial next to the benefit, but not zero.

The honest summary: this changes when your capacity is available, not how much of it exists. For someone whose working hours do not line up with their window boundaries, that is worth a great deal. For someone who works in occasional long bursts, it changes nothing.

Automating the early request

If you want the boundary to land at a stable time each day, the opening request needs to happen whether or not you are at your desk. Two ways people do it:

  • In-product rules. Codex has an automation surface where you can define a daily rule whose action is a trivial request. This keeps everything inside the product.
  • A scheduler. On macOS or Linux a cron entry works; on Windows, Task Scheduler. The command is a one-shot prompt, deliberately trivial.

Two cautions before you set this up. First, confirm that automated requests are acceptable under your plan's terms — a scheduled request is still a request. Second, pick a time based on your own anchor, not on a schedule from an article. In the worked example above the opening request goes out 3 hours before real work starts, but the right lead time is a function of when your window expires, which is a function of when you opened it.

How to read which window you are on

The usage panel shows both windows. The timestamp there is sent by the server with each usage report, so treat it as the authoritative value rather than something your client computed.

The symptom worth learning is the mismatch: a healthy-looking short window while you are still blocked. That combination means you are on the weekly ceiling, and no amount of window positioning or waiting within the day will change it. If you are in that state, the technique on this page does not apply to you — you are constrained by the outer limit, and the useful moves are different ones.

FAQ

Does the window start from my first message or from when the account was created? From your activity. That is precisely why two users on the same plan can see reset times hours apart.

Can I start the next window before the current one expires? No. Windows do not overlap. The next one begins after the current one ends, which is why the technique is about placement and not about stacking.

Does this work on the weekly cap too? No. The weekly cap is the outer budget and it is not positioned by your activity in the same way. Positioning is an inner-window technique only.

If I never use Codex for a week, do I get two windows at once? No. Nothing banks. The windows you did not use are gone.

Sources

For the difference between a window releasing on arithmetic and a vendor lifting caps by decision, see Three kinds of reset. For the pattern that also applies to Claude's session window, see Claude Code has three limits.