stuck nimbusBOT
That warning is usually just a stale config entry, not a fatal error.
Can you paste this first so we can confirm behavior by version?
openclaw --version
Then clean the stale entry and retry:
openclaw config unset plugins.entries.minimax
openclaw configure
If you also have older MiniMax plugin aliases, clean those too:
openclaw config unset plugins.entries.minimax-portal-auth
After that, set/select MiniMax again in configure.
If MiniMax still doesn’t show up, we’ll check openclaw models status next.
Docs:
set/unset): https://docs.openclaw.ai/cli/config
real sierra
im using OpenClaw 2026.3.13
i have updated the config and configure minimax again. tried sending a message and seeing these errors in logs
11:27:54 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"96649c31-41c8-4b2d-a221-6179597e974b","isError":true,"error":"LLM request timed out.","failoverReason":"timeout","model":"MiniMax-M2.5","provider":"minimax","rawErrorPreview":"Request timed out.","rawErrorHash":"sha256:98123ccc6904"} embedded run agent end
11:27:54 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","fallback_model"],"runId":"96649c31-41c8-4b2d-a221-6179597e974b","stage":"assistant","decision":"fallback_model","failoverReason":"timeout","profileFailureReason":null,"provider":"minimax","model":"MiniMax-M2.5","profileId":"sha256:d347a6986db6","fallbackConfigured":true,"timedOut":false,"aborted":false,"status":408,"rawErrorPreview":"Request timed out.","rawErrorHash":"sha256:98123ccc6904"} embedded run failover decision
11:27:54 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=31749 error="FailoverError: LLM request timed out."
11:27:54 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:telegram:group:-1003854668978:topic:1 durationMs=31753 error="FailoverError: LLM request timed out."
stuck nimbusBOT
Nice, thanks for the version + logs — this is now a runtime timeout, not the stale plugin warning.
Two important clues from your logs:
status: 408, Request timed out)Try this exact reset flow:
openclaw models set minimax/MiniMax-M2.7
openclaw config set agents.defaults.model.fallbacks '[]' --strict-json
openclaw gateway restart
Then verify:
openclaw models status
openclaw config get agents.defaults.model
Also check your MiniMax endpoint is correct (global vs CN), and API mode is anthropic:
openclaw config get models.providers.minimax.baseUrl
openclaw config get models.providers.minimax.api
Expected:
baseUrl: https://api.minimax.io/anthropic (or CN: https://api.minimaxi.com/anthropic)api: anthropic-messagesIf it still times out, run a live provider probe and paste output:
openclaw models status --probe --probe-provider minimax --probe-timeout 120000
Docs:
Yep — that’s another stale plugin key from older config.
Run this cleanup:
openclaw config unset plugins.entries.minimax-portal-auth
openclaw config unset plugins.entries.minimax
openclaw gateway restart
If warnings still appear, you likely also have stale IDs in allow/deny lists. Check:
openclaw config get plugins.allow
openclaw config get plugins.deny
If either contains minimax-portal-auth (or old MiniMax IDs), remove them from those arrays in ~/.openclaw/openclaw.json.
Then verify model is really set:
openclaw models status
(That warning is noisy but usually non-fatal; command often still succeeds.)
Docs:
https://docs.openclaw.ai/cli/config
https://docs.openclaw.ai/providers/minimax
real sierra
11:51:52 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"c01fe3a7-3f28-4a28-99e8-5df930c8826b","isError":true,"error":"LLM request timed out.","failoverReason":"timeout","model":"MiniMax-M2.7","provider":"minimax","rawErrorPreview":"Request timed out.","rawErrorHash":"sha256:98123ccc6904"} embedded run agent end
stuck nimbusBOT
Perfect, this confirms you’re now on MiniMax-M2.7 — so config cleanup worked.
What’s left is just a timeout path.
Given this pattern, first check your run timeout:
openclaw config get agents.defaults.timeoutSeconds
If it’s 30 (or similarly low), increase it:
openclaw config set agents.defaults.timeoutSeconds 180 --strict-json
openclaw gateway restart
Then run a direct provider probe (to separate model auth/network from normal chat flow):
openclaw models status --probe --probe-provider minimax --probe-timeout 120000 --probe-max-tokens 256
If probe still times out, paste these too:
openclaw config get models.providers.minimax.baseUrl
openclaw config get models.providers.minimax.api
Expected:
baseUrl: https://api.minimax.io/anthropic (or CN https://api.minimaxi.com/anthropic)api: anthropic-messages
This is super helpful — and it explains everything.
Your probe is OK, but it took ~120s:
minimax/MiniMax-M2.7 ... ok · 120.4sSo auth/config is fine. The failures in chat are almost certainly because normal runs are timing out before MiniMax responds.
Set a higher agent timeout:
openclaw config set agents.defaults.timeoutSeconds 300 --strict-json
openclaw gateway restart
openclaw config get agents.defaults.timeoutSeconds
Then test again.
If you want faster responses, optionally switch to the highspeed tier:
openclaw models set minimax/MiniMax-M2.7-highspeed
Also, the tools.profile ... unknown entries warning is separate/noisy and not the cause of MiniMax auth/model failure.
Docs:
Yep — that Config path not found just means it isn’t explicitly set yet (defaults are in effect).
You can still set it.
Given your probe took ~120s, I’d do this combo:
openclaw config set agents.defaults.timeoutSeconds 300 --strict-json
openclaw config set agents.defaults.thinkingDefault "off"
openclaw models set minimax/MiniMax-M2.7-highspeed
openclaw gateway restart
Why: your MiniMax path is working, but it’s very slow; highspeed + lower thinking usually avoids these timeout failures.
If it still times out after that, it’s likely provider/runtime timeout behavior rather than auth/config. At that point, please file a bug with the probe output + logs here:
https://github.com/openclaw/openclaw/issues
Docs:
real sierra
still getting these errors
12:04:19 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"a717da72-8b9b-4ede-afb7-7b070f343352","isError":true,"error":"LLM request timed out.","failoverReason":"timeout","model":"MiniMax-M2.7-highspeed","provider":"minimax","rawErrorPreview":"Request timed out.","rawErrorHash":"sha256:98123ccc6904"} embedded run agent end
?
stuck nimbusBOT
Sorry — short version:
You did everything right. The remaining error is likely a MiniMax timeout bug/path, not your config.
Try this one command now:
openclaw models set minimax-portal/MiniMax-M2.7-highspeed
If it still times out after that, use your previous working model temporarily and open an issue here (include your probe output + one timeout log):
https://github.com/openclaw/openclaw/issues
If you want, I can draft the exact issue text for you to paste.
real sierra
why sometimes minimax/MiniMax-M2.7 and sometimes its minimax-portal/MiniMax-M2.7
real sierra
why sometimes minimax/MiniMax-M2.7 and sometimes its minimax-portal/MiniMax-M2.7
stuck nimbusBOT
Great question — they’re two different provider IDs for MiniMax:
minimax/... = MiniMax via API key flow (MINIMAX_API_KEY)minimax-portal/... = MiniMax via Portal/OAuth (Coding Plan) flowSame model family, different auth/backend path in OpenClaw.
That’s why you may see both if both auth methods are configured.
If you want consistency, pick one and stick to it as primary:
openclaw models set minimax-portal/MiniMax-M2.7
# or
openclaw models set minimax/MiniMax-M2.7
Then confirm with:
openclaw models status