CodexMarathon adds native multi-account controls to a custom build of the Codex CLI. With more than one ChatGPT profile stored locally, the hardest question is not how to switch accounts; it is knowing when a switch is safe and why a quota observation can be trusted. Fresh quota observations and reset revalidation are the two pieces that make codex account switching feel less like a gamble and more like a deliberate, data-backed operation.

What a quota observation includes

CodexMarathon keeps a private metadata service called codexmarathon-accountd running as a user service. The service stays credential-free. It does not open a TCP port, and status output never prints credentials. Instead, accountd owns metadata that the Codex CLI can use to understand the current state of every managed account.

The local account API exposes:

  • account aliases and active state
  • credential health
  • five-hour and weekly quota windows
  • exact reset times
  • observation freshness
  • scheduler status
  • durable metadata events

The phrase “fresh quota observations” matters because a quota value is only useful when you know when it was recorded. If the local snapshot is hours old, the real provider state may have changed. CodexMarathon treats observation freshness as a first-class signal. It does not pretend that a stored quota number is the same as a live provider response. Before a decision depends on quota state, the CLI can check the freshness of that observation and choose a safer path.

Reset revalidation: from zero to verified

CodexMarathon includes a quota-reset scheduler that was built with mocks and tests. Its intended behavior is conservative: use a real provider reset action only after every eligible managed account has reached zero weekly quota, then verify the refreshed quota before selecting that account.

That means a reset is never assumed to have worked. The moment a reset action returns, CodexMarathon wants to see a fresh observation before it treats the account as available. If the refreshed quota still shows zero, the account is not selected. If the freshness cannot be confirmed, the scheduler does not guess.

This is different from a naive switch that simply alternates identities. CodexMarathon’s reset revalidation step exists to avoid acting on stale or unverified quota state. The source facts are explicit here: no real reset action is called by this project during development, tests, or the current build. Production execution remains disabled until a provider integration exposes a documented reset capability and is explicitly enabled.

So the architecture is ready, but the real provider action is not yet active. You can still inspect the scheduler state, check the reset policy, and understand where quota windows stand. What you cannot do today is claim that CodexMarathon itself triggers a real ChatGPT reset.

How this affects codex account switching

Codex account switching already has a strict safety model. A switch waits until all account-bound work is idle. It never changes an active model response, tool call, or subagent turn. The source identity is checked again before a transition. The target profile is validated and persisted atomically before Codex updates its in-memory credentials.

Fresh quota observations fit into that model by making the switch decision less surprising. When you ask CodexMarathon for account state, you can see not only which account is active, but also whether the quota data is recent and when the next reset window begins. That context helps you decide whether to switch manually or wait for the scheduler.

A common pattern is:

  1. Check current observations.
  2. Confirm the active account is idle.
  3. Switch to a target alias.
  4. Verify the new active identity after reload.

The local daemon supports this through the native codex marathon commands. The command output uses aliases and account IDs, never opaque credential snapshots. You can also use /marathon inside an interactive Codex session to see the same state.

Practical command example

For a quick look at account health, quota windows, and observation freshness, use the daemon-aware accounts command:

codex marathon accounts --daemon --format table

You can also request machine-readable JSON when you need to feed the state into another local tool:

codex marathon accounts --daemon --format json

To see whether the reset scheduler is enabled and how it is behaving:

codex marathon auto-reset status

If a reset capability were ever available and explicitly enabled, the flow would start with:

codex marathon auto-reset on

But remember the current build never invokes a real provider reset action. The commands exist for inspection and for the explicit, opt-in control that would gate production execution once a provider integration is documented.

For normal codex account switching, the native commands remain the same:

codex marathon on
codex marathon switch work

The switch command resolves an alias or account ID and changes the active identity only when no turn is running. That boundary is the same one used by the reset scheduler when it considers a revalidated account.

Revalidation and the status line

You can surface Marathon state directly in the Codex status line. The marathon item shows whether native Marathon is enabled. The marathon-accounts item shows the number of managed accounts.

These status-line items are useful during long interactive sessions because they turn quota context into ambient information. Instead of leaving the session to inspect state, you can see the account count at a glance and run the interactive /marathon panel for details. The panel explains the available account, login, enabled-state, and switching commands.

In the interactive panel, you can also run:

/marathon auto-reset status

That keeps the reset scheduler visible without requiring a separate shell. If the scheduler has not been enabled, the panel will reflect that state.

Provider quotas still apply

Fresh quota observations and reset revalidation are about making better decisions with accurate data, not about changing the provider’s rules. Provider quotas still apply. CodexMarathon does not extend quotas, hide quota consumption, or pretend an exhausted account is ready when the provider says otherwise.

The project’s design is explicit about this boundary. CodexMarathon owns account aliases, opaque credential snapshots, quota observations, and transition policy. Codex itself remains authoritative for the active turn, authentication reload, account-bound transport invalidation, and recovery continuation. The two sides do not blur together. Marathon can ask Codex to switch only after a safe boundary, and Codex decides what happens inside the turn.

That separation matters when a reset is involved. The scheduler may consider a reset-capable account, but it does so only when every managed account has reached zero weekly quota. It then verifies the refreshed quota before selecting that account. If verification fails, the account stays unavailable.

Where to look next

The project documentation covers the full architecture, encrypted account backup, and build verification. The CodexMarathon blog is a good place for product updates. The GitHub repository contains the source, the runtime provenance, and the feature usage docs.

Codex account switching becomes much easier to reason about when the local state is fresh and the reset path is conservative. CodexMarathon does not promise magic; it promises a credential-free metadata daemon, safe-boundary switching, and a quota-reset scheduler that waits for verified observations. That is the right trade-off for anyone who wants control without guessing.