The short answer is that a Codex usage limit is an account-specific provider observation, not a universal number that applies to every plan. Check the managed account’s five-hour and weekly windows, reset times, credential health, and observation freshness together. Then either continue with that account, request a safe switch to another eligible profile, or wait. CodexMarathon does not invent a plan allocation, refill quota, or bypass a provider rule.
Start with the CodexMarathon home page for the product boundary, then use the blog for related account-management guides. The commands below assume the native CodexMarathon build and its automatically managed account service.
See what the CLI actually knows
Run the accountd-backed table view:
codex marathon accounts --daemon --format tableFor each managed ChatGPT profile, the output can include an alias, stable ID, credential health, observed five-hour window, observed weekly window, reset times, and freshness. It is metadata. Credential snapshots, tokens, cookies, and authorization headers do not appear in the view. If another local tool needs the same records, request JSON instead:
codex marathon accounts --daemon --format jsonThe query reads the latest observation stored by codexmarathon-accountd. It is not a request to the provider, and it does not cause a reset. Check Marathon’s own state beside it:
codex marathon statusstatus tells you whether Marathon is enabled and whether a transition is pending, rejected, or uncertain. A quota row can look healthy while an identity transition still needs reconciliation, so these are two different checks.
Read the five-hour and weekly windows separately
The two windows answer different questions. The five-hour observation describes a shorter window associated with the account’s latest native rate-limit data. The weekly observation describes a broader window. Either one can be the immediate constraint, and a nonzero value in one does not cancel a zero or stale value in the other.
Suppose personal reports a fresh five-hour value of zero with a reset time later today, while its weekly observation is still nonzero. The short window is the reason to pause that profile. If the weekly observation is zero as well, waiting for one short reset may not make the profile eligible. Conversely, a fresh short-window value does not prove that the weekly window can support a long task.
Do not turn the displayed values into a universal “messages per plan” promise. Codex usage depends on the account, provider response, task shape, model, and the observation available at that moment. CodexMarathon deliberately reports what native Codex supplied instead of guessing a hidden allocation. For a focused explanation of the short window, see Codex 5-hour limit explained.
Put reset times next to freshness
A reset timestamp is useful, but it belongs to the observation that produced it. If the timestamp has passed, the corresponding record is stale. The clock moving forward is not proof that the provider has already returned capacity. Wait for Codex to receive a fresh native observation, then run the account query again.
For example, imagine this simplified reading:
| Account | Five-hour | Weekly | Reset | Freshness |
|---|---|---|---|---|
work | 0 | 42 | 2026-09-15 14:00 UTC | stale |
personal | 18 | 0 | 2026-09-20 09:00 UTC | fresh |
Neither row is automatically ready for every job. work needs a new observation even though its reset time is in the past. personal has short-window room but an exhausted weekly observation. The right conclusion is narrower: the latest evidence does not show a fresh account with both relevant windows usable.
This is why “available again” should mean “fresh native evidence says the account is eligible,” not merely “the timestamp is behind the current time.” The Codex rate-limit reset guide covers the same distinction with more reset examples.
Choose a safe next step
If another managed profile has healthy credentials and fresh usable observations, request a switch by alias or stable account ID:
codex marathon switch work
codex marathon statusMarathon waits for an idle account boundary. It does not change an active model response, tool call, or subagent turn. Before committing, it rechecks the source identity, validates and persists the target, asks native Codex to reload authentication, and verifies the target identity. A rejected or uncertain transition stays visible for reconciliation.
Inside a running session, the equivalent controls are:
/marathon status
/marathon switch workSwitching changes which supported managed identity Codex uses. It does not copy quota from one account to another, merge accounts, or make an old observation fresh. If the active account has just reported UsageLimitExceeded, read what to do when a Codex usage limit is reached before trying repeated requests.
What happens when there is no eligible profile
No managed account with fresh usable quota means there is no safe target to select. Leave the work parked, wait for a new native observation, and query again. Repeating switch against an exhausted or stale profile does not create capacity. If a usage-limit recovery is already parked, Codex keeps that existing recovery work in place until the policy can verify an eligible identity.
That waiting behavior protects both quota interpretation and conversation state. Codex owns the thread and exactly-once recovery continuation; Marathon coordinates identity selection. It does not copy a prompt into a new turn or submit a duplicate continuation. The automatic account-switching guide shows this sequence step by step.
Keep the product boundary clear
The current build supports managed ChatGPT authentication profiles. API keys, external bearer authentication, workload identity, and other unsupported provider modes are rejected for Marathon switching. Accountd remains a credential-free metadata service, while native Codex remains authoritative for authentication reload, transport invalidation, and conversation recovery.
Automatic reset controls exist as an explicit, disabled-by-default foundation. A real provider reset is not called by this project. The safe interpretation of a usage limit is therefore practical rather than magical: inspect the evidence, use another eligible account you are authorized to use, or wait for the provider to report a fresh window.
When you need a quick checklist, run status, inspect both windows and freshness, resolve any uncertain transition, and only then select the next supported profile. That routine gives you a useful answer without pretending that an observed quota row is a universal plan contract.