fix(shared): redeem reset credits through the hub when it holds the account

[juliusmarminge]

Problem

When a Codex account is signed in natively and also pooled behind a CLIProxyAPI hub, the "Use reset" button could redeem down either path. Which one it took came down to whichever usage snapshot happened to be fresher, because a single flag decided both which credit balance to display and which path to redeem through.

Those are different questions. Redeeming natively goes through the local Codex app-server against the instance's own CODEX_HOME, which resets the subscription upstream but never calls the hub's /v0/management/reset-quota. The hub therefore kept its routing cooldown for that account and went on refusing every request to it — in the case that prompted this, for another ~119h — even though the account had just been reset. Redeeming through the hub does both, because cliproxyApi.consume clears the cooldown after a successful redemption.

The user has no way to choose: a hub account that duplicates a native provider is folded into the native entry, so there is exactly one button and a checkedAt race decides where it goes.

This is client-side logic in packages/shared, and it had the same defect in two independent builders, so both are fixed here:

• collectProviderUsageLimits — the chat view and composer banners (ChatView.tsx, ComposerUsageLimits.tsx).
• collectLimitAccounts — the pooled usage panel (UsageLimitsPooled.tsx).

Both are imported by web and mobile, and desktop wraps web, so all three surfaces are covered.

Fix

Split the fused decision in each builder. Display still follows the fresher snapshot. The redemption path now prefers the hub whenever it has a credit for that account, and falls back to the native instance only when the hub genuinely has nothing to redeem — a hub contributor only carries a redemption target when it has a credit id, so that fallback keeps working.

One case worth naming: if the hub snapshot is stale and its nextCreditId was already spent by an earlier native redeem, we now send that spent id. The hub returns already_redeemed, which is already treated as a success that still clears the cooldown, and the clients already have copy for it. That is strictly better than the old behavior, which left the hub cooling down a healthy account.

Verification

• A focused test per builder, each covering the regressed case: native contributor with its own credits and a fresher checkedAt, hub duplicate on the same email with a staler one. Both fail on main — the first with the exact production symptom, expected { instanceId: 'codex' } to deeply equal { sourceId: 'hub', … } — and pass here.
• packages/shared/src/usageLimits.test.ts: 41 passed. The existing tests that assert a native redemption target still pass, because in those the hub has no credit to redeem.
• tsgo --noEmit on @t3tools/shared clean; lint and fmt --check clean.
• No further client changes needed: the composers' ?? { instanceId } fallback only fires when the field is absent, which never happens for native providers, and the contract union already carried both shapes.

No UI change — nothing about the rendered output moves, only which backend path the existing button takes.

---

Written by Claude Opus 5 (1M context) in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This is a small, self-contained usage-limit bug fix that changes only the redemption route for accounts duplicated between a native provider and a hub, while preserving the freshest displayed balance and all unaffected paths. Both shared aggregation paths have focused regression tests, with no schema, default, deployment, or static-analysis changes.

Not approved because:

• Monthly spending limit reached (workspace setting). Approvability relies on correctness review in order to determine eligibility

^{Review your spending limits in Billing settings. You can add or adjust custom eligibility rules. Learn more.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.6 KiB	13.6 KiB	+11 B (+0.1%)	15.1 KiB	✅
Codex	Thread snapshot wire	7.0 KiB	7.0 KiB	−5 B (−0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.5 KiB	6.6 KiB	+16 B (+0.2%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.1 KiB	57.1 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.6 KiB	13.6 KiB	−2 B (−0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.0 KiB	7.0 KiB	−1 B (−0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.6 KiB	−1 B (−0.0%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	57.9 KiB	57.9 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	10	10	0 (0.0%)	21	✅

Baseline: 7e03dcf · PR result: 9c2c644 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 113.9 KiB
• Claude decoded thread snapshot: 114.6 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.