[Feature]: Prefer other Codex pool accounts to preserve the signed-in ChatGPT account #7100

Area

Authentication and account pool

What are you trying to accomplish?

Keep the current ChatGPT/Codex Desktop account signed in for account-dependent features, while spending other eligible Codex pool accounts' included quota first. Preserve the signed-in account as a last resort, so proxy traffic is less likely to exhaust the account that the desktop client itself uses.

The reporter observes that exhausting the signed-in account can prevent further desktop use despite capacity elsewhere in the pool. That client symptom is reported context, not a newly reproduced root cause. This proposal is about preventing avoidable consumption of that identity; it does not claim to repair an already-disabled composer.

What prevents this today?

The basic priority mechanism already exists; this is not a request to add account priorities from scratch (see #715).

• ocx account priority openai main last sets only the synthetic __main__ entry. A matching login stored as an ordinary pool account keeps its own priority and can still be chosen, consuming the same underlying subscription.
• The pool-card order control is shown when its value is non-default or the card's ⋯ menu is open. Users looking at normal cards can therefore miss it.
• Priority changes normally affect unbound requests; a healthy existing thread keeps its account by default. Manual pins also need clear treatment. codexAccountPriorityFailback is a separate opt-in with quota-strategy, positive-threshold and fresh-evidence conditions.
• Pausing main is already a stronger alternative: the pause endpoint links matching main/pool identities, releases their bindings and selects another account, without changing the login file. It excludes the login rather than reserving it for last-resort use.

The missing workflow is a clearly named, identity-aware Prefer other accounts / preserve signed-in quota policy or preset that explains these distinctions.

What should OpenCodex do?

Provide an opt-in control near the native main-login / pool strategy settings, for example Use other accounts first; keep the signed-in ChatGPT account as fallback.

1. Prefer eligible pool identities other than the current signed-in identity. Apply the preference to both native main and any matching pool entries, so a duplicate record does not defeat the intent. Match only with sufficient existing account/member/workspace identity evidence; do not group unrelated members merely because they share a workspace.
2. Use the signed-in identity only when no preferred eligible account can serve, subject to all existing quota guards, model access, pause, reauthentication and credit-spending consent. State explicitly that fallback can consume the reserved quota.
3. Show the affected entries and the effective next choice. Explain when an existing binding stays in place, and offer an explicit next-request transition for a user who wants the preference to apply to ongoing work; do not switch an in-flight request. Respect or clearly reconcile explicit account-qualified models and manual pins.
4. Make never use this identity through the pool a clearly distinguished option or explanation of the existing linked-pause workflow. Keep desktop sign-in intact.
5. If the signed-in identity changes, show which identity the preference now protects. Preserve the user's existing custom account ordering when turning the preset off.
6. Explain that this only controls requests which reach OpenCodex. An already-locked desktop composer is a separate client-side issue; do not advertise priority as a universal unlock.

Example usage or interface

Synthetic example (no real account identifiers):

• Native main login A.
• Stored pool entry A-copy, the same member/account identity.
• Stored pool entry B, a different usable identity.

Current behavior with only main last: A is -2; A-copy and B remain 0. A-copy can still serve. With quota, a lower usage score for A-copy selects it; with fill-first, an already-active A-copy can remain selected.

Requested mode: B serves first; A and A-copy share the reserved/fallback role. If B cannot serve, show that fallback will consume A's quota. For an existing A-bound thread, show whether it is retained or explicitly moved for the next request.

Existing manual equivalent for new/unbound requests:

ocx account priority openai main last
ocx account priority openai <matching-pool-entry-id> last

This is an ordering preference, not an absolute exclusion. B must have a higher priority than both entries; these commands were exercised only through synthetic API fixtures, not applied to the reporter's running setup.

Alternatives or workarounds

• Set main and every matching pool entry to a lower priority manually. This works for unbound requests, but users must discover and maintain the identity relationship themselves.
• Use the existing Pause action on main: current code groups matching pool entries as well. Isolated tests confirmed that the synthetic login file is unchanged and an existing bound request moves to another account. Desktop UI/account-feature continuity was not live-tested.
• Use codexAccountPriorityFailback where its documented conditions fit; it is not equivalent to a general signed-in-account preservation policy.
• Desktop authless mode changes account-dependent desktop behavior, so it does not meet the requirement to keep the current sign-in experience.

Related reports: #6196 tracks composer-side quota gating and has later reports of build-dependent limitations; #7046 is closed after #7076 improved the main-hard-lock error contract/recovery hint. Neither should be described as a new, proven failure of pool selection here.

Additional context

Source inspected on 2026-10-14: fetched upstream dev at 08bb2e485d56115d2ecd641a15659ff912b69d38 (package version 2.86.0 development), and main at 732fba65b4cb2ff35c3416a4102553cb36ec28bb (2.85.0). The priority setter, selection module and linked-pause helper are identical between those two refs. The reporter's screenshot shows 2.84.0; no live upgrade or account-setting mutation was performed.

Pinned source evidence:

• Documented main-last command and binding/pin semantics.
• Priority setter changes one account ID; priority API clears the manual pin but does not release live bindings.
• Shared priority-tier selection after eligibility checks.
• Default pool-card priority control disclosure.
• Existing linked-pause identity matching and atomic publication / binding release.
• Documented priority failback and default cache affinity.

Offline verification in an archived copy of that dev commit:

• Existing pool rotation, priority failback, linked pause and main-hard-lock usage-limit suites: 167 passed, 0 failed, Bun 1.3.14. An initial attempt could not load missing dependencies; the successful run followed an isolated frozen-lockfile install with lifecycle scripts disabled.
• Additional synthetic API/routing cases: 10 passed, 0 failed, Bun 1.4.2. They verify main-only demotion can still select A-copy under quota, round-robin, fill-first (A-copy active), and reset-first; demoting both entries selects B; reserved entries remain fallback; linked pause excludes both and preserves the login file. An initial fill-first fixture without an active cursor chose B by alphabetical order; the corrected fixture explicitly sets A-copy active. This demonstrates a possible selection, not that every strategy always picks A-copy.
• Tests use temporary homes, fake credentials and quota observations. The additional cases exercise management API and routing selection, not real upstream inference or desktop quota-gate behavior. The main-token liveness seam is synthetic. No production credentials, usage balances, account identifiers or model requests were used. No full-suite or live desktop acceptance is claimed.

The request can build on existing priority/linked-identity mechanisms. Whether it is implemented as a preset, clearer controls, or a persistent policy is an implementation decision. No raw screenshot is attached because it contains account/usage information.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.