[Bug] remains_time drains passively without API calls + cache-read discount not verifiable in Token Plan Plus

[juancspjr]

Environment

Field	Value
Plan	Token Plan Plus ($20/month)
Model	MiniMax-M3
Interface	Claude Code CLI (Anthropic-compatible endpoint)
Date	2026-06-02
Endpoints tested	https://www.minimax.io/v1/token_plan/remains / https://api.minimax.io/v1/chat/completions

---

Bug 1 — CRITICAL: remains_time drains passively (no API calls made)

The remains_time field in /v1/token_plan/remains decreases continuously
even when zero API calls are being made. This strongly suggests
remains_time is a real-time countdown timer, not a token-consumption
counter — which is not documented anywhere.

Measured evidence (raw timestamps from log):

Timestamp (UTC)	Event	remains_time	Delta
23:11:05	Snapshot — NO call	2,933,989	baseline
23:11:29	Snapshot — NO call	2,910,400	−23,589 ms in 24s
23:11:40	POST test call (192 tokens)	2,899,177	−11,223 ms
23:11:47	Snapshot — NO call	2,891,691	−7,486 ms in 7s
23:12:04	POST 2 long calls (701 tokens each)	2,875,313	−16,378 ms

Between 23:11:05 → 23:11:29 (24 seconds, ZERO API calls):
remains_time dropped 23,589 ms

Between 23:11:40 → 23:11:47 (7 seconds, ZERO API calls):
remains_time dropped 7,486 ms

Expected behavior: remains_time should only decrease when tokens
are consumed via API calls, not as a real-time countdown.

Actual behavior: Balance drains continuously regardless of usage.

Impact: Token Plan Plus ($20/month) exhausted in ~4–5 hours of
agentic coding work (Claude Code + MiniMax-M3), making it unusable
for professional AI-assisted development. Extrapolated rate: the
5-hour window would exhaust in ~50 minutes under continuous agent load.

---

Bug 2 — Cache-read discount not verifiable (Transparency Bug)

The API correctly reports cached_tokens in the response body,
confirming the cache is active at the inference level. However, there
is no way to verify whether the published 10:1 cache discount
($0.03/M cache-read vs $0.30/M input) is actually applied to
Token Plan balance deductions.

Evidence — Two identical calls, vastly different cache rates:

Call A — LONG_CALL_1 (first call):

{
  "id": "066e963b985425f3648a2e5f8ed6bee3",
  "usage": {
    "total_tokens": 701,
    "prompt_tokens": 681,
    "completion_tokens": 20,
    "prompt_tokens_details": {
      "cached_tokens": 114
    }
  }
}

→ 16.7% of prompt was cached

Call B — LONG_CALL_2 (identical repeat, seconds later):

{
  "id": "066e9642367623db33cb5a8d7bc40a48",
  "usage": {
    "total_tokens": 701,
    "prompt_tokens": 681,
    "completion_tokens": 20,
    "prompt_tokens_details": {
      "cached_tokens": 667
    }
  }
}

→ 97.9% of prompt was cached

Expected cost difference (per published MiniMax pricing):

	Call A	Call B
Non-cached input tokens	567 @ $0.30/M	14 @ $0.30/M
Cache-read tokens	114 @ $0.03/M	667 @ $0.03/M
Completion tokens	20 @ $1.20/M	20 @ $1.20/M
Expected cost	~197.5 µUSD	~48.2 µUSD
Expected ratio	4.10x more expensive	baseline

Problem: The remains_time deduction for both calls combined
(16,378 ms) cannot be audited per-call, and there is no way to
confirm Call B was charged 4x less than Call A. The balance
endpoint provides no per-call history.

---

Bug 3 — Missing billing fields in API response

Other providers expose cache billing explicitly for auditability.
MiniMax M3 only returns cached_tokens as informational metadata,
but does not expose the fields needed to verify billing:

Current MiniMax response:

"prompt_tokens_details": {
  "cached_tokens": 114
}

What Anthropic exposes (industry standard):

"usage": {
  "cache_creation_input_tokens": N,
  "cache_read_input_tokens": N,
  "input_tokens": N,
  "output_tokens": N
}

Requested addition to MiniMax response:

"prompt_tokens_details": {
  "cached_tokens": N,
  "cache_read_input_tokens": N,       ← ADD: billable cache reads
  "cache_creation_input_tokens": N,   ← ADD: cache write cost
  "non_cached_input_tokens": N        ← ADD: regular input cost
}

---

Steps to Reproduce

For Bug 1 (passive drain):

export KEY="your-token-plan-subscription-key"

# Snapshot 1
curl -s 'https://www.minimax.io/v1/token_plan/remains' \
  -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json'

# Wait 30 seconds — make NO API calls

# Snapshot 2
curl -s 'https://www.minimax.io/v1/token_plan/remains' \
  -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json'

# Observe: remains_time has decreased despite zero token consumption

For Bug 2 (cache discount not verifiable):

# Call 1 — note cached_tokens
curl -s 'https://api.minimax.io/v1/chat/completions' \
  -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"MiniMax-M3","messages":[{"role":"user","content":"[500+ token prompt here]"}],"max_tokens":20}'

# Call 2 — identical prompt, should hit cache
# Same command as above — observe cached_tokens jumps from ~17% to ~98%
# Then check remains_time — no way to verify 4x cost difference was applied

---

Related Issues

• Claude Code CLI continuously times out on all versions when using MiniMax Anthropic API #44 — Claude Code CLI timeouts on MiniMax Anthropic API
• API Error: 400 invalid params - chat content has invalid message role: system (2013) in Claude Code CLI v2.1.156 using Minimax Anthropic API #43 — API Error 400 invalid message role with Claude Code CLI
• Unauthorized Charge - Refund Request #42 — Unauthorized charge / refund request
• [Bug]: minimax-portal OAuth usage tracker reports "0% left" despite full MiniMax balance — blocks Discord but CLI works openclaw/openclaw#52335 — usage tracker reports 0% left incorrectly

---

Questions for MiniMax Team

1. Is remains_time a real-time countdown or a token-consumption counter?
   If it is time-based, what is the documented conversion to tokens/USD?
2. Does the 10:1 cache discount apply to Token Plan subscriptions?
   If yes, why does the remains_time deduction not reflect this?
3. Will cache_read_input_tokens be added to the API response body?
4. Will a per-call billing breakdown be added to the Token Plan dashboard?

---

Full API log with all raw JSON responses available upon request.
Tested on: Ubuntu 22.04 / curl 7.81 / Token Plan Plus $20/month

minimax_evidence_REDACTED.log

[juancspjr]

Additional Evidence — June 3, 2026 (Anthropic SDK independent test)

Tested cache_read_input_tokens via Anthropic-compatible endpoint using
the official anthropic Python SDK directly (not through Claude Code CLI).

Test script

import anthropic, os, time

client = anthropic.Anthropic(
    base_url="https://api.minimax.io/anthropic",
    api_key=os.environ["MINIMAX_API_KEY"]
)

SYSTEM = "Eres un asistente experto en Python. Responde siempre en español."

def call(label):
    r = client.messages.create(
        model="MiniMax-M3",
        max_tokens=100,
        system=SYSTEM,
        messages=[{"role": "user", "content": "¿Qué es un decorador en Python?"}]
    )
    u = r.usage
    print(f"input: {u.input_tokens} | output: {u.output_tokens} | "
          f"cache_read: {getattr(u, 'cache_read_input_tokens', 'N/A')} | "
          f"cache_creation: {getattr(u, 'cache_creation_input_tokens', 'N/A')}")

call("Call 1"); time.sleep(2)
call("Call 2"); time.sleep(2)
call("Call 3")

Results — 3 identical consecutive calls

--- Call 1 (first ever, no cache exists) ---
input: 78 | output: 100 | cache_read: 114 | cache_creation: 0

--- Call 2 (should read cache) ---
input: 78 | output: 100 | cache_read: 114 | cache_creation: 0

--- Call 3 (confirm consistency) ---
input: 78 | output: 100 | cache_read: 114 | cache_creation: 0

Results — Short vs Long prompt

Short prompt "Hola":
input: 71 | output: 65 | cache_read: 114

Long prompt (300+ words, full Python explanation):
input: 113 | output: 500 | cache_read: 114

Critical findings

Finding	Why it's impossible
cache_read: 114 on 1st ever call	No cache exists yet, must be 0
cache_read: 114 identical across all 3 calls	Real cache reads vary with content
cache_read (114) > input_tokens (71) on short prompt	Cannot read more tokens from cache than the entire prompt contains
cache_creation: 0 always	Cache is never being created, yet cache_read is always 114

Conclusion: cache_read_input_tokens is returning a hardcoded
default value (114) regardless of actual cache state. This confirms
the field does not reflect real token consumption and billing
based on it cannot be verified or trusted.

Tested on: Ubuntu 22.04 / Python 3.10 / anthropic SDK 0.51.0 / Token Plan Plus

[nimitbhardwaj]

Confirming Bug 1 on Token Plan Plus (yearly upgrade path) — same total_count: 0 + passive drain pattern

Hitting the exact same symptom as in #47 on a yearly upgrade path. Quick data dump for triage.

Plan: Plus yearly ($200/yr) — was on Starter yearly ($100/yr) before, upgraded 2 Jun 2026
Model: general (Claude Code CLI on the Anthropic-compatible endpoint)
Subscription Key: confirmed working for chat/completions

Probe 1 — passive drain reproduced (no usage, 30s gap)

remains_time:                 4,886,524
weekly_remains_time:          364,886,524
current_interval_total_count: 0
current_interval_usage_count: 0
current_weekly_total_count:   0
current_weekly_usage_count:   0

30 seconds later, zero calls:

remains_time:                 4,856,204   (-30,320 ms in 30s)
weekly_remains_time:          364,856,204 (-30,320 ms in 30s)
current_interval_usage_count: 0           (unchanged)

Probe 2 — same drain, after real LLM usage between the snapshots

remains_time:                 4,355,685
current_interval_total_count: 0
current_interval_usage_count: 0   <-- I used the API between probes, still 0

30 seconds later, zero calls:

remains_time:                 4,325,211   (-30,474 ms in 30s)
current_interval_usage_count: 0           (still 0)

What this adds on top of your report

• Reproduced on a yearly subscription, not monthly.
• current_interval_total_count: 0 and current_weekly_total_count: 0 on every snapshot. There is no quota pool allocated to this account's "general" model at all.
• current_interval_usage_count: 0 even after actively calling the API between probes — consumption is not being recorded on the general model.
• The current_interval_remaining_percent (13–14%) is a derived value off remains_time, not a real entitlement calculation, so the dashboard's "remaining" bar is misleading.

Suspected additional bug

Looks like there may be a second, separate bug here on top of the passive remains_time drain: the Plus plan's quota was never provisioned to my account on the "general" model — total_count: 0 on both windows. Happy to file it as a separate issue if that would help triage; right now it is hard to tell from outside whether this is a provisioning failure (similar to #38) or whether the passive drain is dragging total_count to 0 by some accounting side effect.

What I have already done

• Filed a billing/provisioning ticket with api@minimax.io (today, 4 Jun 2026) attaching the same two probe outputs.
• The dashboard shows Plus yearly as my active subscription, so this is an API ↔ account provisioning mismatch, not a subscription visibility problem.

Let me know if you want a third probe with a longer sleep window, or if you want me to hit a non-general model (e.g. video) for comparison.

[joshleblanc]

The remains time fields are the time left in the interval. The 5 hour/weekly buckets. They're supposed to go down over time.

Here's an example that uses this data functionally

[juancspjr]

@nimitbhardwaj — Thank you for the independent confirmation on the
yearly plan. Your data adds critical detail: current_interval_usage_count
staying at 0 even after active API calls suggests the usage counter
itself may not be recording consumption correctly — which makes auditing
the drain even harder. I've cross-referenced your findings in the
description. Your separate issue #48 on the provisioning side is exactly
the right call.

@joshleblanc — Thanks for the clarification on the interval buckets.
That context is genuinely useful. To be precise about what I actually
observed vs what I inferred:

What is documented with timestamps:

• remains_time dropped 23,589 ms in 24 seconds with zero API calls
• remains_time dropped 7,486 ms in 7 seconds with zero API calls

What I cannot confirm:

• Whether the passive drain rate is identical during extended idle periods
• Whether remains_time drains at exactly 1,000 ms/second continuously

The core question that remains unanswered:
If remains_time is a time-based interval counter (as you describe),
this still raises three unresolved concerns:

1. Undocumented behavior — The Token Plan page describes the balance
   in token terms, not time terms. There is no published conversion rate
   between milliseconds and tokens/USD.

2. No per-call audit trail — Whether the drain is time-based or
   token-based, there is still no way to verify that the 10:1 cache
   discount ($0.03/M vs $0.30/M) is being applied to balance deductions.

3. Usage counter not recording — Per nimitbhardwaj's data,
   current_interval_usage_count stays at 0 even after active API usage,
   making it impossible to reconcile what drove the balance down.

Happy to run additional probes with longer idle windows if that helps
triage. Full raw log attached to the original report.