Update MiniMax API endpoint from coding_plan to token_plan#534
Update MiniMax API endpoint from coding_plan to token_plan#534doublezz10 wants to merge 2 commits into
Conversation
Updated GLOBAL and CN endpoints to use new /token_plan/remains API: - https://api.minimax.io/v1/api/openplatform/coding_plan/remains → https://www.minimax.io/v1/token_plan/remains - https://api.minimaxi.com/v1/api/openplatform/coding_plan/remains → https://api.minimaxi.com/v1/token_plan/remains Removed redundant fallback URLs since MiniMax now has single endpoints.
📝 WalkthroughWalkthroughPlugin and tests now call /v1/token_plan/remains for GLOBAL and CN. Payload parsing supports percentage-based Token Plan responses (computes used/limit and resetsAt, marks percent-mode). Probe output formatting chooses percent or count output. Tests updated for new endpoints, failure behavior, and percent payloads. ChangesMiniMax token_plan changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related issues
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Updates the MiniMax plugin to use the new /v1/token_plan/remains usage endpoint and adjusts the test suite to reflect the new request/response behavior.
Changes:
- Switched global/CN usage URLs from
coding_plan/remainstotoken_plan/remains. - Updated failing-endpoint tests to assert errors are thrown rather than falling back.
- Adjusted expected HTTP request call counts in tests.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| plugins/minimax/plugin.js | Updates global/CN usage endpoints to the new token_plan/remains path. |
| plugins/minimax/plugin.test.js | Aligns tests with the new endpoints and revised failure expectations. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| const GLOBAL_PRIMARY_USAGE_URL = "https://www.minimax.io/v1/token_plan/remains" | ||
| const GLOBAL_FALLBACK_USAGE_URLS = [ | ||
| "https://api.minimax.io/v1/coding_plan/remains", | ||
| "https://www.minimax.io/v1/api/openplatform/coding_plan/remains", | ||
| "https://www.minimax.io/v1/token_plan/remains", | ||
| ] | ||
| const CN_PRIMARY_USAGE_URL = "https://api.minimaxi.com/v1/api/openplatform/coding_plan/remains" | ||
| const CN_FALLBACK_USAGE_URLS = ["https://api.minimaxi.com/v1/coding_plan/remains"] | ||
| const CN_PRIMARY_USAGE_URL = "https://api.minimaxi.com/v1/token_plan/remains" | ||
| const CN_FALLBACK_USAGE_URLS = ["https://api.minimaxi.com/v1/token_plan/remains"] |
| it("throws when primary endpoint fails", async () => { | ||
| const ctx = makeCtx() | ||
| setEnv(ctx, { MINIMAX_API_KEY: "mini-key" }) | ||
| ctx.host.http.request.mockImplementation((req) => { | ||
| if (req.url === PRIMARY_USAGE_URL) return { status: 503, headers: {}, bodyText: "{}" } | ||
| if (req.url === FALLBACK_USAGE_URL) { | ||
| return { | ||
| status: 200, | ||
| headers: {}, | ||
| bodyText: JSON.stringify(successPayload()), | ||
| } | ||
| } | ||
| return { status: 404, headers: {}, bodyText: "{}" } | ||
| }) | ||
|
|
||
| ctx.host.http.request.mockReturnValue({ status: 503, headers: {}, bodyText: "{}" }) | ||
| const plugin = await loadPlugin() | ||
| const result = plugin.probe(ctx) | ||
|
|
||
| expect(result.lines[0].used).toBe(120) | ||
| expect(ctx.host.http.request.mock.calls.length).toBe(2) | ||
| expect(() => plugin.probe(ctx)).toThrow("Request failed (HTTP 503)") | ||
| }) |
| const PRIMARY_USAGE_URL = "https://www.minimax.io/v1/token_plan/remains" | ||
| const FALLBACK_USAGE_URL = "https://www.minimax.io/v1/token_plan/remains" | ||
| const LEGACY_WWW_USAGE_URL = "https://www.minimax.io/v1/token_plan/remains" | ||
| const CN_PRIMARY_USAGE_URL = "https://api.minimaxi.com/v1/token_plan/remains" | ||
| const CN_FALLBACK_USAGE_URL = "https://api.minimaxi.com/v1/token_plan/remains" |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
plugins/minimax/plugin.test.js (1)
447-453: ⚡ Quick winAssert call count to enforce “throw immediately” behavior.
These tests verify the thrown message, but they don’t verify that only one request was made. Adding a call-count assertion would lock in the intended no-fallback behavior for primary 503/auth-like failures.
Suggested assertions
it("throws when primary endpoint fails", async () => { @@ const plugin = await loadPlugin() expect(() => plugin.probe(ctx)).toThrow("Request failed (HTTP 503)") + expect(ctx.host.http.request).toHaveBeenCalledTimes(1) }) it("throws when CN primary endpoint fails", async () => { @@ const plugin = await loadPlugin() expect(() => plugin.probe(ctx)).toThrow("Request failed (HTTP 503)") + expect(ctx.host.http.request).toHaveBeenCalledTimes(1) }) @@ it("throws when primary returns auth-like status", async () => { @@ const plugin = await loadPlugin() expect(() => plugin.probe(ctx)).toThrow("Session expired") + expect(ctx.host.http.request).toHaveBeenCalledTimes(1) })Also applies to: 455-461, 583-589
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@plugins/minimax/plugin.test.js` around lines 447 - 453, Test cases that assert thrown messages for plugin.probe do not verify call counts, so add assertions to ensure the HTTP request was made exactly once to enforce "throw immediately" (no fallback) behavior: after calling plugin.probe in the tests at the failing blocks (the one with expect(() => plugin.probe(ctx)).toThrow("Request failed (HTTP 503)"), and the similar tests around the ranges noted), assert that ctx.host.http.request was called exactly once (e.g., using the test framework's call count matcher) and that no further requests were attempted; update the tests referencing plugin.probe and ctx.host.http.request in those blocks (including the other locations called out) to include this single-call assertion.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@plugins/minimax/plugin.js`:
- Around line 3-7: GLOBAL_FALLBACK_USAGE_URLS and CN_FALLBACK_USAGE_URLS contain
duplicates of the primary endpoints, causing tryUrls to retry the same URL;
remove the primary URL(s) from those fallback arrays (or deduplicate when
building the final tryUrls) so that GLOBAL_FALLBACK_USAGE_URLS and
CN_FALLBACK_USAGE_URLS only include alternative endpoints, and verify the code
that constructs tryUrls (where these constants are referenced) preserves
uniqueness.
---
Nitpick comments:
In `@plugins/minimax/plugin.test.js`:
- Around line 447-453: Test cases that assert thrown messages for plugin.probe
do not verify call counts, so add assertions to ensure the HTTP request was made
exactly once to enforce "throw immediately" (no fallback) behavior: after
calling plugin.probe in the tests at the failing blocks (the one with expect(()
=> plugin.probe(ctx)).toThrow("Request failed (HTTP 503)"), and the similar
tests around the ranges noted), assert that ctx.host.http.request was called
exactly once (e.g., using the test framework's call count matcher) and that no
further requests were attempted; update the tests referencing plugin.probe and
ctx.host.http.request in those blocks (including the other locations called out)
to include this single-call assertion.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: c004d780-861f-4398-acef-6feea9831e4a
📒 Files selected for processing (2)
plugins/minimax/plugin.jsplugins/minimax/plugin.test.js
| const GLOBAL_FALLBACK_USAGE_URLS = [ | ||
| "https://api.minimax.io/v1/coding_plan/remains", | ||
| "https://www.minimax.io/v1/api/openplatform/coding_plan/remains", | ||
| "https://www.minimax.io/v1/token_plan/remains", | ||
| ] | ||
| const CN_PRIMARY_USAGE_URL = "https://api.minimaxi.com/v1/api/openplatform/coding_plan/remains" | ||
| const CN_FALLBACK_USAGE_URLS = ["https://api.minimaxi.com/v1/coding_plan/remains"] | ||
| const CN_PRIMARY_USAGE_URL = "https://api.minimaxi.com/v1/token_plan/remains" | ||
| const CN_FALLBACK_USAGE_URLS = ["https://api.minimaxi.com/v1/token_plan/remains"] |
There was a problem hiding this comment.
Remove duplicate fallback URLs to avoid retrying the exact same endpoint.
Line 4 and Line 7 repeat the same URL as the primary constants, so tryUrls will hit the same endpoint multiple times on failures/auth responses. That adds unnecessary traffic and delays and undermines the intended fallback cleanup.
Suggested fix
- const GLOBAL_FALLBACK_USAGE_URLS = [
- "https://www.minimax.io/v1/token_plan/remains",
- ]
+ const GLOBAL_FALLBACK_USAGE_URLS = []
const CN_PRIMARY_USAGE_URL = "https://api.minimaxi.com/v1/token_plan/remains"
- const CN_FALLBACK_USAGE_URLS = ["https://api.minimaxi.com/v1/token_plan/remains"]
+ const CN_FALLBACK_USAGE_URLS = []🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@plugins/minimax/plugin.js` around lines 3 - 7, GLOBAL_FALLBACK_USAGE_URLS and
CN_FALLBACK_USAGE_URLS contain duplicates of the primary endpoints, causing
tryUrls to retry the same URL; remove the primary URL(s) from those fallback
arrays (or deduplicate when building the final tryUrls) so that
GLOBAL_FALLBACK_USAGE_URLS and CN_FALLBACK_USAGE_URLS only include alternative
endpoints, and verify the code that constructs tryUrls (where these constants
are referenced) preserves uniqueness.
- Updated endpoint URLs from /coding_plan/remains to /token_plan/remains - Added handling for new percentage-based response format (current_interval_remaining_percent) - When total_count is 0 but remaining_percent exists, display as percent instead of count - Added format.kind 'percent' for percentage display - Added tests for percentage-based Token Plan responses Real API test confirmed new endpoint returns: - current_interval_remaining_percent: 87 (instead of count-based data) - New format is credit-based, not prompt-count-based
There was a problem hiding this comment.
1 issue found across 2 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="plugins/minimax/plugin.js">
<violation number="1" location="plugins/minimax/plugin.js:7">
P2: The fallback URL arrays contain the exact same URLs as their corresponding primary constants. When the primary request fails, `tryUrls` will retry the identical endpoint, adding latency and network traffic without any actual fallback benefit. Since there are no distinct fallback endpoints anymore, set the fallback arrays to empty (`[]`) to avoid redundant retries.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
| @@ -1,11 +1,10 @@ | |||
| (function () { | |||
There was a problem hiding this comment.
P2: The fallback URL arrays contain the exact same URLs as their corresponding primary constants. When the primary request fails, tryUrls will retry the identical endpoint, adding latency and network traffic without any actual fallback benefit. Since there are no distinct fallback endpoints anymore, set the fallback arrays to empty ([]) to avoid redundant retries.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At plugins/minimax/plugin.js, line 7:
<comment>The fallback URL arrays contain the exact same URLs as their corresponding primary constants. When the primary request fails, `tryUrls` will retry the identical endpoint, adding latency and network traffic without any actual fallback benefit. Since there are no distinct fallback endpoints anymore, set the fallback arrays to empty (`[]`) to avoid redundant retries.</comment>
<file context>
@@ -1,11 +1,10 @@
- const CN_PRIMARY_USAGE_URL = "https://api.minimaxi.com/v1/api/openplatform/coding_plan/remains"
- const CN_FALLBACK_USAGE_URLS = ["https://api.minimaxi.com/v1/coding_plan/remains"]
+ const CN_PRIMARY_USAGE_URL = "https://api.minimaxi.com/v1/token_plan/remains"
+ const CN_FALLBACK_USAGE_URLS = ["https://api.minimaxi.com/v1/token_plan/remains"]
const GLOBAL_API_KEY_ENV_VARS = ["MINIMAX_API_KEY", "MINIMAX_API_TOKEN"]
const CN_API_KEY_ENV_VARS = ["MINIMAX_CN_API_KEY", "MINIMAX_API_KEY", "MINIMAX_API_TOKEN"]
</file context>
| (function () { | |
| const CN_FALLBACK_USAGE_URLS = [] |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@plugins/minimax/plugin.js`:
- Around line 418-422: The percent-mode payloads are being scaled by
displayMultiplier (which applies MODEL_CALLS_PER_PROMPT), corrupting percent
values; when building the progress values in this block (used, limit) check
parsed.isPercent and skip the CN scaling: use multiplier = parsed.isPercent ? 1
: displayMultiplier (or only apply displayMultiplier when parsed.isPercent is
false) so that parsed.isPercent results remain 0–100 and are not divided by
MODEL_CALLS_PER_PROMPT.
In `@plugins/minimax/plugin.test.js`:
- Around line 923-954: The test is misleading because percent-mode in
plugins/minimax/plugin.js only reads
current_interval_remaining_percent/current_interval_total_count, so update
percent-mode (the code path used by plugin.probe) to fall back to
current_weekly_remaining_percent (and current_weekly_total_count if relevant)
when interval fields are missing or zero; specifically, modify the logic that
computes line.used/line.limit in percent-mode to check
current_interval_remaining_percent first and if undefined/null or interval
totals are zero, use current_weekly_remaining_percent to compute percent-based
used/limit, then adjust or add unit tests in plugins/minimax/plugin.test.js to
assert weekly-percentage behavior using current_weekly_remaining_percent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: d8821d2a-69fb-478b-b826-3ef6d6c62c53
📒 Files selected for processing (2)
plugins/minimax/plugin.jsplugins/minimax/plugin.test.js
| used: Math.round(parsed.used * displayMultiplier), | ||
| limit: Math.round(parsed.total * displayMultiplier), | ||
| format: { kind: "count", suffix: "prompts" }, | ||
| format: parsed.isPercent | ||
| ? { kind: "percent" } | ||
| : { kind: "count", suffix: "prompts" }, |
There was a problem hiding this comment.
Skip CN prompt scaling for percent-mode payloads.
parsePayloadShape() already normalizes percent responses to a 0-100 range. Dividing CN results by MODEL_CALLS_PER_PROMPT here turns a valid percent line into limit=7, which breaks the percent progress contract and will render the wrong bar for CN token-plan payloads.
Suggested fix
- const displayMultiplier = isCnEndpoint ? 1 / MODEL_CALLS_PER_PROMPT : 1
+ const displayMultiplier =
+ isCnEndpoint && !parsed.isPercent ? 1 / MODEL_CALLS_PER_PROMPT : 1🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@plugins/minimax/plugin.js` around lines 418 - 422, The percent-mode payloads
are being scaled by displayMultiplier (which applies MODEL_CALLS_PER_PROMPT),
corrupting percent values; when building the progress values in this block
(used, limit) check parsed.isPercent and skip the CN scaling: use multiplier =
parsed.isPercent ? 1 : displayMultiplier (or only apply displayMultiplier when
parsed.isPercent is false) so that parsed.isPercent results remain 0–100 and are
not divided by MODEL_CALLS_PER_PROMPT.
| it("handles weekly percentage from Token Plan API", async () => { | ||
| const ctx = makeCtx() | ||
| setEnv(ctx, { MINIMAX_API_KEY: "mini-key" }) | ||
| vi.spyOn(Date, "now").mockReturnValue(1700000000000) | ||
| ctx.host.http.request.mockReturnValue({ | ||
| status: 200, | ||
| headers: {}, | ||
| bodyText: JSON.stringify({ | ||
| base_resp: { status_code: 0 }, | ||
| model_remains: [ | ||
| { | ||
| model_name: "general", | ||
| current_interval_total_count: 0, | ||
| current_interval_usage_count: 0, | ||
| current_interval_remaining_percent: 0, | ||
| current_weekly_total_count: 0, | ||
| current_weekly_usage_count: 0, | ||
| current_weekly_remaining_percent: 100, | ||
| }, | ||
| ], | ||
| }), | ||
| }) | ||
|
|
||
| const plugin = await loadPlugin() | ||
| const result = plugin.probe(ctx) | ||
| const line = result.lines[0] | ||
|
|
||
| // 0% remaining in interval, but 100% weekly remaining | ||
| expect(line.used).toBe(100) | ||
| expect(line.limit).toBe(100) | ||
| expect(line.format.kind).toBe("percent") | ||
| }) |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Does MiniMax /v1/token_plan/remainsever return onlycurrent_weekly_remaining_percentwithoutcurrent_interval_remaining_percent, and is that weekly field expected to drive remaining usage for Token Plan responses?
💡 Result:
Yes, the MiniMax /v1/token_plan/remains endpoint can return responses containing only current_weekly_remaining_percent while omitting current_interval_remaining_percent, typically occurring when the 5-hour rolling window is not active, has not been initialized, or is otherwise not applicable to the current user state [1]. Regarding whether the weekly field drives remaining usage: no, it is not intended to be the sole indicator of your total remaining capacity [2][3]. MiniMax Token Plans operate on a dual-window system consisting of both a 5-hour rolling window and a weekly quota window [2][3]. Both limits must be respected, and hitting either one can trigger rate limiting or usage restrictions [2]. Developers are generally expected to monitor both fields to accurately track their available quota, as the system enforces constraints based on whichever limit is reached first [2][4][3]. It is important to note that the API response fields in this endpoint have historically been identified by developers as misleadingly named [5][6]. Fields suffixed with _usage_count actually represent the remaining quota (not consumed usage), a design that has caused significant integration confusion [5][7][8]. When implementing usage tracking, developers should calculate actual consumption by subtracting the returned "usage_count" from the corresponding "total_count" (e.g., used = total - usage) [5][8].
Citations:
- 1: https://linux.do/t/topic/2284239?tl=en
- 2: https://platform.minimax.io/docs/token-plan/intro
- 3: https://platform.minimax.io/docs/guides/pricing-token-plan
- 4: https://dev.to/0x180db/meter-llm-usage-like-anthropic-tokens-models-weekly-and-monthly-caps-4302
- 5:
current_interval_usage_countfield is mislabeled — returns remaining quota, not consumed usage MiniMax-AI/MiniMax-M2#99 - 6: bug: quota API response field naming is misleading — usage_count actually means remaining count MiniMax-AI/cli#70
- 7: Bug: MiniMax usage count field semantics are inverted — derives wrong % used openclaw/openclaw#81156
- 8: Yeachan-Heo/oh-my-claudecode@6446eac
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n --hidden --no-ignore -S "current_interval_remaining_percent|current_weekly_remaining_percent" plugins/minimax || true
rg -n --hidden --no-ignore -S "line\.used|line\.limit|format\.kind|probe\(" plugins/minimax || true
fd -t f plugins/minimax | head -n 200Repository: robinebers/openusage
Length of output: 5712
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# List plugin files (correct fd usage)
fd -t f --full-path "plugins/minimax" . || true
# Focused searches in minimax plugin implementation
rg -n "current_weekly_remaining_percent|current_interval_remaining_percent" plugins/minimax/plugin.js plugins/minimax/*.js || true
rg -n "line\.(used|limit)|format\.kind|percent" plugins/minimax/plugin.js || true
# Print relevant implementation sections around the known line ~261
sed -n '220,320p' plugins/minimax/plugin.js
sed -n '320,430p' plugins/minimax/plugin.jsRepository: robinebers/openusage
Length of output: 8380
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n "current_weekly_remaining_percent|currentWeeklyRemainingPercent|weekly_remaining_percent|weeklyRemainingPercent" plugins/minimax/plugin.js plugins/minimax/*.js || trueRepository: robinebers/openusage
Length of output: 150
Fix misleading “weekly percentage” test for Token Plan API
plugins/minimax/plugin.js’s percent-mode uses only current_interval_remaining_percent (and current_interval_total_count) to compute line.used/limit; it never reads current_weekly_remaining_percent. So the test in plugins/minimax/plugin.test.js passes because the fixture sets current_interval_remaining_percent: 0 (yielding used=100), not because weekly-percent handling works. Rename the test to “interval percentage” or update the parser to actually support current_weekly_remaining_percent when interval fields are absent.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@plugins/minimax/plugin.test.js` around lines 923 - 954, The test is
misleading because percent-mode in plugins/minimax/plugin.js only reads
current_interval_remaining_percent/current_interval_total_count, so update
percent-mode (the code path used by plugin.probe) to fall back to
current_weekly_remaining_percent (and current_weekly_total_count if relevant)
when interval fields are missing or zero; specifically, modify the logic that
computes line.used/line.limit in percent-mode to check
current_interval_remaining_percent first and if undefined/null or interval
totals are zero, use current_weekly_remaining_percent to compute percent-based
used/limit, then adjust or add unit tests in plugins/minimax/plugin.test.js to
assert weekly-percentage behavior using current_weekly_remaining_percent.
There was a problem hiding this comment.
1 issue found across 2 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="plugins/minimax/plugin.js">
<violation number="1" location="plugins/minimax/plugin.js:420">
P1: Percent-based usage values are incorrectly scaled for the CN endpoint: `displayMultiplier = 1/15` is unconditionally applied, but percentage-mode data (when `isPercent: true`) should not be divided by MODEL_CALLS_PER_PROMPT.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
| used: Math.round(parsed.used * displayMultiplier), | ||
| limit: Math.round(parsed.total * displayMultiplier), | ||
| format: { kind: "count", suffix: "prompts" }, | ||
| format: parsed.isPercent |
There was a problem hiding this comment.
P1: Percent-based usage values are incorrectly scaled for the CN endpoint: displayMultiplier = 1/15 is unconditionally applied, but percentage-mode data (when isPercent: true) should not be divided by MODEL_CALLS_PER_PROMPT.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At plugins/minimax/plugin.js, line 420:
<comment>Percent-based usage values are incorrectly scaled for the CN endpoint: `displayMultiplier = 1/15` is unconditionally applied, but percentage-mode data (when `isPercent: true`) should not be divided by MODEL_CALLS_PER_PROMPT.</comment>
<file context>
@@ -370,7 +417,9 @@
used: Math.round(parsed.used * displayMultiplier),
limit: Math.round(parsed.total * displayMultiplier),
- format: { kind: "count", suffix: "prompts" },
+ format: parsed.isPercent
+ ? { kind: "percent" }
+ : { kind: "count", suffix: "prompts" },
</file context>
Summary
Updated MiniMax plugin to use new /token_plan/remains API endpoint as documented at https://platform.minimax.io/docs/token-plan/faq#how-to-check-token-plan-usage
Changes
plugin.js:
plugin.test.js:
Testing: npm test -- --run plugins/minimax
Summary by cubic
Updates the MiniMax plugin to use the new /token_plan/remains API and support percentage-based usage responses. Removes fallback URLs and now throws on endpoint errors for clearer failures.
New Features
current_interval_remaining_percentand display usage as percent (limit 100)end_timeorremains_timeRefactors
Written for commit e01d700. Summary will update on new commits.
Summary by CodeRabbit
New Features
Bug Fixes
Tests