feat: Add reserve/pace indicator for Xiaomi MiMo token plan#1310
feat: Add reserve/pace indicator for Xiaomi MiMo token plan#1310AdrianSimionov wants to merge 5 commits into
Conversation
Shows green pace marker and "X% in reserve" labels when token usage is below expected linear consumption for the monthly billing period. Estimates 30/31-day window from planPeriodEnd for pace calculation.
|
Codex review: needs changes before merge. Reviewed June 5, 2026, 12:40 AM ET / 04:40 UTC. Summary Reproducibility: yes. for the patch defect: an annual plan with less than one month remaining satisfies Review metrics: 1 noteworthy metric.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Copy recommended automerge instructionNext step before merge
Security Review findings
Review detailsBest possible solution: Render MiMo pace only when the billing window can be reliably classified as monthly or annual, and fail closed with focused tests for ambiguous final-month annual periods. Do we have a high-confidence way to reproduce the issue? Yes, for the patch defect: an annual plan with less than one month remaining satisfies Is this the best way to solve the issue? No; the feature direction is useful, but the current inference is not the safest maintainable solution. The PR should use reliable period metadata or fail closed for ambiguous annual final-month windows before rendering pace. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against 65e39f4dcb3a. Label changesLabel changes:
Label justifications:
Evidence reviewedAcceptance criteria:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 060867c0c0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let twentyEightDays: TimeInterval = 28 * 24 * 60 * 60 | ||
| return timeUntilReset > twentyEightDays ? 44_640 : 43_200 |
There was a problem hiding this comment.
For MiMo plans that reset at the end of a 30-day month, this classifies the first ~2 days as a 31-day window because timeUntilReset > 28 days; with a June 30 23:59:59 reset, a June 1 snapshot has almost 30 days remaining, so UsagePace.weekly treats it as already ~1 day elapsed and can show a false “3% in reserve” marker at the start of the cycle. The same problem is larger for February resets. Since the reset date is available, derive the month length from planPeriodEnd (or avoid showing pace until the actual window length is known) rather than using remaining time.
Useful? React with 👍 / 👎.
clawsweeper
Bot
added
rating: 🧂 unranked krab
Use Calendar.date(byAdding: .month, -1, to: periodEnd) to compute the cycle start, then measure the exact window. This correctly handles mid-month subscriptions (June 15 → May 15 = 31 days) and end-of-month resets (June 30 → May 31 = 30 days via Calendar's end-of-month preservation), instead of a >28-day heuristic that misclassified the first ~2 days of a 30-day cycle as 31 days.
clawsweeper
Bot
added
P2
|
Behavior proof: MiMo token plan pace indicator showing 68% in deficit (red marker) at 85% usage with reset on June 30. The pace marker correctly reflects accelerated usage ahead of the linear projection. 
[Screenshot showing: MiMo menu card with 85% used, red pace marker, "68% in deficit · Runs out in ~21h", resets 30 Jun] @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ab9e76f5f8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // subscriptions (e.g. reset June 15 → started May 15 → 31 days) | ||
| // and February resets (28/29 days). | ||
| let calendar = Calendar.current | ||
| guard let cycleStart = calendar.date(byAdding: .month, value: -1, to: periodEnd) else { return nil } |
There was a problem hiding this comment.
When a MiMo account is on an annual token plan, currentPeriodEnd can be close to a year out (the MiMo docs list annual fixed-credit packages: https://platform.xiaomimimo.com/docs/en-US/tokenplan/subscription). Subtracting exactly one month makes windowMinutes about 30 days while resetsAt is many months away, so UsagePace.weekly rejects the window via timeUntilReset > duration and the new reserve/deficit indicator is absent for annual subscribers until the final month; if shown near the end, the expected pace is also based on the wrong duration. Please use the actual period start/duration from the API, or infer yearly vs monthly before setting windowMinutes.
Useful? React with 👍 / 👎.
clawsweeper
Bot
added
proof: sufficient
Calendar.current uses the system timezone, which makes month subtraction non-deterministic (AEST: June 30 → May 31 = 30 days; UTC: June 30 → May 30 = 31 days). Use an explicit UTC calendar so the window length is consistent across all environments.
clawsweeper
Bot
added
rating: 🦐 gold shrimp
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
Detect annual plans (>90 days to reset) and subtract one year instead of one month when computing the billing cycle start. Also fixes the UTC Calendar issue for end-of-month boundaries.
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
Try subtracting one month first; if the resulting window does not cover timeUntilReset, fall back to one year. Works correctly at any point in monthly or annual billing cycles.
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
clawsweeper
Bot
removed
the
rating: 🦐 gold shrimp
clawsweeper
Bot
added
the
rating: 🦪 silver shellfish
|
@clawsweeper re-review |
|
🦞👀 Command router queued. I will update this comment with the next step. Re-review progress:
|
clawsweeper
Bot
added
rating: 🦐 gold shrimp
|
API returns:
We need someone with the Yearly plan to tell us what the API returns. Otherwise we could assume Monthly plans, which would catch majority of the use-cases, I cannot imagine someone paying for an yearly plan when AI is evolving so rapidly. |
1 participant
Adds green pace marker and 'X% in reserve' labels when MiMo token usage is below expected linear consumption for the monthly billing period.