Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: provider-usage-DYewFt0n.js hardcodes CN endpoint for MiniMax usage polling — ignores configured baseUrl [3 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#65054•Fetched 2026-04-12 13:25:48
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
0
Author
sixone74sixone74
Participants
sixone74sixone74
Timeline (top)
cross-referenced ×3labeled ×2referenced ×1

Root Cause

fetchMinimaxUsage() at provider-usage-DYewFt0n.js:489 hardcodes api.minimaxi.com instead of reading the configured models.providers.minimax.baseUrl.

// Line 489 — hardcoded CN endpoint, ignores user config
const res = await fetchJson("https://api.minimaxi.com/v1/api/openplatform/coding_plan/remains", {

Fix Action

Fixed

PR fix notes

PR #65059: fix(minimax): use configured baseUrl for usage polling endpoint

Description (problem / solution / changelog)

The MiniMax usage fetcher hardcodes the CN endpoint (api.minimaxi.com) for coding_plan/remains. Global endpoint users (api.minimax.io) get wrong/stale usage data or 403 errors.

Add baseUrl parameter to fetchMinimaxUsage and derive the usage host from the provider config. Falls back to CN endpoint for backward compatibility.

Fixes #65054

Changed files

  • extensions/minimax/provider-registration.ts (modified, +7/-2)
  • src/infra/provider-usage.fetch.minimax.ts (modified, +27/-1)

PR #65106: fix(minimax): use configured baseUrl for usage polling endpoint

Description (problem / solution / changelog)

Closes #65054

Changed files

  • extensions/memory-core/src/dreaming-narrative.ts (modified, +2/-0)
  • extensions/minimax/provider-registration.ts (modified, +6/-1)
  • src/gateway/server-methods/chat.directive-tags.test.ts (modified, +31/-0)
  • src/gateway/server-methods/chat.ts (modified, +3/-0)
  • src/infra/provider-usage.fetch.minimax.test.ts (modified, +57/-1)
  • src/infra/provider-usage.fetch.minimax.ts (modified, +24/-2)
  • src/secrets/resolve.test.ts (modified, +16/-0)
  • src/secrets/resolve.ts (modified, +9/-1)

PR #65145: fix(minimax): use configured baseUrl for usage polling endpoint

Description (problem / solution / changelog)

Closes #65054

Changed files

  • extensions/memory-core/src/dreaming-narrative.ts (modified, +2/-0)
  • extensions/minimax/provider-registration.ts (modified, +6/-1)
  • src/gateway/server-methods/chat.directive-tags.test.ts (modified, +31/-0)
  • src/gateway/server-methods/chat.ts (modified, +3/-0)
  • src/infra/provider-usage.fetch.minimax.test.ts (modified, +57/-1)
  • src/infra/provider-usage.fetch.minimax.ts (modified, +24/-2)
  • src/secrets/resolve.test.ts (modified, +16/-0)
  • src/secrets/resolve.ts (modified, +9/-1)

Code Example

https://api.minimaxi.com/v1/api/openplatform/coding_plan/remains

---

// Line 489 — hardcoded CN endpoint, ignores user config
const res = await fetchJson("https://api.minimaxi.com/v1/api/openplatform/coding_plan/remains", {

---

https://api.minimax.io/v1/api/openplatform/coding_plan/remains

---
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Bug Description

The MiniMax usage fetcher in provider-usage-DYewFt0n.js (line 489) hardcodes the CN endpoint:

https://api.minimaxi.com/v1/api/openplatform/coding_plan/remains

This ignores the baseUrl configured in models.providers.minimax. For users on the global endpoint (api.minimax.io), the usage tracker calls the wrong host entirely, resulting in either:

  • HTTP 200 with stale/wrong data (e.g. returning 4431/4500 instead of actual usage)
  • HTTP 403/1004 "cookie is missing, log in again" (CN auth rejecting global key)

Impact

  • openclaw status --usage shows garbage data for global MiniMax users
  • Per-session usage cards can't display accurate MiniMax quota
  • Users have no way to monitor Token Plan usage through OpenClaw

Root Cause

fetchMinimaxUsage() at provider-usage-DYewFt0n.js:489 hardcodes api.minimaxi.com instead of reading the configured models.providers.minimax.baseUrl.

// Line 489 — hardcoded CN endpoint, ignores user config
const res = await fetchJson("https://api.minimaxi.com/v1/api/openplatform/coding_plan/remains", {

Steps to reproduce

  1. Configure MiniMax with global endpoint (api.minimax.io) using a Token Plan API key
  2. Run openclaw status --usage
  3. Compare output to portal at https://platform.minimax.io/user-center/payment/token-plan
  4. Numbers do not match (e.g., shows 4431/4500 used vs portal showing 71/4500)

Expected behavior

Usage polling should respect models.providers.minimax.baseUrl. For global users with baseUrl: "https://api.minimax.io/anthropic" (or api.minimax.io), the usage endpoint should be:

https://api.minimax.io/v1/api/openplatform/coding_plan/remains

Actual behavior

HTTP 200 with stale/wrong data (e.g. returning 4431/4500 instead of actual usage) HTTP 403/1004 "cookie is missing, log in again" (CN auth rejecting global key)

OpenClaw version

OpenClaw 2026.4.9

Operating system

macOS

Install method

pnpm

Model

minimax2.7

Provider / routing chain

minimax

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The most likely fix is to update the fetchMinimaxUsage() function to use the configured baseUrl from models.providers.minimax instead of hardcoding the CN endpoint.

Guidance

  • Identify the fetchMinimaxUsage() function in provider-usage-DYewFt0n.js and update the hardcoded URL to use the baseUrl from models.providers.minimax.
  • Verify that the baseUrl is correctly configured for global users, using https://api.minimax.io/ or https://api.minimax.io/anthropic.
  • Test the updated function with a global endpoint configuration to ensure it returns accurate usage data.
  • Consider adding error handling to handle cases where the baseUrl is not correctly configured or the API request fails.

Example

const baseUrl = models.providers.minimax.baseUrl;
const res = await fetchJson(`${baseUrl}/v1/api/openplatform/coding_plan/remains`, {
  // ...
});

Notes

This fix assumes that the baseUrl is correctly configured in models.providers.minimax for global users. If the configuration is incorrect, additional debugging may be required.

Recommendation

Apply the workaround by updating the fetchMinimaxUsage() function to use the configured baseUrl, as this will allow global users to access accurate usage data without waiting for a full version update.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Usage polling should respect models.providers.minimax.baseUrl. For global users with baseUrl: "https://api.minimax.io/anthropic" (or api.minimax.io), the usage endpoint should be:

https://api.minimax.io/v1/api/openplatform/coding_plan/remains
#api#model save/load#optimization#mixed precision#training loop

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING