“Rate limit” and “usage limit” are often used as if they mean the same thing. The safe distinction is narrower: a rate-limit response is what native Codex reports when a request cannot proceed, while a usage-limit view is the account-specific quota metadata you inspect to understand the likely window and reset state. Neither phrase gives you a universal plan allocation. Read the native error, both observed windows, freshness, and account health together.
The CodexMarathon home page describes the supported account workflow. This guide focuses on interpreting signals without guessing what a provider has not reported. For a command-oriented starting point, see how to check your Codex usage limit.
Start with the event that stopped the work
The first piece of evidence is the native Codex result. It may identify a usage-related condition such as UsageLimitExceeded, or it may indicate another request or authentication problem. Do not replace that native result with a number from an older dashboard row. The event belongs to the identity and turn that just ran.
When Codex reports UsageLimitExceeded, Codex owns the conversation and parks the existing recovery turn. Marathon can help find another eligible managed account, but it must complete a safe identity transition before Codex releases that recovery exactly once. The automatic switching guide explains the sequence.
A rate-limit response can therefore be an immediate operational event, while usage metadata is context for deciding what to do next. The distinction helps prevent two common mistakes: treating a stale reset timestamp as proof that the request will work, or treating every request failure as evidence that every quota window is empty.
Query the observed usage windows
Use the accountd-backed table view:
codex marathon accounts --daemon --format tableThe output can show each managed alias and ID, credential health, an observed five-hour window, an observed weekly window, reset times, and observation freshness. It is deliberately metadata-only: accountd does not expose credential snapshots, tokens, cookies, or authorization headers. For a machine-readable check, run:
codex marathon accounts --daemon --format jsonThese values are observations supplied through native Codex’s rate-limit path and stored by the private service. They are not a live quota query that guarantees the next request. If a row is missing, stale, or ambiguous, leave it out of an automated eligibility decision until Codex supplies a new observation.
Compare the terms without overpromising
| Signal | What it represents | What it does not prove |
|---|---|---|
| Native rate-limit response | The condition Codex reported for a particular request or turn | That every account or window is exhausted |
| Five-hour observation | The latest short-window metadata for one managed account | A universal number of prompts or messages |
| Weekly observation | The latest broader-window metadata for that account | That a short-window reset restores weekly capacity |
| Reset timestamp | The time attached to the stored observation | That capacity has returned after the clock passes it |
| Freshness | Whether the observation is current enough to interpret | That credentials or a pending transition are healthy |
The table is a reasoning aid, not a provider specification. “Usage limit” is useful shorthand when the native event and the stored window point in the same direction. It is less useful when it hides which window, account, or timestamp you actually inspected.
Work through a concrete example
Imagine a work profile receives UsageLimitExceeded. The next query reports a fresh five-hour value of zero, a weekly value of 35, and a reset time two hours away. The evidence supports a short-window constraint for work; it does not say that the weekly allocation is gone. A safe next step is to wait for fresh evidence or compare another managed profile.
Now imagine the timestamp has passed but freshness still says stale. The correct conclusion is not “the limit definitely reset.” It is “the stored observation needs replacement.” Run the query again after native Codex receives a new provider-authored observation. An elapsed timestamp without freshness is not enough to authorize a switch or a new long-running task.
Finally, suppose work has fresh short-window capacity but zero weekly capacity. Starting a second request because the short number looks healthy ignores the other window. Read both values for the same alias. The current product intentionally avoids turning these observations into an estimate for every ChatGPT plan.
Check transition state before changing identity
Alongside the quota view, check Marathon’s state:
codex marathon statusIf another managed profile has fresh usable observations, request a switch only when you are ready for a safe boundary:
codex marathon switch personal
codex marathon statusMarathon waits until account-bound work is idle, rechecks the source identity, validates and persists the target, and asks native Codex to reload its authentication. Codex then verifies the target identity and invalidates account-bound transports before the transition is committed. A rejected or uncertain result stays visible; a successful file rename is not treated as proof of a committed identity.
This is why a rate-limit response should not trigger an emergency auth.json edit or a mid-turn profile swap. Read why changing auth.json mid-turn is unsafe for the failure modes and the supported alternative.
Keep the response responsible
Use only managed ChatGPT profiles you are authorized to control. API keys, external bearer authentication, workload identity, and other unsupported provider modes are rejected for Marathon switching. Account changes do not merge plan entitlements, reset windows, or move usage from one identity to another.
The current build includes a mock-tested reset foundation, but it calls no real provider reset action. If no account has fresh usable quota, a parked recovery waits while policy revalidates quota state. That pause is more accurate than repeated retries that create more errors and no new provider evidence.
In practice, the distinction is simple: treat the native response as the event, treat the quota rows as context, and treat freshness and safe-boundary state as gates. That gives you enough information to decide whether to continue, switch, or wait without claiming more than CodexMarathon can know.