feat(gui): show weighted Codex pool capacity and next recovery in Providers overview

[luvs01]

Area

Multiple areas

What are you trying to accomplish?

I want the Providers overview to explain the usable capacity of the whole Codex account pool without hiding either the effective current account or exhausted pool members.

The primary summary should be a clearly labeled, configured-weight pool estimate. The effective runtime account and its raw quota should remain visible as secondary context. The overview should also say how much weighted capacity the next reset will restore.

What prevents this today?

The OpenAI provider quota currently reports one account selected from persisted config.activeCodexAccountId. It does not follow the effective runtime-active account and does not aggregate the pool.

If the persisted selected account is exhausted while the effective account or other pool members still have capacity, the Providers overview can show 100% even though usable pool capacity remains.

What should OpenCodex do?

Show a display-only weighted capacity estimate for each quota window, using these initial configured weights:

Plan	Weight
Plus	1
Business	1
Prolite	5
Pro	20

For each window independently:

total capacity = sum(weight)
consumed capacity = sum(weight * usedPercent / 100)
aggregate used percent = consumed capacity / total capacity * 100
remaining capacity (internal only) = total capacity - consumed capacity
next recovery percent = recovered consumed capacity / total capacity * 100

The weighted units are an internal calculation detail and should not be displayed in the GUI.

The overview should:

• use the weighted pool estimate as the primary quota value;
• show the effective current account and its raw quota separately;
• show the earliest future reset as next capacity recovery, not as a full pool reset;
• group accounts sharing that exact reset timestamp;
• display the restored share of the total configured pool as a percentage, for example +19.2% pool capacity at the next reset;
• not emphasize a projected post-reset percentage;
• keep weekly, monthly, 5-hour, and other windows separate;
• keep this display-only and never change routing, pinning, thread affinity, pause state, or automatic switching.

Correctness safeguards:

• Do not guess weights for team, free, go, unknown future plans, or missing plan data.
• Exclude unknown-plan and missing-quota rows from numeric totals and report incomplete coverage.
• Exclude paused or reauthentication-required accounts from immediately routable capacity while reporting the excluded count.
• Ignore expired reset timestamps until quota refresh.
• Preserve raw per-account percentages as authoritative.
• Label the aggregate as a configured-weight estimate rather than an upstream-guaranteed capacity contract.
• If aggregation is impossible, fall back to the effective runtime account rather than the stale persisted selection.

Example usage or interface

Synthetic example with common plan types:

Pro (20 units) at 10% + Prolite (5 units) at 100% + Plus (1 unit) at 100%
total = 20 + 5 + 1 = 26
consumed = 20*0.10 + 5 + 1 = 8
aggregate = 30.77% used

Suggested overview:

OpenAI (Codex login)
Pool capacity estimate: 30.8% used
Current account: raw account quota shown separately

Next capacity recovery
<next reset time>
+19.2% pool capacity (if Prolite resets next)

In this synthetic pool, a fully consumed Plus reset would show +3.8% pool capacity; a fully consumed Pro reset would show +76.9% pool capacity.

Alternatives or workarounds

• Showing only the current account is accurate for the cursor but hides the pool.
• Showing only the least-used account hides exhausted members.
• Showing only the most-used account is overly pessimistic.
• A raw unweighted average is misleading because the configured plan capacities differ.
• The Codex authentication page exposes individual rows, but it does not provide a concise Providers overview summary.

Additional context

The current single-account selection is in src/providers/quota.ts. Effective runtime selection is resolved separately in src/codex/routing.ts and exposed by /api/codex-auth/active.

Tests should cover the synthetic Pro 10% + Prolite 100% + Plus 100% = 30.77% example, next-recovery percentage points, same-time resets, partial consumption, unknown plans, missing quota, paused/reauth accounts, mixed windows, expired resets, and all-excluded fallback.

Related context: #724 and #750 cover plan freshness, #593 covers quota-aware pool strategies, and #821 covers account priority/pinning direction.

This issue is being opened before implementation to surface conflicts and collect feedback. A complete, validated implementation will follow as a PR. Routing behavior is out of scope.

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.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.