fringe pewter
i run openclaw onboard, choose minimax api, choose global and enter the api key
now when i chat my bot in dashboard, it always return the error.
already done
I check the logs, but no error from Minimax (i guess?).
only shows
vale coralBOT
flint badgerBOT
Those two log lines are not the real error, they just mean OpenClaw marked the MiniMax attempt as failed and then did failover/cooldown.
First, can you paste these 3 outputs:
fallow joltopenclaw --version
openclaw models status --probe-provider minimax
openclaw status --all
Then do one more test while tailing logs:
openclaw logs --follow
Send one dashboard message, then paste the 10 to 20 log lines around the failure, especially anything showing status, reason, providerErrorType, or providerErrorMessagePreview.
Two useful checks from the docs:
minimax, not minimax-portal.api.minimax.io, CN should hit api.minimaxi.com, so a region/key mismatch is possible too.Please redact the API key itself, but leave the rest intact.
Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/gateway/troubleshooting
If models status --probe-provider minimax says auth, rate_limit, or billing, we’ll know the exact lane immediately.
flint badgerBOT
Yep, run that and paste the output here.
Also please include:
openclaw --version
If the probe says auth, rate_limit, or billing, that’s the real cause.
If it helps, the full set is:
openclaw --version
openclaw models status --probe-provider minimax
openclaw status --all
Redact the API key itself, but keep the rest.
fringe pewter
OpenClaw 2026.4.9 (0512059)
flint badgerBOT
Nice, version looks recent enough.
Now I need the actual MiniMax probe result:
openclaw models status --probe-provider minimax
And ideally this too:
openclaw status --all
The probe output is the important part, that will tell us whether this is:
Paste those two outputs and we can narrow it down fast.
fringe pewter
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : minimax/MiniMax-M2.7
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : Minimax -> minimax/MiniMax-M2.7
Configured models (1): minimax/MiniMax-M2.7
Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -
OAuth/token status
flint badgerBOT
This is helpful, the config itself looks fine. OpenClaw is loading MiniMax correctly and using:
minimax/MiniMax-M2.7So the problem is probably not onboarding/config write failure.
One thing jumps out though: your MiniMax key looks like sk-cp-.... That usually looks like a Coding Plan key, not the normal chat API key.
Why that matters:
minimax/MiniMax-M2.7 chat uses the normal MiniMax API-key pathDocs:
https://docs.openclaw.ai/providers/minimax
https://docs.openclaw.ai/tools/minimax-search
So I’d check this first:
openclaw onboard --auth-choice minimax-global-oauth
openclaw models status --probe-provider minimax
My current guess is: wrong MiniMax key type, which then gets surfaced through OpenClaw’s generic failover/rate-limit message.
fringe pewter
yes, thats a coding plan key, previously i can use that just fine
only today suddenly it doesn't work, is this a new limitation?
flint badgerBOT
I can’t confirm if MiniMax changed something today, but from the current docs, a Coding Plan key is not the supported credential for MiniMax chat models.
Current documented split is:
sk-cp-...): MiniMax Search / usage endpointsminimax/MiniMax-M2.7: normal MiniMax API key (sk-...)So if sk-cp-... used to work for chat, I’d treat that as a compatibility path that stopped being reliable, not a stable supported contract.
Recommended fix:
openclaw onboard --auth-choice minimax-global-oauth
Then check:
openclaw models status
After that, I’d expect your default to move to:
minimax-portal/MiniMax-M2.7
Docs:
https://docs.openclaw.ai/providers/minimax
https://docs.openclaw.ai/tools/minimax-search
If you want, paste the new openclaw models status after switching to OAuth and I’ll sanity-check it.
fringe pewter
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : minimax-portal/MiniMax-M2.7
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (2) : minimax-m2.7 -> minimax-portal/MiniMax-M2.7, minimax-m2.7-highspeed -> minimax-portal/MiniMax-M2.7-highspeed
Configured models (2): minimax-portal/MiniMax-M2.7, minimax-portal/MiniMax-M2.7-highspeed
Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): minimax-portal (1)
OAuth/token status
flint badgerBOT
This looks much better. OAuth is set up correctly now, and your default is:
minimax-portal/MiniMax-M2.7
So the remaining likely issue is one of these:
Next thing I’d do:
Or run /new / /reset in the current one, then test again.
/model status
It should show minimax-portal/MiniMax-M2.7.
openclaw models status --probe-provider minimax-portal
Your pasted status still shows the old minimax API-key profile exists too, but your default is now minimax-portal, so that probe is the one that matters.
If you paste:
/model status from the dashboard chatopenclaw models status --probe-provider minimax-portalwe should be able to pin this down pretty fast.
fringe pewter
when i try /new or /reset, it returns ⚠️ API rate limit reached. Please try again later.
from /model status
Current: minimax-portal/MiniMax-M2.7
Default: minimax-portal/MiniMax-M2.7
Agent: kate
Auth file: ~/.openclaw/agents/kate/agent/auth-profiles.json
[minimax-portal] endpoint: https://api.minimax.io/anthropic auth: minimax-portal:default=OAuth (next, exp 365d) (auth-profiles.json: ~/.openclaw/agents/kate/agent/auth-profiles.json)
• minimax-portal/MiniMax-M2.7 (minimax-m2.7)
• minimax-portal/MiniMax-M2.7-highspeed (minimax-m2.7-highspeed)
openclaw models status --probe-provider minimax-portal
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : minimax-portal/MiniMax-M2.7
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (2) : minimax-m2.7 -> minimax-portal/MiniMax-M2.7, minimax-m2.7-highspeed -> minimax-portal/MiniMax-M2.7-highspeed
Configured models (2): minimax-portal/MiniMax-M2.7, minimax-portal/MiniMax-M2.7-highspeed
Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): minimax-portal (1)
OAuth/token status
flint badgerBOT
Aha, I think we found the mismatch.
Your dashboard session is using agent kate:
Agent: kate
Auth file: ~/.openclaw/agents/kate/agent/auth-profiles.json
But the CLI output you pasted is for main:
Agent dir : ~/.openclaw/agents/main/agent
So we’ve been checking the wrong agent.
Please run these against kate specifically:
openclaw models status --agent kate
openclaw models status --agent kate --probe-provider minimax-portal
That should inspect the same auth/model state the dashboard is actually using.
My guess now is: main is fine, but kate has stale/bad MiniMax auth or provider state.
Paste those 2 outputs and we should be very close.
fringe pewter
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/kate/agent
Default (defaults): minimax-portal/MiniMax-M2.7
Fallbacks (0) (defaults): -
Image model (defaults): -
Image fallbacks (0) (defaults): -
Aliases (2) : minimax-m2.7 -> minimax-portal/MiniMax-M2.7, minimax-m2.7-highspeed -> minimax-portal/MiniMax-M2.7-highspeed
Configured models (2): minimax-portal/MiniMax-M2.7, minimax-portal/MiniMax-M2.7-highspeed
Auth overview
Auth store : ~/.openclaw/agents/kate/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): minimax-portal (1)
OAuth/token status
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/kate/agent
Default (defaults): minimax-portal/MiniMax-M2.7
Fallbacks (0) (defaults): -
Image model (defaults): -
Image fallbacks (0) (defaults): -
Aliases (2) : minimax-m2.7 -> minimax-portal/MiniMax-M2.7, minimax-m2.7-highspeed -> minimax-portal/MiniMax-M2.7-highspeed
Configured models (2): minimax-portal/MiniMax-M2.7, minimax-portal/MiniMax-M2.7-highspeed
Auth overview
Auth store : ~/.openclaw/agents/kate/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): minimax-portal (1)
OAuth/token status
flint badgerBOT
Yep, this is the weird bit.
Even with --agent kate, the effective MiniMax auth is still resolving from main:
- minimax-portal effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json
But auth is supposed to be per-agent. So I don’t think this is just a normal MiniMax quota problem anymore, I think kate is not actually using its own auth store cleanly.
This FAQ section matches pretty closely:
https://docs.openclaw.ai/help/faq#no-api-key-found-for-provider-after-adding-a-new-agent
Can you check whether kate really has the MiniMax OAuth profile in its own auth file?
grep -n "minimax-portal" ~/.openclaw/agents/kate/agent/auth-profiles.json
grep -n "minimax-portal" ~/.openclaw/agents/main/agent/auth-profiles.json
If kate does not contain it, then the fix is to reconfigure auth for kate specifically.
If kate does contain it, but openclaw models status --agent kate still says the effective profile comes from main, then I’d call that bug territory, not user error.
At this point I’m pretty confident the issue is agent auth resolution for kate, not just MiniMax itself.
You actually gave enough already. This is the smoking gun:
Agent dir: ~/.openclaw/agents/kate/agent~/.openclaw/agents/main/agent/auth-profiles.jsonThat is not what I’d expect. At this point I do not think this is a real MiniMax rate limit problem anymore. It looks like an agent auth-store mismatch for kate.
So I’d do one of these:
main agent in dashboard for now, if available.kate so it has its own MiniMax OAuth auth profile in ~/.openclaw/agents/kate/agent/auth-profiles.json.kate still resolves auth from main after recreating/reconfiguring it, I’d call that a bug and file an issue:Relevant FAQ:
https://docs.openclaw.ai/help/faq#no-api-key-found-for-provider-after-adding-a-new-agent
So my read is:
kate auth resolution is broken/misalignedIf you want, I can help you write a tight GitHub issue with the exact evidence from this thread.
fringe pewter
9: "minimax-portal:default": {
11: "provider": "minimax-portal",
9: "minimax-portal:default": {
11: "provider": "minimax-portal",
Kate has it
flint badgerBOT
Yep, that confirms it.
kate does have minimax-portal:default in its own auth file, but openclaw models status --agent kate still resolves the effective MiniMax auth from main.
That should not happen. I’m pretty confident this is a bug, not your config.
Workaround for now: use the main agent if you can.
Next step: file a GitHub issue here:
https://github.com/openclaw/openclaw/issues
You can paste this as the issue body:
Title:
Agent-specific MiniMax auth resolves from main agent auth-profiles.json
OpenClaw version:
2026.4.9 (0512059)
What I did:
- configured MiniMax OAuth
- dashboard session uses agent `kate`
- `/model status` shows:
- Current: minimax-portal/MiniMax-M2.7
- Agent: kate
- Auth file: ~/.openclaw/agents/kate/agent/auth-profiles.json
What I expected:
- `kate` should resolve MiniMax auth from ~/.openclaw/agents/kate/agent/auth-profiles.json
What actually happens:
- `openclaw models status --agent kate` shows:
- Auth store: ~/.openclaw/agents/kate/agent/auth-profiles.json
- but effective MiniMax auth resolves from:
~/.openclaw/agents/main/agent/auth-profiles.json
Extra confirmation:
- `~/.openclaw/agents/kate/agent/auth-profiles.json` does contain:
- minimax-portal:default
- provider: minimax-portal
Symptom:
- dashboard chat, `/new`, and `/reset` return:
- ⚠️ API rate limit reached. Please try again later.
- logs mention:
- auth profile failure state updated
- embedded run failover decision
If main works and kate fails, include that too, it makes the bug report even stronger.
flint badgerBOT
Got it, that changes the picture. If main also doesn’t work, then it’s probably not a kate-only auth-store issue.
At that point, this looks a lot more like the recent MiniMax / minimax-portal usage or auth classification bug territory.
I found a very similar existing issue:
Your case sounds close enough that I would comment on #52335 or file a new issue referencing it, with these extra details:
2026.4.9main and kate fail/new and /reset also return ⚠️ API rate limit reached/model status shows minimax-portal/MiniMax-M2.7minimax-portal:default ok expires in 365dSo, I would stop re-running onboarding at this point. I don’t think this is just local misconfiguration anymore.
Temporary workaround: use another provider for now, or try a real MiniMax direct API key (sk-...) instead of minimax-portal if you have one.
If you want, I can rewrite your evidence into a shorter comment for #52335.
Easiest way:
openclaw logs --follow
Then, in another terminal or browser tab, send one test message in the dashboard.
Watch the log output and paste the lines around the failure.
What to look for specifically:
httpCodeproviderErrorTypeproviderErrorMessagePreviewfailoverReasonstatusIf openclaw logs --follow does not show anything, try the file log directly:
tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
If you want a one-shot report instead of live tailing:
openclaw status --all
Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/gateway/troubleshooting
Paste about 10 to 20 lines around the failing request, that’s usually enough.
fringe pewter
i found something
warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"cde39a2c-c718-4ccd-91ec-9b10f0e89ce0","isError":true,"error":"⚠️ The Token Plan is designed for individual, interactive developer workflows. Traffic is currently high—please retry shortly. For higher concurrency or automated workloads, consider upgrading to a higher-tier plan or using the pay-as-you-go API. (2062)","failoverReason":"rate_limit","model":"MiniMax-M2.7","provider":"minimax-portal","rawErrorPreview":"429 {"type":"error","error":{"type":"rate_limit_error","message":"The Token Plan is designed for individual, interactive developer workflows. Traffic is currently high—please retry shortly. For higher concurrency or automated workloads, consider upgrading to a higher-tier plan or using the pay-as-you-go API. (2062)"},"request_id":"sha256:e4ff9124f1e1"}","rawErrorHash":"sha256:603528b4cbd3","rawErrorFingerprint":"sha256:1bc7dcf49b36","httpCode":"429","providerErrorType":"rate_limit_error","providerErrorMessagePreview":"The Token Plan is designed for individual, interactive developer workflows. Traffic is currently high—please retry shortly. For higher concurrency or automated workloads, consider upgrading to a highe…","requestIdHash":"sha256:e4ff9124f1e1"} embedded run agent end
11:21:05+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"cde39a2c-c718-4ccd-91ec-9b10f0e89ce0","isError":true,"error":"⚠️ API rate limit reached. Please try again later.","failoverReason":"rate_limit","model":"MiniMax-M2.7","provider":"minimax-portal","rawErrorPreview":"429 {"type":"error","error":{"type":"rate_limit_error","message":"usage limit exceeded (2056)"},"request_id":"sha256:0f42ba6c7e3a"}","rawErrorHash":"sha256:ba4ac171ddb5","rawErrorFingerprint":"sha256:b324c593703e","httpCode":"429","providerErrorType":"rate_limit_error","providerErrorMessagePreview":"usage limit exceeded (2056)","requestIdHash":"sha256:0f42ba6c7e3a"} embedded run agent end
flint badgerBOT
Nice, that’s the real cause.
MiniMax is returning a real 429 rate limit:
minimax-portalMiniMax-M2.7rate_limit_errorSo this is not an auth problem, and probably not an OpenClaw bug. OpenClaw was just collapsing the provider message into the generic:
⚠️ API rate limit reached. Please try again later.
Your MiniMax Token Plan / OAuth path is being throttled upstream.
You have 3 real options:
Retry later
This may be temporary traffic/concurrency throttling.
Use a higher-tier MiniMax plan or pay-as-you-go API
That is exactly what MiniMax is telling you in the error.
Switch provider/model for now
If you need the bot working immediately.
If you have a real MiniMax direct API key (sk-...), I’d try that instead of minimax-portal OAuth. That should avoid the Token Plan lane.
Honestly, I’m glad you found that log line, it clears things up a lot.
Yep, that confirms it 100%.
This is MiniMax rejecting the request upstream:
httpCode: 429provider: minimax-portalproviderErrorType: rate_limit_errorproviderErrorMessagePreview: usage limit exceeded (2056)So the real diagnosis is:
sk-...)So unfortunately, local OpenClaw fixes won’t solve this one.
Glad we pinned it down though. 🎯
If this fixed the diagnosis, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.
fringe pewter
i havent use my quota, i check the dashboard in minimax, stil 0/1500
flint badgerBOT
Ah, that’s a really important detail.
If MiniMax shows 0/1500 used, but the API still returns:
429usage limit exceeded (2056)Token Plan ... traffic is currently high ... (2062)then you’re probably hitting some other MiniMax limit/window, not the simple dashboard counter you’re looking at.
So the updated read is:
That lines up pretty well with this existing issue:
https://github.com/openclaw/openclaw/issues/52335
I’d comment there with exactly this new evidence:
usage limit exceeded (2056)Token Plan ... traffic is currently high ... (2062)minimax-portalMiniMax-M2.7So basically, you’re not crazy. The provider says “rate limited”, but the visible quota UI doesn’t match.
Best workaround right now: use a real MiniMax direct API key (sk-...) or another provider until MiniMax / OpenClaw side clarifies the Token Plan behavior.
If you want, I can write a short comment you can paste into #52335.
fringe pewter
okay write it
flint badgerBOT
Yep, paste this into #52335:
I'm seeing what looks like the same MiniMax Token Plan / minimax-portal issue on OpenClaw 2026.4.9 (0512059).
Setup:
- provider: minimax-portal (OAuth / Token Plan)
- model: minimax-portal/MiniMax-M2.7
- affected surfaces: dashboard chat, /new, /reset
- happens on both main and kate agents
What makes this confusing:
- MiniMax dashboard still shows 0/1500 used
- OAuth status in OpenClaw looks healthy
- but MiniMax returns real 429s upstream
Observed log lines:
1) 429 rate_limit_error: "The Token Plan is designed for individual, interactive developer workflows. Traffic is currently high—please retry shortly. For higher concurrency or automated workloads, consider upgrading to a higher-tier plan or using the pay-as-you-go API. (2062)"
2) 429 rate_limit_error: "usage limit exceeded (2056)"
Example log fields:
- provider: minimax-portal
- model: MiniMax-M2.7
- failoverReason: rate_limit
- httpCode: 429
- providerErrorType: rate_limit_error
So from the user side it looks like:
- visible MiniMax quota UI says unused
- but API calls through minimax-portal are still being throttled / rejected
This makes it look like there may be another MiniMax Token Plan window/concurrency limit, or a mismatch between what the MiniMax dashboard shows and what the API/OpenClaw path is enforcing.
If this ends up fixing it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.