When Codex reports UsageLimitExceeded, the automatic path is deliberately ordered: Codex parks the existing recovery turn, Marathon selects a fresh eligible managed account, the identity change waits for a safe boundary, Codex verifies the target, and the same recovery resumes exactly once. If no account is eligible, it waits. CodexMarathon never refills quota, edits an active credential during a turn, or creates a second continuation to make the work appear to continue.

That sequence is the useful answer for anyone searching for automatic Codex account switching. The CodexMarathon home page gives the product overview, while what to do when your Codex usage limit is reached covers the manual inspection path.

The recovery sequence, in order

The native recovery path has six meaningful stages:

  1. Observe UsageLimitExceeded. Codex receives the usage-limit result for the active managed identity.
  2. Park the existing turn. Codex keeps the conversation, thread state, and recovery work without submitting a new continuation.
  3. Select a fresh eligible account. Marathon compares supported managed profiles with fresh, usable observations and healthy credentials.
  4. Wait for a safe boundary. No model response, tool call, or subagent turn is allowed to change identity halfway through.
  5. Verify the target identity. Native Codex reloads authentication, invalidates account-bound transports, and confirms the intended profile before commit.
  6. Resume exactly once. Codex releases the parked recovery work once, using the existing conversation context.

The order matters. Selection before the boundary would not be enough; a target still needs an atomic transition and identity acknowledgement. Verification before resuming is what protects exactly-once behavior.

Turn the policy on and prepare accounts

Automatic management operates on profiles that are already managed by Marathon. Check the current state and saved identities first:

codex marathon status
codex marathon accounts
codex marathon on

For accountd-backed quota metadata, use:

codex marathon accounts --daemon --format table

The rows can include credential health, five-hour and weekly observations, reset times, and freshness. A profile is not automatically eligible because it exists. Stale or missing observations, an unsupported authentication mode, an unhealthy credential, or a pending uncertain transition should keep it out of the target set.

To add a managed profile on a headless machine, use the native device-code flow before enabling automatic management:

codex marathon login work --device-code
codex marathon on

The device-code login guide explains how the verification URL and one-time code work. Only add accounts you are authorized to use. Automatic selection is an identity-management convenience, not a way to combine entitlements.

What “fresh eligible” means

Marathon needs evidence that a candidate can carry the next turn. “Fresh” refers to a current native observation, not merely a reset timestamp that happens to be in the past. “Eligible” also means the profile is a supported managed ChatGPT authentication profile with healthy credentials and no unresolved transition that would make identity ambiguous.

The policy reads both windows. A profile with a fresh five-hour value but an exhausted weekly observation may not be suitable for the task. A profile with an elapsed reset time and stale data needs a new native observation first. A missing value is not an invitation to guess. For background, read Codex usage limits: windows, freshness, and safe next steps.

Marathon does not infer universal plan allocations. The provider-authored observations stay attached to the account and timestamp that produced them. Automatic switching chooses between evidence-backed profiles; it does not manufacture capacity.

Why the safe boundary is part of automation

An automatic action still has to obey the same transition contract as a manual switch. Marathon waits until account-bound work is idle, rechecks the source identity, validates and persists the target atomically, and asks Codex to reload native authentication. Codex then invalidates account-bound transports and verifies the target identity. Only after the expected account and generation agree does the transition commit.

This prevents an in-flight response from beginning under one identity and finishing under another. It also makes a process interruption diagnosable: a rejected transition stays rejected, and a lost acknowledgement remains uncertain until native evidence reconciles it. The system does not infer success from a changed file timestamp or a successful rename.

During a usage-limit recovery, the boundary also protects the conversation. Codex does not copy the recovery prompt into a new turn, advance a second counter, or submit a duplicate request while the target is being verified. The existing parked work remains the only work eligible for release.

If every account is exhausted

No fresh eligible account means no switch. Codex leaves the recovery parked while policy waits for quota state to change and checks observations again. That can feel slower than retrying, but retries cannot create provider capacity and can obscure whether the original transition is still pending.

Use read-only checks when you need to understand the wait:

codex marathon status
codex marathon accounts --daemon --format json

Look for a fresh observation and a clean transition state. Once a candidate becomes eligible, the same park-select-boundary-verify-resume sequence applies. If no candidate becomes eligible, the correct outcome remains waiting—not a forced identity edit, a copied prompt, or an improvised reset.

The rate-limit reset guide explains why an old reset timestamp does not release parked recovery on its own.

What automatic switching does not do

CodexMarathon manages supported identities that you control. It does not bypass provider controls, move quota between accounts, or call a real provider reset action in the current build. The reset capability and scheduler are mock-tested and disabled for production execution unless a documented provider integration is later enabled explicitly.

It also does not expose credentials to accountd, status output, logs, or transition records. Native Codex remains authoritative for authentication, transport invalidation, the running thread, and exactly-once recovery. Marathon supplies policy and durable account metadata around those native decisions.

The practical result is predictable automation: preserve the original recovery, choose only from current evidence, cross the identity boundary while idle, verify, and resume once. When the evidence is not there, waiting is the safe and honest state.