Repository navigation
[Bug]: Pooled Limits average accounts evenly, ignoring plan size (Pro 20x counts the same as Plus) #13110
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
packages/contracts or packages/shared
Steps to reproduce
- Add a CLIProxyAPI usage-limit source that holds two Codex accounts on different plans: one ChatGPT Pro 20x, one ChatGPT Plus.
- Use most of the Pro 20x account's weekly quota and leave the Plus account untouched.
- Open Usage → Limits and look at the pooled Codex Weekly row.
Expected behavior
The pooled figure weights each account by its plan's capacity. Pro 20x holds 20 of the pool's 21 parts (~95%) and Plus holds 1 (~5%). With Pro 20x fully used and Plus unused, the pool should show about 5% left. The "+X% in …" reset hint should say the Pro reset restores about 95%.
Actual behavior
poolWindows in packages/shared/src/usageLimits.ts averages members evenly:
const usedPercent = members.reduce((sum, m) => sum + m.window.usedPercent, 0) / members.length;
// ...
restoresPercent: Math.round(member.window.usedPercent / members.length),As a result, the same scenario shows 50% left, and each reset claims to restore up to 50% of the pool. Pace (timedUsed / meanElapsed) uses the same unweighted means. The plan multiplier is already on every account (LimitAccount.plan, e.g. ChatGPT Pro 20x Subscription, Max 5x); the pool maths just ignores it. Web, mobile, and the mobile widget all use collectLimitPools, so all three show the wrong figure.
Impact
Major degradation or frequent failure
Version or commit
T3 Code (Alpha) 0.0.42; code checked at 17e34773 on main
Environment
macOS, local CLIProxyAPI hub with Codex Pro 20x + Codex Plus accounts
Activity
fix(usage): weight pooled limits by plan capacity
cartwmic commentedon Nov 10, 2026
Same thing with Claude accounts on a CLIProxyAPI hub. Three accounts, two on a plan twice the size of the third. Both large ones are used up and the small one is nearly full: Usage -> Limits shows 32% left, and the capacity-weighted figure is about 19%. Code checked at 9a0d027 (0.1.9-nightly.20261110.4446):
collectLimitPoolsinpackages/shared/src/usageLimits.ts, lines 577 and 595.Deriving the weight from
LimitAccount.plandoes not cover Claude accounts from a hub:readAccountinapps/server/src/usage/cliproxyApi.tssetsplan: "Claude Subscription"(line 309) and the hub reports no plan for them. So the weight also needs a config source.I have a patch for that. It adds an optional
accountWeightsto the usage source insettings.json, keyed<driver>:<email>(for exampleclaudeAgent:[email protected]: 2). Unlisted accounts count 1, and with no weights the output is unchanged. It weights the pooled remaining, the pace and each reset's restores share, and has tests. Against a real hub it moved the figure from 32% to 19%. I can open a PR if that shape works for you.mentordefi22 commentedon Nov 10, 2026
Another case where an even split misleads, this time on Claude weekly windows: a Claude Pro ($20) and a Max 5x ($100) account pooled together. Right now the Max 5x weekly has 97% left and the Pro weekly is used up (0% left), and Usage → Limits shows the weekly pool at about 49% left.
Weighted by plan, the real figure is much higher: about 81% left at the advertised 5:1 ratio, and still about 65% at a conservative 2:1. #13675 keeps Claude weekly windows equally weighted because the weekly ratio isn't published, so this case stays at ~49% after it lands.
An optional per-account capacity weight in settings (as suggested above) would let users with mixed plans get a correct pooled figure for any provider, without T3 guessing unpublished ratios.
Written by claude-opus-5-5 via T3 Code on behalf of the account owner. (Edited: first version had the two accounts' figures swapped.)