A Codex usage-limit message tells you that a request is constrained, but it leaves several practical questions unanswered. Which quota window is empty? When was the last observation recorded? Is the account healthy enough to use, and is another managed account available?
CodexMarathon answers those questions from the shell. Its accountd query exposes quota metadata without exposing credentials, so you can inspect the state before deciding what to do. The CodexMarathon home page has the short product overview, while the CodexMarathon blog collects the longer account-management guides.
Start with the quota view
Run the table view from the same environment where you use the native Codex CLI:
codex marathon accounts --daemon --format tableThe result lists managed account aliases and IDs along with credential health, the observed five-hour window, the observed weekly window, reset times, and observation freshness. The accountd service owns this metadata. It does not read or print auth.json, saved credential snapshots, tokens, cookies, or authorization headers.
The command reads the latest stored observations. It is useful for checking state, but it is not a request to the provider and it does not perform a reset. If you have not configured any managed profiles yet, the table may have no account rows to compare.
For scripts, dashboards, or a closer look at the fields, use JSON:
codex marathon accounts --daemon --format jsonJSON is also helpful when you need to record which alias was active when you saw the limit. Keep the output in the metadata category it belongs to. There is no reason to search it for a credential value, and none should be present.
Read the five-hour and weekly windows separately
The account view shows two quota windows because a short-term observation and a broader weekly observation answer different operational questions. Read both values for the account that was active when Codex reported the limit.
If the five-hour value is exhausted while the weekly value still has observed capacity, the short window is the immediate constraint. If the weekly value is exhausted, changing the way you phrase a request will not create more observed weekly capacity. A nonzero value in one column also does not erase a zero in the other column. Treat the displayed values as the provider observations that Marathon received for that identity, rather than inferring an account plan or an exact allocation from them.
The reset time gives you a concrete timestamp associated with the stored observation. It is more useful than doing mental arithmetic from when the last request failed, especially when several accounts have different observations. It still needs to be read alongside freshness.
Check freshness before trusting a reset time
Run the native status command alongside the quota query:
codex marathon statusstatus reports Marathon’s native enabled state and any transition state. The accountd output supplies the per-window freshness information. Together, they tell you whether you are looking at a clean managed-account state and how current the quota observation is.
An elapsed reset timestamp does not prove that capacity has returned. In Marathon’s quota policy, the old observation becomes stale when its reset time passes. A fresh provider observation is still needed before the account is treated as usable. This matters when a limit message is followed by a quiet period: the clock moving forward is not the same thing as the provider reporting a renewed window.
When the observation is missing, stale, or ambiguous, leave the account out of an automated decision and check again after Codex has received a new native rate-limit observation. The read-only query will then show the newer stored data. It will not manufacture a result when the provider has not supplied one.
Compare managed accounts safely
If you manage more than one supported ChatGPT profile, use the table or JSON output to compare aliases, health, both quota windows, and freshness. Only managed ChatGPT authentication profiles can participate in Marathon switching. API keys, external bearer credentials, workload identity, and other unsupported authentication modes are rejected for this workflow.
Once you have a suitable target, switch by alias:
codex marathon switch workMarathon waits for all account-bound work to become idle before changing identity. It then verifies the target identity before the transition is committed. A failed or uncertain transition remains visible in codex marathon status for reconciliation; the CLI does not infer success from a file change or an elapsed timestamp.
For the safety details behind that boundary, read how to switch Codex accounts without losing your conversation. The companion guide using multiple Codex accounts safely in the Codex CLI covers profile setup and device-code login.
Use the result to choose your next step
An account with healthy credentials, a fresh observation, and usable values in the relevant windows is a reasonable candidate for the next turn. An account with stale or missing data needs another observation before you rely on it. An account with an exhausted window needs time or a different managed profile with fresh usable data. CodexMarathon manages account identity and reports observed quota state. It does not bypass provider limits, reset a provider window, or promise a particular plan allocation. The CodexMarathon source repository documents the accountd boundary and the native commands if you need to inspect the implementation.
If the newest row is still stale, wait for Codex to receive a fresh provider observation, then rerun the table and status commands before switching accounts.