openclaw - 💡(How to fix) Fix Bug: MiniMax usage count field semantics are inverted — derives wrong % used

Bug: MiniMax usage count field semantics are inverted — derives wrong % used

Affected version: 2026.5.7 (eeef486) Channel: Telegram Provider: minimax-portal (MiniMax-M2.7)

Summary

The MiniMax usage display shows X% left that actually means X% used — still broken in 2026.5.7 despite a previous fix attempt (PR #60254).

Example: Dashboard confirms 7% used (93% remaining). Status bar shows 7% left (correct label, wrong value interpretation — it's inverted twice).

Root Cause

1. Two endpoints — incompatible field semantics

MiniMax provides two usage endpoints that return the same model (MiniMax-M*) with different semantic meanings for current_interval_usage_count:

Neither endpoint's count-based calculation matches the dashboard's confirmed value of 7% used. This suggests the gateway is using the wrong endpoint and interpreting current_interval_usage_count incorrectly.

2. Raw API payloads (live capture)

Dashboard confirms: 7% used (93% remaining)

ENDPOINT 1 — api.minimax.io/v1/token_plan/remains (gateway default):

{
  "model_remains": [
    {
      "start_time": 1778616000000,
      "end_time": 1778630400000,
      "remains_time": 12241883,
      "current_interval_total_count": 1500,
      "current_interval_usage_count": 151,
      "model_name": "MiniMax-M*",
      "current_weekly_total_count": 0,
      "current_weekly_usage_count": 0,
      "weekly_start_time": 1778457600000,
      "weekly_end_time": 1779062400000,
      "weekly_remains_time": 444241883
    }
  ],
  "base_resp": { "status_code": 0, "status_msg": "success" }
}

• current_interval_usage_count = 151 → if USED: 10.1% | if REMAINING: 89.9%

ENDPOINT 2 — platform.minimax.io/v1/api/openplatform/coding_plan/remains (my usage script uses this):

{
  "model_remains": [
    {
      "start_time": 1778616000000,
      "end_time": 1778630400000,
      "remains_time": 12241883,
      "current_interval_total_count": 1500,
      "current_interval_usage_count": 1349,
      "model_name": "MiniMax-M*",
      "current_weekly_total_count": 0,
      "current_weekly_usage_count": 0,
      "weekly_start_time": 1778457600000,
      "weekly_end_time": 1779062400000,
      "weekly_remains_time": 444241883
    }
  ],
  "base_resp": { "status_code": 0, "status_msg": "success" }
}

• current_interval_usage_count = 1349 → if USED: 89.9% | if REMAINING: 10.1%

Neither endpoint matches the dashboard's 7% used.

3. usage_percent / usagePercent fields do not exist

Both MiniMax endpoints return no usage_percent or usagePercent fields:

Keys in api.minimax.io response: ['model_remains', 'base_resp']
Keys in platform.minimax.io response: ['model_remains', 'base_resp']

The REMAINING_PERCENT_KEYS = ["usage_percent", "usagePercent"] inversion code path in deriveUsedPercent() is never triggered for this provider — it is dead code for MiniMax. The bug lives entirely in the count-based path.

4. The count-based calculation is wrong

In deriveUsedPercent(), the count-based path is:

const total = pickNumber(payload, TOTAL_KEYS);         // 1500
let used = pickNumber(payload, USED_KEYS);             // undefined for MiniMax
const remaining = pickNumber(payload, REMAINING_KEYS); // undefined for MiniMax
if (used === void 0 && remaining !== void 0 && total !== void 0) used = total - remaining;
// falls through to:
const fromCounts = clampPercent(used / total * 100);    // wrong if used means REMAINING

current_interval_usage_count from /v1/token_plan/remains is semantically named but its meaning (used vs remaining) is not correct per the API contract for this endpoint.

The fix needed is either:

1. Option A (preferred): Add current_interval_usage_count to REMAINING_KEYS so the gateway derives used = total - remaining (treating it as remaining, not used). The MiniMax API convention for /v1/token_plan/remains appears to return remaining prompts, not used.

2. Option B: Add MiniMax-specific logic to the count-based path that interprets current_interval_usage_count as remaining for this provider specifically.

3. Option C: Switch the gateway to call platform.minimax.io/v1/api/openplatform/coding_plan/remains (which returns usage_count as used prompts) and verify the interpretation matches the dashboard.

What OpenClaw maintainers need to verify

1. Confirm the correct semantic meaning of current_interval_usage_count from /v1/token_plan/remains — does it mean used or remaining?
2. If it means REMAINING: add it to REMAINING_KEYS array so the existing used = total - remaining logic fires, removing the need for MiniMax-specific count handling
3. If it means USED: verify the correct endpoint is being called (platform vs api subdomain)
4. Add a fallback that cross-checks against both endpoints when they disagree significantly, to catch future API changes