People searching for the Codex 5-hour limit usually want a simple answer: what does the window mean, when can they check it again, and what should they do while it is empty? The safest answer starts with the data Codex received from the provider. CodexMarathon keeps that observation visible next to a separate weekly window, its reset time, and its freshness.

The phrase “five-hour limit” is useful shorthand for an observed quota window. It should not be treated as a promise about every ChatGPT plan or as a fixed provider allocation. The CodexMarathon home page explains the account workflow, and the blog has more guides for people managing quota-affected sessions.

What the five-hour window tells you

Run the accountd-backed view:

codex marathon accounts --daemon --format table

For each managed account, the table includes credential health, a five-hour quota observation, a weekly quota observation, reset times, and freshness. These are metadata supplied through Codex’s native rate-limit observation path and stored by the private account service. They are not credentials, and the display does not print credential snapshots, tokens, cookies, or authorization headers.

The five-hour value helps you understand the short window associated with the account’s latest observation. It does not tell you how a provider calculates every plan limit, nor does it establish a universal number of requests or messages. Keep the reading tied to the account and timestamp shown by the CLI.

The weekly value matters at the same time. An account can have a usable observation in one window and an exhausted observation in the other. That is why checking only for a five-hour reset can give you an incomplete picture.

A useful comparison keeps the alias and freshness next to the numbers. For example, a row with zero observed five-hour capacity and a reset time in the future is still constrained in that short window, even if its weekly value is nonzero. A different row with a reset time in the past but stale freshness is not ready to use on the strength of that timestamp alone. You are comparing identity-specific observations, not calculating a universal countdown for every Codex account.

Check both windows and the reset time

Use JSON when you want to inspect the full account records or feed a local report:

codex marathon accounts --daemon --format json

Then check native Marathon state:

codex marathon status

The first command gives the per-account quota metadata. The second reports whether Marathon is enabled and whether a transition needs attention. Looking at both prevents a quota observation from being confused with an account-switching problem.

The reset time belongs to the stored observation. If the timestamp has passed, Marathon marks that window’s observation stale. The passage of time alone does not prove that the provider has restored capacity. Wait for a fresh native observation and check the command again before treating the account as ready.

This distinction is easy to miss during a long-running session. A terminal can show a reset timestamp that looks current while the rest of the account record is old. Freshness gives you the missing context. If it is missing, stale, or ambiguous, keep the account out of a usage decision until Codex supplies a new observation.

What to do while the window is exhausted

If you have another managed ChatGPT profile, compare its two windows and freshness before switching. A candidate with fresh, usable observed data can be selected by alias:

codex marathon switch work

The switch waits until all account-bound work is idle. Marathon verifies the target identity before committing the transition, so an active model response, tool call, or subagent turn is not changed halfway through. If the result is rejected or uncertain, codex marathon status keeps that state visible for reconciliation.

Inside an interactive Codex session, the matching controls are available through the native panel:

/marathon status
/marathon switch work

Switching accounts is an identity-management operation. It does not erase the five-hour observation, change a provider’s allocation, or make an exhausted account report fresh capacity. For a closer look at the safe-boundary behavior, see how to switch Codex accounts without losing your conversation.

Know where the product stops

CodexMarathon supports managed ChatGPT authentication profiles. API keys, external bearer authentication, workload identity, and other unsupported modes are rejected for managed switching. Keep accounts under your control and use the native login flow documented in the multiple-account guide. The CodexMarathon GitHub repository contains the source and quota-policy documentation.

The current build has no real provider reset action. Its reset foundation is mock-tested and disabled for production use. There is no command that can force the five-hour window to refill, and the project does not bypass or evade provider quota.

When the reset timestamp has passed, rerun codex marathon accounts --daemon --format table and use the five-hour row only after its freshness shows a new native observation.