Repository navigation
fix(usage): correct MiniMax token plan quota display - #1642
diegosouzapw merged 3 commits into
Conversation
…ailures - Override plist to v4.0.0 which passes mandatory mimeType to DOMParser - Add USERPROFILE sanitization on Windows to avoid EPERM on junction points - Add NPM_CONFIG_LEGACY_PEER_DEPS to Electron workflow install step
Treat the newer MiniMax token-plan endpoint as reporting used counts while preserving fallback behavior for the older coding-plan endpoint, and round compact quota percentages for display.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a helper function to correctly calculate MiniMax usage quotas by determining whether the API response represents used or remaining units based on the request URL. It also includes a new unit test to verify this logic. Regarding the UI changes, rounding the remaining percentage to the nearest integer may cause misleading displays near the 0% and 100% thresholds; consider using a more precise rounding method or Math.floor to maintain accuracy for the user.
| const remainingPercentageRaw = q.unlimited | ||
| ? 100 | ||
| : (q.remainingPercentage ?? calculatePercentage(q.used, q.total)); | ||
| const remainingPercentage = Math.round(remainingPercentageRaw); |
There was a problem hiding this comment.
Rounding the remaining percentage to the nearest integer can lead to misleading displays at the extremes. For example, a quota with 99.6% remaining will be displayed as 100%, which might incorrectly suggest that no usage has occurred. Conversely, a quota with 0.4% remaining will show as 0%, suggesting it is completely exhausted.
Consider using a more precise rounding method (such as toFixed(1) for values near the boundaries) or using Math.floor for the remaining percentage to ensure that 100% is only shown when the quota is truly untouched, maintaining better accuracy for the user.
4eef082
into
cheaper-inference:release/v3.7.1
|
Thanks @CruxExperts for this excellent fix! 🎉 Great catch on the used-vs-remaining semantics difference between the two MiniMax endpoints, and the |
…ce#1642) Integrated into release/v3.7.1 — fixes inverted MiniMax quota display for token_plan/remains endpoint and rounds floating-point percentages.
…ce#1642) Integrated into release/v3.7.1 — fixes inverted MiniMax quota display for token_plan/remains endpoint and rounds floating-point percentages.
…ce#1642) Integrated into release/v3.7.1 — fixes inverted MiniMax quota display for token_plan/remains endpoint and rounds floating-point percentages.
Summary
/v1/token_plan/remainsendpoint as reporting used request counts, while preserving remaining-count behavior for the older/coding_plan/remainsfallback endpoint.13 / 15000and66 / 150000so the dashboard shows roughly full remaining quota instead of near-zero remaining quota.0.044000000000000004%.Context
The upstream MiniMax report MiniMax-AI/MiniMax-M2#99 documents the older
/coding_plan/remainssemantics as remaining counts. The newer/v1/token_plan/remainsendpoint used first by OmniRoute returns used counts in the observed live response, so applying the old fallback semantics to the new endpoint reverses remaining quota.No matching open OmniRoute issue or PR was found for this MiniMax-specific inversion. PR #1516 added the current MiniMax quota support.
Test plan
npx cross-env DISABLE_SQLITE_AUTO_BACKUP=true node --import tsx/esm --test tests/unit/usage-service-hardening.test.ts tests/unit/provider-limits-ui.test.tsnpm run test:unit, 3629 tests passed, 0 failednpm run check:any-budget:t11