Conversation
Pooled Limits averaged each account's window evenly, so a Plus account counted as much as a Pro 20x one. Weight the pooled share, pace, and per-reset restore figure by the multiplier in the plan label. Fixes pingdotgg#13110 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
| const first = members[0]!.window; | ||
| const usedPercent = members.reduce((sum, m) => sum + m.window.usedPercent, 0) / members.length; | ||
| // Each member counts by its plan's capacity, not one vote apiece. | ||
| const weightOf = (member: LimitPoolMember) => planCapacityWeight(member.account.plan); |
There was a problem hiding this comment.
🟡 Medium src/usageLimits.ts:366
Pooled usage, pace, and reset-restoration percentages use the wrong tier weight when collectLimitAccounts takes winner.limits from the fresher source but keeps previous.plan ?? next.plan. A Pro window can therefore be weighted as Plus (or vice versa) until the stale source disappears; the merged account's plan must be selected from the same source as limits (or otherwise reconciled with it).
🤖 Copy this AI Prompt to have your agent fix this:
In file @packages/shared/src/usageLimits.ts around line 366:
Pooled usage, pace, and reset-restoration percentages use the wrong tier weight when `collectLimitAccounts` takes `winner.limits` from the fresher source but keeps `previous.plan ?? next.plan`. A Pro window can therefore be weighted as Plus (or vice versa) until the stale source disappears; the merged account's `plan` must be selected from the same source as `limits` (or otherwise reconciled with it).
ApprovabilityVerdict: Would Approve Macroscope's review found this PR approvable — This is a focused, test-covered correction to pooled usage calculations, with understood impact limited to displayed quota, pace, and reset estimates across existing web and mobile consumers. An unresolved Medium finding separately flags a possible stale plan/limits mismatch during account merging, which remains a blocking correctness concern under repository policy. Not approved because:
Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more. |
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: pingdotgg/t3code/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe change adds plan-capacity parsing and applies it to pooled usage, pace, and reset restoration calculations. Tests cover valid and fallback multipliers and verify a Pro 20x account contributes 20 times the capacity of a Plus account. ChangesWeighted pooled limits
Priority: ➖ Normal Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Bug fix · Severity of issue fixed: Medium Suggested reviewers: Merge Risk: ⚪ Minimal · up to No verified merge-blocking risk remains in the weighted pooled usage change. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
0a55175 to
05ddf42
Compare
What Changed
poolWindowsinpackages/shared/src/usageLimits.tsnow weights each pooled account by its plan's capacity. The weight comes from the multiplier already in the plan label (ChatGPT Pro 20x Subscription→ 20,Max 5x→ 5). A label without one (Plus, Claude Pro, hub-reportedClaude Subscription) counts as 1. The weights apply to:restoresPercent(the "+X% in …" hint and the "Restores" popover row)The change adds
planCapacityWeightand tests for both the helper and a Pro 20x + Plus pool.Why
Fixes #13110. Pools averaged members evenly, so a Plus account counted as much as a Pro 20x account. Take a Pro 20x account that is fully used plus an untouched Plus account: the pool showed 50% left, but the real figure is about 5% (20 of 21 parts are spent). Web, mobile, and the mobile widget all use
collectLimitPools, so fixing it here fixes all three. Pools whose accounts share a plan tier give the same numbers as before, so existing tests are unchanged.UI Changes
Only the numbers change (pooled percent, pace arrow, "+X% in …" / "Restores +X% of pool"). Layout and segment widths are unchanged. Example: Pro 20x at 100% used + Plus at 0% went from "50% left" to "5% left".
Checklist
Checks run locally:
vp test run src/usageLimits.test.ts(shared, 32 passed; the new pool test fails onmainwith 50 ≠ 5), mobilesubscriptionUsageSnapshot.test.ts(12 passed),tsc --noEmitforpackages/shared,vp lint,vp fmt, knip--exportsonpackages/shared.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Tests