When your Codex usage limit is reached, the next useful action is to identify the state that caused the stop. A short five-hour window, a weekly observation, stale quota data, or a pending account transition each calls for a different response. CodexMarathon gives you a way to inspect those signals and, when you have another eligible profile, change identity without interrupting account-bound work.

The CodexMarathon home page gives the product overview. You can also browse the CodexMarathon blog for related guides on account switching and quota observations.

Check native state first

Start with the native transition view:

codex marathon status

This reports Marathon’s enabled state and the current transition state. A rejected or uncertain transition needs attention before you make another account decision. Marathon records uncertainty instead of treating a successful file operation or a process exit as proof that the target identity became active.

Next, inspect the accountd quota metadata:

codex marathon accounts --daemon --format table

The table shows managed aliases and IDs, credential health, five-hour and weekly quota observations, reset times, and freshness. It does not expose credential snapshots, tokens, cookies, or authorization headers. For a machine-readable view, use:

codex marathon accounts --daemon --format json

Read the active account’s two windows together. The output is an observation for that identity, not a complete description of a provider plan. Keep the displayed timestamp and freshness beside the values when deciding whether the record is still useful.

Look for a fresh eligible account

If the active profile has an exhausted window, compare the other managed ChatGPT profiles. A target with fresh observed capacity in the relevant windows may be able to carry the next turn. Only managed ChatGPT authentication profiles participate in this switching workflow. API keys, external bearer credentials, workload identity, and other unsupported modes are rejected.

If a reset timestamp has elapsed but freshness is stale, wait for a new native provider observation and check again. Elapsed time alone does not prove that quota returned. The same rule applies to a missing or ambiguous observation: leave it out of an automated choice instead of filling in the gap by guesswork.

Switch at a safe boundary

When you have a suitable managed profile, request the switch by alias:

codex marathon switch work

Marathon waits until all account-bound work is idle. It validates and persists the target profile, asks Codex to reload native authentication, and verifies the target identity before committing the transition. An active model response, tool call, or subagent turn is not changed halfway through.

The interactive session exposes the same native controls:

/marathon status
/marathon switch work

After the command returns, run the two read-only checks again. Confirm that the intended alias is active, the transition is clean, and the target’s quota observation is fresh enough for your next decision. If the status remains uncertain, reconcile that transition before starting more account-bound work.

For a longer explanation of the handoff, read how to switch Codex accounts without losing your conversation. The guide on using multiple Codex accounts safely in the Codex CLI covers login and profile setup.

If every account is exhausted

When no managed profile has fresh usable quota, leave the recovery parked and monitor the observations. Codex owns the conversation, thread state, and exactly-once recovery continuation. Marathon can select an eligible account and coordinate the transition, but it does not copy the recovery prompt or submit a duplicate continuation.

Recheck with the accountd command after Codex receives a fresh native rate-limit observation. If the weekly observation is still zero for every managed account, there may be no eligible target to switch to. A reset time on an old record is not enough evidence to change that conclusion.

That waiting state is deliberate. Repeatedly retrying the same account does not create a fresh provider observation, and starting an unrelated switch while a transition is uncertain makes the state harder to read. Check codex marathon status, wait for a clear transition result, and then compare the account rows again. The recovery can stay parked until the quota policy has current evidence for an eligible identity.

What CodexMarathon does not change

CodexMarathon manages identities you control and reports provider-authored observations. It does not bypass, evade, or reset provider quota. The current build does not call a real provider reset action, so no CLI command can force an exhausted window to refill. For implementation details and the supported command surface, see the CodexMarathon GitHub repository.

If no account row has fresh usable quota, leave the recovery parked and rerun codex marathon accounts --daemon --format table after Codex records a new native rate-limit observation.