#Cycled my main model api key, set it in .env, didn't change any other settings. Throwing 401.

29 messages · Page 1 of 1 (latest)

hot slate
#

Already restarted gateway and rebooted machine. Openclaw 2026.4.14. MiniMax

undone mauveBOT
#

Let me check the docs and source for the exact auth/env behavior before I guess.

#

Since you already restarted/rebooted, I’d stop looking at the daemon and look at which credential source OpenClaw is actually using.

Most likely one of these:

  1. Wrong .env location
    For a gateway/service install, the safe place is usually ~/.openclaw/.env, not a project/local .env.

  2. Wrong MiniMax auth path

    • API key setup: minimax/... + MINIMAX_API_KEY
    • OAuth setup: minimax-portal/...

  3. CN/global mismatch

    • global: api.minimax.io
    • China: api.minimaxi.com

Can you paste the redacted output of:

#

Don’t paste the actual key, just the redacted status output.

hot slate
#

it shows the env key name and the correct key in various places

undone mauveBOT
#

Ah, “various places” is actually a big clue.

OpenClaw’s env loading is precedence-based, and .env does not override an env var that already exists in the parent/service environment. So if the old MiniMax key is still present somewhere higher priority, the new .env value gets ignored.

That means the likely issue is one of:

  • old MINIMAX_API_KEY still set in the service environment
  • old key still coming from another env source
  • stale auth/config source still being selected instead of the .env one

Can you paste just the MiniMax bits from:

openclaw models status --json

I’m looking for:

hot slate
#

provider is minimax
env.source is env: MINIMAX_API_KEY
modelsJson.source is models.json (value is the correct key though)
auth.storePath is .openclaw/agents/main/agent/auth-profiles.json
auth.unusableProfiles has minimax:global and minimax:Default, both have a cooldown of about 10000 ms

undone mauveBOT
#

Let me check what those models status fields actually mean so I don’t send you in the wrong direction.

#

Yep, that’s the smoking gun.

Those auth.unusableProfiles entries mean OpenClaw is still trying the stored MiniMax auth profiles (minimax:global, minimax:Default), and they’re the ones getting 401’d and put on cooldown.

So even though your env key is correct, it’s probably not the credential actually winning first.

Safest fix:

openclaw capability model auth logout --provider minimax
openclaw gateway restart
openclaw models status

After that, MiniMax should resolve from the env/models config instead of the stale saved profiles.

A couple notes:

#
  • Don’t delete the whole auth-profiles.json if you have other providers in there.
  • The cooldown is just the symptom, not the root cause.

If it still 401s after the MiniMax profiles are cleared, then I’d check MiniMax global vs CN baseUrl next.
Docs: https://docs.openclaw.ai/help/faq , https://docs.openclaw.ai/providers/minimax

If you try that, paste the new MiniMax section from openclaw models status and I’ll keep going.

hot slate
#

i'm definitely using the right minimax url (global). I didn't change any settings and already had a working api key. all i did was reset it on their site and re-save it to .env

undone mauveBOT
#

I believe you, and honestly that still matches the evidence.

What your status output says is:

  • the new env key is visible (env: MINIMAX_API_KEY)
  • but OpenClaw is still attempting saved MiniMax profiles (minimax:global, minimax:Default)
  • those saved profiles are the ones getting 401 + cooldown

So this is probably not a URL/settings problem anymore. It looks like stored credential precedence.

In other words, changing .env did not fully replace the old saved MiniMax auth path.

I’d try exactly this:

openclaw capability model auth logout --provider minimax
# 
openclaw gateway restart

That is provider-scoped, so it should only clear the saved MiniMax auth, not your other providers.

Then test once more. If that fixes it, the old saved MiniMax profile was winning over the fresh env key.

If you want, paste the post-logout MiniMax bit from openclaw models status and I’ll sanity check it.

hot slate
#

i did that already and it didn't work

undone mauveBOT
#

I’m going one layer deeper here, because if clearing the saved profiles didn’t help, the problem is probably lower-level than auth-store precedence.

#

Got it. Then we’re past the easy precedence stuff.

At this point I don’t want to keep guessing. The next useful thing is the actual MiniMax response body.

Can you do this:

openclaw logs --follow

Then trigger one failing MiniMax request, and paste the MiniMax 401 block here, redacted.

If you want a clean repro without Discord/session noise, do it with:

openclaw infer model run --model minimax/MiniMax-M2.7 --prompt "hi" --json
#

while logs --follow is open.

Why I’m asking: a MiniMax 401 can be a few different things, for example:

  • key truly rejected
  • account/billing state surfaced as 401
  • auth/header mismatch on the request path

The response text will usually tell us which bucket it is.

Troubleshooting ref: https://docs.openclaw.ai/gateway/troubleshooting

Don’t paste the key itself, just the redacted error body.

hot slate
#

the infer script got a real response from the model

undone mauveBOT
#

Oh, that’s actually great news.

If openclaw infer model run --model minimax/MiniMax-M2.7 ... works, then:

  • the key is valid
  • the MiniMax endpoint is fine
  • the problem is now almost certainly in the gateway/chat session path, not MiniMax itself

So I’d check these next, in this order:

  1. In the failing Discord thread, run:

    /model status

    I want to see the active model, active agent, and auth store path for the actual chat session.

  2. Then start a fresh session in that thread:

# 
   /new

or

/reset

and try again.

Why I’m pushing that: this now smells like session/agent drift or stale session state, not a bad API key.

If infer works but chat doesn’t, the chat thread may be:

  • pinned to a different agent/model than you think
  • holding stale session state after the auth failures
  • using a different gateway/runtime context than your CLI test

If you paste the /model status output from the failing thread, I can narrow it down fast.

hot slate
#

Current: minimax/MiniMax-M2.7
Default: minimax/MiniMax-M2.7
Agent: main
Auth file: ~/.openclaw/agents/main/agent/auth-profiles.json

[google] endpoint: https://generativelanguage.googleapis.com/v1beta api: google-generative-ai auth: google:default=${GEMINI...API_KEY} (next, lastGood) (auth-profiles.json: ~/.openclaw/agents/main/agent/auth-profiles.json)
• google/gemini-flash-latest (Gemini Flash)

[groq] endpoint: https://api.groq.com/openai/v1 api: openai-completions auth: groq:default=${...Y} (next, lastGood) (auth-profiles.json: ~/.openclaw/agents/main/agent/auth-profiles.json)
• groq/llama-3.3-70b-versatile (Groq Llama)

[local] endpoint: http://127.0.0.1:8081/v1 api: openai-completions auth: local-ll...back-key (models.json: ~/.openclaw/agents/main/agent/models.json)
• local/qwen2.5-1.5b-instruct-q4_k_m.gguf

[minimax] endpoint: https://api.minimax.io/anthropic api: anthropic-messages auth: XXXplaintext_old_keyXXX (env: MINIMAX_API_KEY)
• minimax/MiniMax-M2.7 (Minimax)

[openrouter] endpoint: https://openrouter.ai/api/v1 api: openai-completions auth: openrouter:default=${OPENRO...API_KEY} (next, lastGood) (auth-profiles.json: ~/.openclaw/agents/main/agent/auth-profiles.json)
• openrouter/openrouter/free

undone mauveBOT
#

Aha, we found it. I’m checking the docs/source for the exact service-env behavior so I can point you at the clean fix, not just wave at it.

#

Nice, we found it.

That /model status output is the proof:

  • the chat runtime is using env: MINIMAX_API_KEY
  • but the value it shows is still the old plaintext key

So the problem is not MiniMax anymore. It’s that the gateway service is still running with an old MINIMAX_API_KEY in its environment.

That also explains why infer worked: your CLI test saw the new key, but the long-running gateway process did not.

I’d do this:

openclaw gateway install --force
openclaw gateway restart
#

Important: run that from the same profile / same environment you want the service to use, with the new key in ~/.openclaw/.env.

Why: OpenClaw’s .env does not override an already-existing service env var, and gateway install --force is the clean way to refresh the service environment.

Docs:
https://docs.openclaw.ai/help/faq#env-vars-and-env-loading
https://docs.openclaw.ai/help/faq#why-does-openclaw-gateway-status-show-config-cli-and-config-service-different

After that, run /model status again in the thread. If it still shows the old masked key, there’s still another stale MINIMAX_API_KEY source winning somewhere.

hot slate
#

that worked.

#

discord won't let me mark as solution though (error)

undone mauveBOT
#

Nice, glad we caught it. 🎉

Root cause was the gateway service env still holding the old MINIMAX_API_KEY, so the running chat path and your CLI were seeing different keys.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
That helps Answer Overflow index it for the next person.