Usage view misreports limits with multi-account Codex routing

Bug: Usage view reports a single Codex account when traffic is routed across multiple accounts

Summary

T3 Code’s Usage view does not represent multi-account Codex usage correctly when Codex requests are sent through a local OpenAI-compatible proxy that rotates between two ChatGPT/Codex subscriptions. The page is misleading because it presents duplicated or identical Codex limit bars while the account details do not identify or aggregate the underlying account pool.

Environment

• Application: T3 Code (Nightly) on macOS
• Provider shown in the client: Codex
• Subscription setup: two separate ChatGPT/Codex Max subscriptions, referred to here as Account A and Account B
• Routing: local CLIProxyAPI/VibeProxy account pool, using two stored Codex OAuth credentials and round-robin/session-affinity routing
• Proxy endpoint: localhost OpenAI-compatible endpoint
• Related setup guide: CLIProxyAPI and VibeProxy Multi Account Guide.md
• Prior validation: the account pool was tested with fresh sessions, simultaneous requests, Codex resume, failover, and restart recovery; requests were observed using both accounts.

Steps to reproduce

1. Configure CLIProxyAPI/VibeProxy with two eligible Codex OAuth accounts (Account A and Account B).
2. Route Codex CLI requests from T3 Code through the local OpenAI-compatible proxy.
3. Send requests that are distributed across both accounts.
4. Open T3 Code → Usage → Limits.
5. Inspect the Codex weekly limit bars and open each Codex popover.

Actual behavior

• The Usage page shows two identical-looking Codex weekly bars with the same remaining percentage and reset time.
• The bars do not clearly identify Account A versus Account B, nor do they show an aggregate pool total.
• Opening a bar shows a single Codex identity/context and a single limit state. The other account’s usage is not visibly incorporated into the displayed statistics.
• The result can be read as one account’s usage, or as a duplicated representation of one account, even though requests are being routed through both accounts.
• In the Codex CLI, the corresponding status reports Limits: data not available yet when using the custom local provider, which gives no account-level explanation.

Expected behavior

When T3 Code is using a provider through a multi-account router, the Usage view should do one of the following:

1. Show an explicit aggregate: combine the limits for Account A and Account B, label the result as a pooled/aggregated value, and explain how the percentage is calculated; or
2. Show account-level limits: list each account separately with a stable anonymized/account label, its remaining percentage, reset time, and contribution to the pool; or
3. State that limits are unavailable: if T3 Code cannot query limits for a custom provider or cannot associate usage with individual upstream accounts, say so prominently instead of rendering duplicated or misleading Codex limit bars.

The UI should also distinguish “multiple environments/sessions” from “multiple upstream accounts.” Two identical bars should not imply two independently measured accounts unless the data source confirms that.

Evidence

• T3 Code Usage screenshots show duplicated Codex bars with the same remaining percentage and reset countdown.
• The popovers expose only one signed-in context at a time and do not present an account-pool total or account labels.
• The local account-pool setup uses two separate Codex credentials and has been validated with requests reaching both accounts.
• CodexBar 0.60.0 recognizes two configured Codex accounts (the live upstream fetch was unavailable during capture because of a DNS/network error), confirming that the local setup contains two account identities rather than one.

Impact

The display can cause users to believe they have one remaining quota, two duplicate quotas, or a correctly aggregated quota when none of those interpretations is established. This makes it difficult to decide whether a limit is approaching, which account is exhausted, or whether routing is working as intended.

Suggested fix

Detect custom-provider/multi-account routing where possible. If account attribution is unavailable, replace the current duplicated Codex bars with an explicit “limit data unavailable for this provider” state and link to the provider/configuration details. If attribution is available, render a per-account breakdown plus a clearly labeled aggregate rather than duplicating one account’s result.

Start by tracing the T3 Code Usage → Limits view and how Codex provider data reaches its bars and popovers. Read CLIProxyAPI and VibeProxy Multi Account Guide.md alongside the reported multi-account setup. Done means the UI either shows clearly labeled account-level and aggregate limits, or explicitly states that limits are unavailable for the custom provider instead of duplicating bars.