Modernize MiniMax Token Plan and M3 usage display

[Yuxin-Qiao]

Summary

Modernize MiniMax-only usage presentation and parsing for current Token Plan / M3 surfaces while preserving existing auth paths.

What Changed

• MiniMax-only Token Plan/M3 modernization.
• Parser support for current MiniMax remains semantics.
• Prefer model_name == "general" as the primary text/coding quota source (video stays secondary and does not override primary quota).
• Convert remaining-percent fields to used-percent display:
  • 5-hour used % = 100 - current_interval_remaining_percent
  • weekly used % = 100 - current_weekly_remaining_percent
• Parse reset windows from remains_time and weekly_remains_time.
• Parse credits from token_plan_credit (total / used / remaining) while explicitly ignoring api_key.
• Parse subscription metadata from cycle_resource_package (title, tier, expiry/end time, credit total when provided).
• Update docs from "Coding Plan" wording to "Token Plan / M3" where user-facing and relevant.
• Keep existing MiniMax auth behavior unchanged:
  • key-based auth
  • browser session reuse
  • manual Cookie header / cURL fallback
  • legacy env/config compatibility (including MINIMAX_CODING_API_KEY)

Scope

• MiniMax provider UI copy
• MiniMax usage fetcher/snapshot
• MiniMax tests
• docs/minimax.md
• docs/providers.md

No changes to unrelated providers.

Validation

• Ran: swift test --filter MiniMax
• Result: passed (73 tests across 13 suites).

Proof

• Redacted Preferences > Providers > MiniMax screenshot: to be attached in PR thread.
• Redacted MiniMax console screenshots (Token Plan / 5h / weekly / credits): to be attached in PR thread.
• Test proof excerpt:

✔ Suite MiniMaxUsageParserTests passed
✔ Test run with 73 tests in 13 suites passed

Security / Redaction

This PR and test fixtures do not include real secrets or personal identifiers. Specifically excluded/redacted:

• sk-cp keys
• Cookie / Authorization headers
• group ids
• phone/email/account ids
• purchase/order ids
• full HAR payloads

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed June 1, 2026, 9:28 AM ET / 13:28 UTC.

Summary
The PR modernizes MiniMax Token Plan/M3 parsing and display, adds MiniMax snapshot metadata/encoding, updates provider UI copy, adds focused MiniMax tests, and revises MiniMax provider docs.

Reproducibility: yes. for source-level review: the reset-time regression is visible from the PR head source by comparing its remains_time >= 1000 conversion with current main's higher threshold. No live MiniMax account reproduction was run, consistent with AGENTS.md credential-safety guidance.

Review metrics: 2 noteworthy metrics.

• MiniMax surface touched: 13 files, +678/-136. The patch spans provider UI copy, parser models, snapshot encoding, tests, and docs, so it needs a provider-level compatibility review.
• Snapshot schema changed: 1 UsageSnapshot key added. Adding minimaxUsage to the encoded schema changes data-storage behavior for a provider current main fetches fresh.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🦐 gold shrimp
Result: blocked until real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P1] Add redacted Preferences > Providers > MiniMax and MiniMax Token Plan 5h/weekly/credits proof, with keys, cookies, account IDs, IPs, non-public endpoints, and other private details removed.
• [P1] Fix the reset-time compatibility and docs wording findings.
• Reconcile this branch with the overlapping MiniMax Token Plan PR before maintainers choose a canonical landing path.

Proof guidance:

• [P1] Needs real behavior proof before merge: No after-fix screenshot, recording, terminal output, live output, linked artifact, or redacted log proves the rebuilt MiniMax settings UI or real Token Plan 5h/weekly/credits behavior; add redacted proof and update the PR body to trigger re-review, or ask a maintainer to comment @clawsweeper re-review.

Mantis proof suggestion
A visible desktop proof of the MiniMax provider settings and Token Plan usage card would materially help review because the PR changes user-facing provider UI and display. A maintainer can ask Mantis to capture proof by posting a new PR comment that starts with the OpenClaw Mantis account mention, followed by:

visual task: verify the rebuilt CodexBar MiniMax provider settings and Token Plan 5h/weekly/credits usage card with private account details redacted.

Risk before merge

• [P1] The reset-time threshold change can make existing MiniMax responses that provide seconds-based remains_time without end_time display near-immediate resets after upgrade.
• [P1] The PR starts encoding and decoding minimaxUsage in the shared UsageSnapshot JSON schema, while current main deliberately treats MiniMax usage as fetched fresh; that local data-storage behavior needs maintainer sign-off.
• [P1] No redacted after-fix Preferences or MiniMax Token Plan 5h/weekly/credits proof is attached yet.
• [P1] The overlapping open MiniMax Token Plan PR at Fix MiniMax token plan usage display #1266 needs reconciliation before maintainers choose a canonical landing path.

Maintainer options:

1. Fix MiniMax compatibility before merge (recommended)
   Preserve seconds-based remains_time values while accepting current millisecond Token Plan payloads, and cover both units with focused parser tests.
2. Make persistence intentional
   If MiniMax usage snapshots should now be persisted, keep the schema change only after maintainer sign-off and upgrade/privacy review.
3. Pick one MiniMax Token Plan branch
   Pause or close this branch if maintainers choose the overlapping MiniMax Token Plan PR as the safer canonical landing path.

Next step before merge

• [P1] Contributor proof is still missing and maintainers need to reconcile the canonical MiniMax landing path and persistence choice before any automation should repair or merge this PR.

Security
Cleared: No dependency, CI, downloaded-code, permission, or secret-handling regression was found; the MiniMax snapshot persistence change is tracked as a compatibility/privacy review risk rather than a concrete secret leak.

Review findings

• [P1] Preserve seconds-based remains_time resets — Sources/CodexBarCore/Providers/MiniMax/MiniMaxUsageFetcher.swift:842-843
• [P3] Remove PR-specific parser wording from docs — docs/minimax.md:52-53

Review details

Best possible solution:

Land one canonical MiniMax Token Plan update that preserves both legacy seconds and current millisecond reset values, documents product behavior cleanly, treats MiniMax snapshot persistence as an intentional choice, and includes redacted real behavior proof.

Do we have a high-confidence way to reproduce the issue?

Yes for source-level review: the reset-time regression is visible from the PR head source by comparing its remains_time >= 1000 conversion with current main's higher threshold. No live MiniMax account reproduction was run, consistent with AGENTS.md credential-safety guidance.

Is this the best way to solve the issue?

No, not as-is: the MiniMax Token Plan direction is plausible, but the patch should first preserve reset-time compatibility, remove PR-specific docs wording, attach real behavior proof, and reconcile the overlapping landing path.

Full review comments:

• [P1] Preserve seconds-based remains_time resets — Sources/CodexBarCore/Providers/MiniMax/MiniMaxUsageFetcher.swift:842-843
  Current main treats no-end remains_time values up to 1,000,000 as seconds, but this branch divides every value >= 1000 by 1000. A legacy 5-hour seconds value such as 18000 would display as 18 seconds after upgrade, so keep seconds support or infer units from accompanying fields.
  Confidence: 0.86
• [P3] Remove PR-specific parser wording from docs — docs/minimax.md:52-53
  This sentence would ship to users saying “this PR does not change parser or fetch behavior” even though the branch adds parser/fetcher behavior. After merge, docs should describe product behavior rather than the review artifact.
  Confidence: 0.93

Overall correctness: patch is incorrect
Overall confidence: 0.86

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 4756ba06bf42.

Label changes

Label justifications:

• P2: The change affects provider-specific MiniMax usage display and parsing with limited blast radius but visible user impact.
• merge-risk: 🚨 compatibility: The diff changes MiniMax reset-time interpretation and snapshot persistence in ways that can affect existing MiniMax setups after upgrade.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: No after-fix screenshot, recording, terminal output, live output, linked artifact, or redacted log proves the rebuilt MiniMax settings UI or real Token Plan 5h/weekly/credits behavior; add redacted proof and update the PR body to trigger re-review, or ask a maintainer to comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its MiniMax/parser testing, credential-safety, provider-data siloing, and focused-change guidance apply to this review. (AGENTS.md:1, 4756ba06bf42)
• PR reset-time behavior: The PR head changes resetsAt to divide every positive remains_time >= 1000 by 1000 when no future absolute end time is available. (Sources/CodexBarCore/Providers/MiniMax/MiniMaxUsageFetcher.swift:842, e937037a2f1f)
• Current-main reset behavior: Current main only converts very large remains_time values over 1,000,000 as milliseconds, preserving smaller seconds values such as normal multi-hour reset windows. (Sources/CodexBarCore/Providers/MiniMax/MiniMaxUsageFetcher.swift:891, 4756ba06bf42)
• PR docs wording: The PR head would ship docs text saying this PR does not change parser or fetch behavior, even though the branch changes MiniMax parser/fetcher behavior. (docs/minimax.md:52, e937037a2f1f)
• Proof status: The PR body and contributor comments say redacted Preferences and MiniMax console screenshots are still to be attached; no after-fix real behavior proof is present in the provided thread evidence. (e937037a2f1f)
• Related landing path: The provided GitHub context shows an overlapping open MiniMax Token Plan PR at Fix MiniMax token plan usage display #1266, so maintainers should pick a canonical landing path instead of merging competing implementations blindly.

Likely related people:

• steipete: Recent GitHub history for MiniMaxUsageFetcher includes feat: add MiniMax billing summaries, and local blame for the current MiniMax parser and UsageSnapshot schema points to release/current-main commits authored by Peter Steinberger. (role: recent area contributor; confidence: high; commits: af202b462bdf, 3f419060f875, 4756ba06bf42; files: Sources/CodexBarCore/Providers/MiniMax/MiniMaxUsageFetcher.swift, Sources/CodexBarCore/UsageFetcher.swift, docs/minimax.md)
• Yuxin-Qiao: GitHub history for docs/minimax.md shows prior merged MiniMax diagnostic export work by Yuxin-Qiao, and this PR touches the same MiniMax provider documentation and diagnostic-adjacent usage surface. (role: recent adjacent contributor; confidence: medium; commits: 78c8c0b2bd08; files: docs/minimax.md, Sources/CodexBarCore/Providers/MiniMax/MiniMaxUsageFetcher.swift)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[Yuxin-Qiao]

Proof update:\n\n- passed (, ).\n- PR scope diff is limited to MiniMax UI/fetcher/snapshot/tests + + .\n- Redacted screenshots are required and should include:\n 1. Preferences > Providers > MiniMax\n 2. MiniMax console Token Plan 5h/weekly/credits views\n\nSecurity reminder: no real keys, cookies, auth headers, group/account IDs, purchase/order IDs, or HAR dumps in uploads.

[Yuxin-Qiao]

Proof update:

• swift test --filter MiniMax passed (73 tests, 13 suites).
• PR scope diff is limited to MiniMax UI/fetcher/snapshot/tests plus docs/minimax.md and docs/providers.md.
• Redacted screenshots required in PR thread:
  1. Preferences > Providers > MiniMax
  2. MiniMax console Token Plan 5h / weekly / credits views

Security reminder: do not upload real keys, cookies, authorization headers, group/account IDs, purchase/order IDs, or full HAR dumps.

[Yuxin-Qiao]

I’m closing this PR for now instead of continuing to expand it. While investigating MiniMax’s current Token Plan / M3 console behavior, I found we need a clearer integration/design split before this is merge-ready.

Redacted findings

• MiniMax has moved user-facing wording from "Coding Plan" toward Token Plan / M3.
• The console appears to expose separate data surfaces:
  • rolling quota / remains
  • credits
  • subscription/package metadata

Remains semantics observed

• Model-specific windows appear in the remains-style response:
  • model_name: "general" seems to be the primary text/coding quota surface.
  • model_name: "video" seems to be secondary.
• Relevant fields:
  • current_interval_remaining_percent
  • current_weekly_remaining_percent
  • remains_time
  • weekly_remains_time
• Displayed used percentages should be derived as:
  • current-window used = 100 - current_interval_remaining_percent
  • weekly used = 100 - current_weekly_remaining_percent
• remains_time and weekly_remains_time appear to be milliseconds until reset.

Credits and subscription metadata

• Credits-style responses expose credit/balance fields.
• If an api_key field is returned, it must be ignored/redacted and never displayed, cached, committed, logged, or used in fixtures.
• Subscription/package responses appear to expose plan title/tier, expiration, credit total, and Token Plan/M3 benefit text.

Runtime split observed locally

• With a MiniMax key configured, auto prefers the API strategy.
• API strategy can return a basic primary quota/reset window, but in local validation it did not consistently include richer Token Plan fields (plan title, weekly quota, credits, expiration).
• Richer Token Plan console data appears to depend on the web/session path.
• Clearing the key to force Chrome web session was not reliable enough in local validation; candidate session data could be found but refresh was not consistently usable.
• Because of this, UI can still fall back to older-looking primary quota output (generic prompt window) instead of a full Token Plan dashboard.

Why close now

I don’t want to merge a half-proven MiniMax behavior change that may confuse users or future maintainers.

A cleaner follow-up likely needs to explicitly decide between:

1. keep API-key strategy as a basic quota-only path;
2. prefer web/session strategy for Token Plan console data;
3. or merge API quota data with web subscription/credits data when both are available.

Closing this PR avoids further churn while preserving investigation notes for a more complete follow-up implementation.