BUG with GLM-5 coldown with out any real coldown | Friends of the Crustacean 🦞🤝 | Page 1

neon ridge Feb 13, 2026, 9:14 PM

#

I have to use openclaw agents add (main) to authenticate again to be able to use the model but then after some certain amount of time it will get this

⚠️ Agent failed before reply: All models failed (2): zai/glm-5: 401 token expired or incorrect (auth) | zai/glm-4.7: 401 token expired or incorrect (auth).
Logs: openclaw logs --follow

I have checked my usage and I'm not even nearly to reach 100% of usage on glm platform

sweet fieldBOT Feb 13, 2026, 9:14 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

untold flaxBOT Feb 13, 2026, 9:16 PM

#

That error isn’t “cooldown/usage” — it’s straight auth failure from Z.AI:

zai/glm-5: 401 token expired or incorrect
zai/glm-4.7: 401 token expired or incorrect

Because both models fail the same way, the common cause is: the Z.AI credential OpenClaw is using is wrong (or it’s a short‑lived token, not an API key). OpenClaw may then put that profile into a temporary “cooldown/backoff” after repeated auth failures, which can look like a cooldown bug.

1) First: make sure you’re using a real Z.AI API key

OpenClaw’s zai provider expects a Z.AI API key (the ZAI_API_KEY, usually sk-...), not a web session token.

Docs: https://docs.openclaw.ai/providers/zai and https://docs.openclaw.ai/providers/glm

2) Check what the Gateway thinks your Z.AI auth is (and whether it’s in backoff)

Run these on the gateway host (the machine running the gateway service), then paste the output (redact secrets):

#

openclaw --version
openclaw gateway status
openclaw models status --probe-provider zai
openclaw models status --json

models status --json is especially useful: it shows which auth profiles exist and whether one is marked unusable/backoff.

Docs: https://docs.openclaw.ai/cli/models

3) Fix the most common cause: key is set in the wrong place / wrong user / wrong service env

If you’re running the Gateway as a daemon/service, your shell env and the service env can differ.

Recommended stable setup for Z.AI is one of these:

Put it in global ~/.openclaw/.env on the gateway host, or

#

Put it in config:

{
  env: { ZAI_API_KEY: "sk-..." }
}

Then restart the gateway:

openclaw gateway restart

Important nuance: OpenClaw does not override existing env vars (process env wins). So if your service already has an old/bad ZAI_API_KEY, updating .env/config won’t fix it until the service environment is corrected + restarted.

Docs: https://docs.openclaw.ai/help/environment (env precedence + “never override existing values”)

#

If you paste the outputs of the 4 commands above (especially gateway status + models status --json), I can tell you exactly whether this is (a) wrong token type, (b) wrong gateway host/user/profile, or (c) stale ZAI_API_KEY stuck in the service environment.

neon ridge Feb 13, 2026, 9:33 PM

#

🦞 OpenClaw 2026.2.12 (f9e444d) — I can't fix your code taste, but I can fix your build and your backlog.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : zai/glm-5
Fallbacks (2) : zai/glm-4.7, anthropic/claude-opus-4-6
Image model : -
Image fallbacks (0): -
Aliases (9) : minimax-m2.1 -> minimax-portal/MiniMax-M2.1, Minimax -> minimax/MiniMax-M2.1, GLM -> zai/glm-4.7, GLM-5 -> zai/glm-5, minimax-m2.1-lightning -> minimax-portal/MiniMax-M2.1-lightning, minimax-m2.5 -> minimax-portal/MiniMax-M2.5, minimax-m2.5-lightning -> minimax-portal/MiniMax-M2.5-lightning, ollama-local -> ollama/llama3.2-32k:limited, ollama-1b -> ollama/llama3.2:1b
Configured models (10): minimax-portal/MiniMax-M2.1, minimax/MiniMax-M2.1, zai/glm-4.7, zai/glm-5, google-gemini-cli/gemini-3-pro-preview, minimax-portal/MiniMax-M2.1-lightning, minimax-portal/MiniMax-M2.5, minimax-portal/MiniMax-M2.5-lightning, ollama/llama3.2-32k:limited, ollama/llama3.2:1b

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

minimax effective=env:sk-cp-MD...nfGvqtbk | env=sk-cp-MD...nfGvqtbk | source=env: MINIMAX_API_KEY
minimax-portal effective=env:sk-cp-MD...nfGvqtbk | env=sk-cp-MD...nfGvqtbk | source=env: MINIMAX_API_KEY | models.json=minimax-oauth | source=models.json: ~/.openclaw/agents/main/agent/models.json
ollama effective=models.json:ollama-local | models.json=ollama-local | source=models.json: ~/.openclaw/agents/main/agent/models.json
zai effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | zai:default=021e7ffd...ndxEHhD6 | models.json=zai:default | source=models.json: ~/.openclaw/agents/main/agent/models.json

Missing auth

anthropic Run claude setup-token, then openclaw models auth setup-token or openclaw configure.

OAuth/token status

#

{
"configPath": "/home/clawd/.openclaw/openclaw.json",
"agentDir": "/home/clawd/.openclaw/agents/main/agent",
"defaultModel": "zai/glm-5",
"resolvedDefault": "zai/glm-5",
"fallbacks": [
"zai/glm-4.7",
"anthropic/claude-opus-4-6"
],
"imageModel": null,
"imageFallbacks": [],
"aliases": {
"minimax-m2.1": "minimax-portal/MiniMax-M2.1",
"Minimax": "minimax/MiniMax-M2.1",
"GLM": "zai/glm-4.7",
"GLM-5": "zai/glm-5",
"minimax-m2.1-lightning": "minimax-portal/MiniMax-M2.1-lightning",
"minimax-m2.5": "minimax-portal/MiniMax-M2.5",
"minimax-m2.5-lightning": "minimax-portal/MiniMax-M2.5-lightning",
"ollama-local": "ollama/llama3.2-32k:limited",
"ollama-1b": "ollama/llama3.2:1b"
},
"allowed": [
"minimax-portal/MiniMax-M2.1",
"minimax/MiniMax-M2.1",
"zai/glm-4.7",
"zai/glm-5",
"google-gemini-cli/gemini-3-pro-preview",
"minimax-portal/MiniMax-M2.1-lightning",
"minimax-portal/MiniMax-M2.5",
"minimax-portal/MiniMax-M2.5-lightning",
"ollama/llama3.2-32k:limited",
"ollama/llama3.2:1b"
],
"auth": {
"storePath": "/home/clawd/.openclaw/agents/main/agent/auth-profiles.json",
"shellEnvFallback": {
"enabled": false,
"appliedKeys": []
},
"providersWithOAuth": [],
"missingProvidersInUse": [
"anthropic"
],
"providers": [
{
"provider": "minimax",
"effective": {
"kind": "env",
"detail": "sk-cp-MD...nfGvqtbk"
},
"profiles": {
"count": 0,
"oauth": 0,
"token": 0,
"apiKey": 0,
"labels": []
},
"env": {
"value": "sk-cp-MD...nfGvqtbk",
"source": "env: MINIMAX_API_KEY"
}
},
{
"provider": "minimax-portal",
"effective": {
"kind": "env",
"detail": "sk-cp-MD...nfGvqtbk"
},
"profiles": {
"count": 0,
"oauth": 0,
"token": 0,
"apiKey": 0,
"labels": []
},
"env": {
"value": "sk-cp-MD...nfGvqtbk",
"source": "env: MINIMAX_API_KEY"
},
"modelsJson": {
"value": "minimax-oauth",
"source": "models.json: ~/.openclaw/agents/main/agent/models.json"
}
},
{
"provider": "ollama",
"effective": {
"kind": "models.json",
"detail": "ollama-local"
},
"profiles": {
"count": 0,
"oauth": 0,
"token": 0,
"apiKey": 0,
"labels": []
},
"modelsJson": {
"value": "ollama-local",
"source": "models.json: ~/.openclaw/agents/main/agent/models.json"
}
},
{
"provider": "zai",
"effective": {
"kind": "profiles",
"detail": "~/.openclaw/agents/main/agent/auth-profiles.json"
},
"profiles": {
"count": 1,
"oauth": 0,
"token": 0,
"apiKey": 1,
"labels": [
"zai:default=021e7ffd...ndxEHhD6"
]
},
"modelsJson": {
"value": "zai:default",
"source": "models.json: ~/.openclaw/agents/main/agent/models.json"
}
}
],
"unusableProfiles": [],
"oauth": {
"warnAfterMs": 86400000,
"profiles": [
{
"profileId": "zai:default",
"provider": "zai",
"type": "api_key",
"status": "static",
"source": "store",
"label": "zai:default"
}

#

],
"providers": [
{
"provider": "anthropic",
"status": "missing",
"profiles": []
},
{
"provider": "google-gemini-cli",
"status": "missing",
"profiles": []
},
{
"provider": "minimax",
"status": "missing",
"profiles": []
},
{
"provider": "minimax-coding",
"status": "missing",
"profiles": []
},
{
"provider": "minimax-portal",
"status": "missing",
"profiles": []
},
{
"provider": "ollama",
"status": "missing",
"profiles": []
},
{
"provider": "openai-codex",
"status": "missing",
"profiles": []
},
{
"provider": "openrouter",
"sta

untold flaxBOT Feb 13, 2026, 9:34 PM

#

Your models status output is super helpful: OpenClaw is using one Z.AI API key profile (zai:default, stored in ~/.openclaw/agents/main/agent/auth-profiles.json). When you later see:

401 token expired or incorrect (auth)

…that’s coming from Z.AI rejecting the credential, not an OpenClaw “cooldown” / usage limit thing.

A few high-probability causes + what to do:

1) Make sure you’re using a Z.AI API key (long-lived), not a web/session token

Z.AI/GLM in OpenClaw expects ZAI_API_KEY / zai API key auth. OpenClaw does not have a token refresh flow for Z.AI—so if you pasted something short-lived, it’ll work briefly then die with “token expired”.

Docs: https://docs.openclaw.ai/providers/zai (and GLM overview: https://docs.openclaw.ai/providers/glm)

Fix: generate a fresh API key in the Z.AI console, then re-add it via:

#

openclaw onboard --auth-choice zai-api-key
# or non-interactive:
openclaw onboard --zai-api-key "<your key>"

2) Confirm the Gateway service is using the same config/state you’re editing (common gotcha)

If the daemon/service is running with a different profile/state dir than your CLI, you can end up “fixing” auth in one place while the Gateway is actually using another.

Please paste:

openclaw gateway status --deep

Specifically look for the “Config (cli)” vs “Config (service)” mismatch. If they differ, the docs recommend:

#

openclaw gateway install --force
openclaw gateway restart

Troubleshooting doc section: https://docs.openclaw.ai/gateway/troubleshooting

3) Check if OpenClaw has marked the ZAI profile temporarily unusable/backoff

When 401s happen repeatedly, OpenClaw can temporarily skip a profile (looks like “cooldown”).

Run and paste (redacting secrets is fine):

openclaw models status --json

Then we’ll look at auth.unusableProfiles and why it’s being skipped.

#

4) Side note: your Anthropic fallback can’t work right now

Your output shows:

Missing auth - anthropic ...

So if Z.AI fails, fallback will also fail until you configure Anthropic (or remove it as a fallback).

If you paste openclaw gateway status --deep + the openclaw models status --json snippet around auth.unusableProfiles, we can pin down whether this is (a) wrong token type, (b) config/service mismatch, or (c) Z.AI key getting revoked/rotated on their side.

#

From the JSON you pasted:

auth.unusableProfiles: [] → OpenClaw is not currently “cooling down” / backing off that Z.AI profile.
Your zai:default profile is type: "api_key" and status: "static" → OpenClaw is treating it as a non-refreshing key.

So if it works for a while and then later you start getting:

zai/glm-5: 401 token expired or incorrect

…that almost always means the credential you stored isn’t a long-lived API key (it’s some kind of access/session token) or the key is getting revoked/rotated on the Z.AI side.

What I’d do next (minimal + decisive)

Create a fresh Z.AI API key in the Z.AI console (not an access token), then re-add it to OpenClaw:

openclaw onboard --auth-choice zai-api-key

#

# or: openclaw onboard --zai-api-key "<new key>"

(You can also do openclaw models auth add and pick zai.)

Restart the gateway (so we know the running process picked it up):

openclaw gateway restart

When it fails again, immediately run:

openclaw models status --probe-provider zai
openclaw logs --follow

…and paste the probe output + the relevant log lines around the 401 (redact secrets).

#

One more important thing

Your fallback includes anthropic/claude-opus-4-6, but your status shows Anthropic auth is missing — so when Z.AI fails, OpenClaw can’t successfully fall back anyway (it’ll just produce more “all models failed” noise).

If you can paste openclaw gateway status --deep too, we can rule out the other classic issue (CLI writing auth to one state dir, gateway service running from another).

neon ridge Feb 13, 2026, 9:36 PM

#

Listening: 127.0.0.1:18789
Other gateway-like services detected (best effort):

openclaw.service (system, unit: /etc/systemd/system/openclaw.service)
Cleanup hint: systemctl --user disable --now openclaw-gateway.service
Cleanup hint: rm ~/.config/systemd/user/openclaw-gateway.service

Recommendation: run a single gateway per machine for most setups. One gateway supports multiple agents (see docs: /gateway#multiple-gateways-same-host).
If you need multiple gateways (e.g., a rescue bot on the same host), isolate ports + config/state (see docs: /gateway#multiple-gateways-same-host).

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
clawd@srv1318115:~$

untold flaxBOT Feb 13, 2026, 9:37 PM

#

That gateway status --deep output is the smoking gun: you’ve got two gateway services installed on the same machine:

a system unit: /etc/systemd/system/openclaw.service
a user unit: ~/.config/systemd/user/openclaw-gateway.service

When this happens, you can easily end up in a loop where you “fix auth” in the CLI (one state dir / one running gateway), but your messages are being handled by the other gateway instance (with a different auth store / old key) → then you see 401s “randomly later”.

Fix: run ONE gateway (recommended)

First, check which services are actually running:

systemctl is-active openclaw.service
systemctl --user is-active openclaw-gateway.service

systemctl status openclaw.service --no-pager | head -40
systemctl --user status openclaw-gateway.service --no-pager | head -40

#

Then pick one to keep (system or user) and stop/disable the other.

If you want to keep the system service (common on VPS), disable the user one:

systemctl --user disable --now openclaw-gateway.service
rm ~/.config/systemd/user/openclaw-gateway.service

(Those two lines match the “Cleanup hint” your gateway printed.)

After cleanup, re-check:

openclaw gateway status --deep

#

You should no longer see “Other gateway-like services detected”.

Why this matches your symptom

Your Z.AI key is stored in an agent auth store (~/.openclaw/agents/main/agent/auth-profiles.json). If gateway A is using that file but gateway B is not (different user/state/profile), it looks like “I have to authenticate again every so often”, and eventually one of them keeps hitting 401 token expired or incorrect.

Docs on multiple gateways (and why isolation matters): https://docs.openclaw.ai/gateway/multiple-gateways

Next thing to paste

Please paste the next openclaw gateway status --deep after you disable one of the services. The important lines are the ones that show the config/state paths the running service is actually using.

neon ridge Feb 13, 2026, 9:51 PM

#

Creo que ya se arreglo, como hago para ver si siguen otras gateways activas?

untold flaxBOT Feb 13, 2026, 9:51 PM

#

Para confirmar que no quedan otras Gateways activas (Linux + systemd), yo miraría 3 cosas: servicios systemd, procesos y puertos.

1) Ver servicios systemd (system + user)

# Servicios "del sistema" (root)
systemctl list-units --type=service | grep -i openclaw

# Servicios del usuario actual
systemctl --user list-units --type=service | grep -i openclaw

Y para ver si están activos:

systemctl is-active openclaw.service
systemctl --user is-active openclaw-gateway.service

#

(Si usas perfiles, pueden existir nombres tipo openclaw@rescue.service o similares, por eso el list-units es lo mejor.)

2) Ver procesos corriendo

ps aux | grep -i openclaw | grep -v grep

3) Ver quién está escuchando en el puerto del Gateway

Si tu gateway escucha en 127.0.0.1:18789:

ss -ltnp | grep 18789

Deberías ver solo un proceso escuchando ese puerto.

4) Check rápido desde OpenClaw

#

openclaw gateway status --deep

Si todavía detecta “Other gateway-like services…”, te lo vuelve a avisar ahí.

Si con esto ya solo aparece un servicio/proceso/puerto, estás bien.

Si esto te lo arregló del todo, marca el mensaje solución (click derecho al mensaje → Apps → ✅ Mark Solution) para que quede indexado.

neon ridge Feb 13, 2026, 10:24 PM

#

Me salio de nuevo el problema apesar de haber matado el gateway duplicado

⚠️ Agent failed before reply: All models failed (2): zai/glm-5: Provider zai is in cooldown (all profiles unavailable) (rate_limit) | zai/glm-4.7: Provider zai is in cooldown (all profiles unavailable) (rate_limit).

cessing new=idle reason="run_completed" queueDepth=0
22:20:18 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=0f97f2d7-567e-4ece-b707-7e70b753c703 totalActive=1
22:20:18 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=22736 error="FailoverError: ⚠️ minimax-portal returned a billing error — your API key has run out of credits or has an insufficient balance. Check your minimax-portal billing dashboard and top up or switch to a different API key."
22:20:18 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:support:telegram:direct:1172819123 durationMs=22748 error="FailoverError: ⚠️ minimax-portal returned a billing error — your API key has run out of credits or has an insufficient balance. Check your minimax-portal billing dashboard and top up or switch to a different API key."
22:20:18 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:support:telegram:direct:1172819123 queueSize=1
22:20:18 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:support:telegr

#

2:22:02 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=9 queueSize=0
22:22:02 error Embedded agent failed before reply: All models failed (2): zai/glm-5: LLM request timed out. (unknown) | zai/glm-4.7: No available auth profile for zai (all in cooldown or unavailable). (rate_limit)
22:22:02 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=32 error="FailoverError: No available auth profile for zai (all in cooldown or unavailable)."
22:22:02 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:telegram:direct:1172819123 durationMs=50 error="FailoverError: No available auth profile for zai (all in cooldown or unavailable)."
22:22:02 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ agent errorCode=UNAVAILABLE errorMessage=Error: All models failed (2): zai/glm-5: No available auth profile for zai (all in cooldown or unavailable). (rate_limit) | zai/glm-4.7: No available auth profile for zai (all in cooldown or unavailable). (rate_limit) runId=cb545d40-7b49-4030-96b1-79871368aea9 error=Error: All models failed (2): zai/glm-5: No available auth profile for zai (all in cooldown or unavailable). (rate_limit) | zai/glm-4.7: No available auth profile for zai (all in cooldown or unavailable). (rate_limit) conn=5c7c5ea9…cb7b id=c7d35780…8fcc
22:22:03 error Embedded agent failed before reply: All models failed (2): zai/glm-5: Provider zai is in cooldown (all profiles unavailable) (rate_limit) | zai/glm-4.7: Provider zai is in cooldown (all profiles unavailable) (rate_limit)
22:22:55 debug cron {"module":"cron","storePath":"/home/clawd/.openclaw/cron/jobs.json"} {"nextAt":1771022276299,"delayMs":60000,"clamped":true} cron: timer armed
22:23:45 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:support:telegram:d

untold flaxBOT Feb 13, 2026, 10:27 PM

#

Ese mensaje ya no es “token expired”, ahora es rate limit real:

Provider zai is in cooldown (all profiles unavailable) (rate_limit)

En OpenClaw eso significa:

Z.AI te devolvió algo tipo HTTP 429 / rate limit, y
OpenClaw puso tu único perfil zai:default en cooldown con backoff exponencial (1 min → 5 → 25 → hasta 1h).
Como solo tienes 1 API key en ZAI, cuando esa key entra en cooldown, TODOS los modelos zai/* quedan “unavailable”, por eso fallan glm-5 y glm-4.7 a la vez.

Esto no tiene que ver con “100% de usage” (cuota mensual/créditos). Muchos proveedores tienen límites por minuto / concurrencia aunque tengas créditos de sobra.

1) Confirma cuánto dura el cooldown (y por qué)

Justo después de que pase el error, corre y pega (sin secretos):

#

openclaw models status --json

Ahí debería aparecer auth.unusableProfiles con algo como cooldownUntil para zai:default.

(El cooldown se guarda en auth-profiles.json bajo usageStats, o sea que puede persistir aunque reinicies.)

2) Encuentra el log que muestra el 429 (la causa)

Tu snippet de logs muestra errores de minimax-portal billing (eso es otro problema aparte), pero no el error original de ZAI.

Para capturarlo:

openclaw logs --follow

#

y busca las líneas justo antes de que entre en cooldown (normalmente verás algo con zai / glm / 429 / “rate limit exceeded”).

Si quieres filtrar (opcional):

openclaw logs --follow | grep -i -E "zai|glm|429|rate"

3) Mitigaciones prácticas

Bajar ráfagas/concurrencia: si mandas varios mensajes seguidos, o hay varios agentes/canales pegándole al modelo, vas a disparar 429.
Añadir un fallback de otro proveedor (pero con auth configurada). Ojo: tu fallback anthropic/claude-opus-4-6 ahora mismo no sirve porque te sale Missing auth - anthropic.
Añadir una 2ª Z.AI API key como otro profile (si Z.AI limita por key): así OpenClaw puede rotar cuando una key cae en rate limit.

4) Sobre el error de Minimax en tus logs

Esto es independiente pero importante:

minimax-portal ... billing error ... out of credits

Algún agente/lane tuyo está intentando usar minimax-portal y se cae por falta de saldo. Si no lo vas a usar, conviene quitarlo de los agentes que lo tengan; si sí lo usas, toca recargar créditos o cambiar de key.

#

Pásame el models status --json después de que ocurra el cooldown (con unusableProfiles) y 10-20 líneas de log donde aparezca el primer error de ZAI, y te digo si es límite por minuto, por concurrencia, o si OpenClaw lo está clasificando mal.

neon ridge Feb 13, 2026, 10:29 PM

#

integrated with BrainX V2 storage
2026-02-13T22:18:13.701Z info plugins {"subsystem":"plugins"} [memory-inyection] Plugin loaded - integrated with BrainX V2 storage
2026-02-13T22:20:18.144Z debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=e6848055-f77d-489b-813e-bcfda198eac1 sessionId=0f97f2d7-567e-4ece-b707-7e70b753c703 provider=zai model=glm-4.7 thinking=off messageChannel=telegram
2026-02-13T22:20:42.544Z debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=e6848055-f77d-489b-813e-bcfda198eac1 sessionId=0f97f2d7-567e-4ece-b707-7e70b753c703 durationMs=24296
2026-02-13T22:22:02.114Z warn agent/embedded {"subsystem":"agent/embedded"} embedded run timeout: runId=dab87f08-3122-4bb9-bd9b-b0bf61653af3 sessionId=a8f709a8-e10f-4292-860a-1c81b8395767 timeoutMs=600000
2026-02-13T22:22:02.132Z debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=dab87f08-3122-4bb9-bd9b-b0bf61653af3 sessionId=a8f709a8-e10f-4292-860a-1c81b8395767 durationMs=600011
2026-02-13T22:22:02.139Z debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=a8f709a8-e10f-4292-860a-1c81b8395767 sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
2026-02-13T22:22:02.144Z debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=a8f709a8-e10f-4292-860a-1c81b8395767 totalActive=0
2026-02-13T22:22:02.156Z warn agent/embedded {"subsystem":"agent/embedded"} Profile zai:default timed out (possible rate limit). Trying next account...
2026-02-13T22:22:02.252Z error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=54 error="FailoverError: No available auth profile for zai (all in cooldown or unavailable)."
2026-02-13T22:22:02.257Z error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:telegram:direct:1172819123 durationMs=68 error="FailoverError: No available auth profile for zai (all in cooldown or unavailable)."
2026-02-13T22:22:02.311Z error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=33 error="FailoverError: No available auth profile for zai (all in cooldown or unavailable)."
2026-02-13T22:22:02.316Z error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:telegram:direct:1172819123 durationMs=49 error="FailoverError: No available auth profile for zai (all in cooldown or unavailable)."
2026-02-13T22:22:02.339Z error Embedded agent failed before reply: All models failed (2): zai/glm-5: LLM request timed out. (unknown) | zai/glm-4.7: No available auth profile for zai (all in cooldown or unavailable). (rate_limit)
2026-02-13T22:22:02.371Z error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=32 error="FailoverError: No available auth profile for zai (all in cooldown or unavailable)."
2026-02-13T22:22:02.379Z error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:telegram:direct:1172819123 durationMs=50 error="FailoverError: No available auth profile for zai (all in cooldown or unavailable)."
2026-02-13T22:22:02.384Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ agent errorCode=UNAVAILABLE errorMessage=Error: All models failed (2): zai/glm-5: No available auth profile for zai (all in cooldown or unavailable).

untold flaxBOT Feb 13, 2026, 10:31 PM

#

Lo que muestran esos logs cuadra con esto:

Primero falla zai/glm-5 por timeout

zai/glm-5: LLM request timed out. (unknown)

Después OpenClaw marca tu ÚNICO perfil de Z.AI en “cooldown” (backoff) para no seguir pegándole al proveedor cuando está fallando.
Como solo tienes 1 key (zai:default), cuando entra en cooldown te quedas con:

No available auth profile for zai (all in cooldown or unavailable)
Provider zai is in cooldown (all profiles unavailable)

O sea: aunque Z.AI no tenga “cooldown” en su dashboard, OpenClaw sí aplica cooldown local ante rate limits/timeouts (failover). Es normal (y está documentado), pero si se dispara demasiado fácil, hay que ver por qué.

1) Confirma el `cooldownUntil` (para ver cuánto dura y si se está rearmando)

#

Justo cuando pase, ejecuta:

openclaw models status --json

y busca auth.unusableProfiles (ahí sale el cooldownUntil y el motivo).

Si no quieres pegar todo el JSON, al menos pega esa parte.

2) Mitigación inmediata: evita disparar rate-limit/timeout

Dos cosas típicas que lo provocan:

Concurrencia (varios chats/agentes a la vez) → te come el QPM/TPM aunque “te queden créditos”.
- Revisa tu config y deja esto en 1 (o asegúrate que no lo subiste):
  - agents.defaults.model.maxConcurrent

#

Respuestas muy largas / thinking pesado → tarda mucho y puede timeoutear.
- Prueba en el chat: /thinking off
- Y/o limita salida con maxTokens para zai/glm-5.

3) Te falta un fallback “real” cuando Z.AI se cae

Ahora mismo:

Anthropic te sale missing auth
Minimax-portal en tus logs sale sin créditos

Entonces cuando Z.AI entra en cooldown, te quedas sin red. Aunque sea temporal, se siente como “se murió”.

4) Si te pasa con POQUÍSIMOS mensajes (1–2), huele a problema de red/endpoint

Z.AI en OpenClaw usa por defecto el coding endpoint. Si tu VPS tiene latencia/rutas malas, verás timeouts y luego cooldown.

Si puedes, pega también 20–30 líneas antes del timeout donde aparezca el request a ZAI (a veces sale el status HTTP/429 o un error de red).

#

Pásame auth.unusableProfiles del models status --json y te digo si esto es:

rate limit real (429),
timeout de red (y OpenClaw lo mete en cooldown),
o un patrón de concurrencia.

#

Eso ya deja súper claro qué está pasando: no es un “cooldown inventado”, es el failover de OpenClaw después de un timeout de 10 minutos en Z.AI, y luego como solo tienes 1 perfil (zai:default), te quedas sin nada y aparece “all profiles unavailable”.

La línea clave es esta:

embedded run timeout ... timeoutMs=600000
Profile zai:default timed out (possible rate limit). Trying next account...

OpenClaw trata timeouts como “posible rate limit” y mete el perfil en cooldown (backoff). Por eso enseguida ves:

No available auth profile for zai (all in cooldown...)
Provider zai is in cooldown (all profiles unavailable) (rate_limit)

Qué hacer (en orden, lo más efectivo)

1) Confirma el cooldownUntil (para saber cuánto dura y si se rearma)

#

Justo cuando pase el error, ejecuta:

openclaw models status --json

y pega solo la parte de auth.unusableProfiles (ahí sale cooldownUntil y el motivo).

2) Solución práctica: agrega una 2ª API key de Z.AI como otro profile

El log dice “Trying next account…”, pero no tiene a dónde ir. Si Z.AI te deja generar 2 keys, añade otra con:

openclaw models auth add

y agrega otra credencial para zai (idealmente con un nombre distinto). Así, cuando una key entra en cooldown, OpenClaw puede rotar a la otra en vez de bloquear todo el provider.

#

3) Reduce probabilidad de timeout/rate-limit (si tienes ráfagas)

En tu config, revisa/asegúrate de no tener mucha concurrencia:

agents.defaults.model.maxConcurrent → déjalo en 1 si estás probando estabilidad.

(Está en la referencia de config.)

4) Ten un fallback que realmente funcione

Ahora mismo tu fallback anthropic/claude-opus-4-6 está missing auth, y en logs también apareció minimax-portal sin créditos. O sea: cuando ZAI cae, te quedas sin red.

Configura Anthropic (setup-token) o pon un fallback que sí tengas con auth/credit.

Si me pegas:

auth.unusableProfiles del openclaw models status --json justo después del fallo, y
si antes del timeout aparece algún 429/ECONNRESET/error de red en logs,

#

te digo si esto es más “rate limit por ráfaga” o “problema de red/endpoint” que está causando timeouts largos.

neon ridge Feb 13, 2026, 11:25 PM

#

como abro auth.unusableProfiles y

untold flaxBOT Feb 13, 2026, 11:25 PM

#

auth.unusableProfiles sale dentro del JSON de:

openclaw models status --json

Opción A (recomendado): usando `jq`

Guarda el JSON:

openclaw models status --json > /tmp/models.json

Muestra solo auth.unusableProfiles:

jq '.auth.unusableProfiles' /tmp/models.json

#

(Extra útil para Z.AI:)

jq '.auth.unusableProfiles[] | select(.provider=="zai")' /tmp/models.json

Si no tienes jq instalado:

sudo apt-get update && sudo apt-get install -y jq

Opción B: sin jq (Python, normalmente viene instalado)

openclaw models status --json | python3 -c 'import sys,json; d=json.load(sys.stdin); print(json.dumps(d["auth"]["unusableProfiles"], indent=2))'

Qué pegar aquí

Pega la salida de auth.unusableProfiles (no debería incluir la key secreta, pero igual revisa por si acaso).

neon ridge Feb 13, 2026, 11:25 PM

#

{
"configPath": "/home/clawd/.openclaw/openclaw.json",
"agentDir": "/home/clawd/.openclaw/agents/main/agent",
"defaultModel": "zai/glm-5",
"resolvedDefault": "zai/glm-5",
"fallbacks": [
"zai/glm-4.7",
"anthropic/claude-opus-4-6"
],
"imageModel": null,
"imageFallbacks": [],
"aliases": {
"minimax-m2.1": "minimax-portal/MiniMax-M2.1",
"Minimax": "minimax/MiniMax-M2.1",
"GLM": "zai/glm-4.7",
"GLM-5": "zai/glm-5",
"minimax-m2.1-lightning": "minimax-portal/MiniMax-M2.1-lightning",
"minimax-m2.5": "minimax-portal/MiniMax-M2.5",
"minimax-m2.5-lightning": "minimax-portal/MiniMax-M2.5-lightning",
"ollama-local": "ollama/llama3.2-32k:limited",
"ollama-1b": "ollama/llama3.2:1b"
},
"allowed": [
"minimax-portal/MiniMax-M2.1",
"minimax/MiniMax-M2.1",
"zai/glm-4.7",
"zai/glm-5",
"google-gemini-cli/gemini-3-pro-preview",
"minimax-portal/MiniMax-M2.1-lightning",
"minimax-portal/MiniMax-M2.5",
"minimax-portal/MiniMax-M2.5-lightning",
"ollama/llama3.2-32k:limited",
"ollama/llama3.2:1b"
],
"auth": {
"storePath": "/home/clawd/.openclaw/agents/main/agent/auth-profiles.json",
"shellEnvFallback": {
"enabled": false,
"appliedKeys": []
},
"providersWithOAuth": [],
"missingProvidersInUse": [
"anthropic"
],
"providers": [
{
"provider": "minimax",
"effective": {
"kind": "env",
"detail": "sk-cp-MD...nfGvqtbk"
},
"profiles": {
"count": 0,
"oauth": 0,
"token": 0,
"apiKey": 0,
"labels": []
},
"env": {
"value": "sk-cp-MD...nfGvqtbk",
"source": "env: MINIMAX_API_KEY"
}
},
{
"provider": "minimax-portal",
"effective": {
"kind": "env",
"detail": "sk-cp-MD...nfGvqtbk"
},
"profiles": {
"count": 0,
"oauth": 0,
"token": 0,
"apiKey": 0,
"labels": []
},
"env": {
"value": "sk-cp-MD...nfGvqtbk",
"source": "env: MINIMAX_API_KEY"
},
"modelsJson": {
"value": "minimax-oauth",
"source": "models.json: ~/.openclaw/agents/main/agent/models.json"
}
},
{
"provider": "ollama",
"effective": {
"kind": "models.json",
"detail": "ollama-local"
},
"profiles": {
"count": 0,
"oauth": 0,
"token": 0,
"apiKey": 0,
"labels": []
},
"modelsJson": {
"value": "ollama-local",
"source": "models.json: ~/.openclaw/agents/main/agent/models.json"
}
},
{
"provider": "zai",
"effective": {
"kind": "profiles",
"detail": "~/.openclaw/agents/main/agent/auth-profiles.json"
},
"profiles": {
"count": 1,
"oauth": 0,
"token": 0,
"apiKey": 1,
"labels": [
"zai:default=021e7ffd...ndxEHhD6"
]
},
"modelsJson": {
"value": "BSA_hTTb...CiF7xDRd",
"source": "models.json: ~/.openclaw/agents/main/agent/models.json"
}
}
],
"unusableProfiles": [],
"oauth": {
"warnAfterMs": 86400000,
"profiles": [
{
"profileId": "zai:default",
"provider": "zai",
"type": "api_key",
"status": "static",
"source": "store",
"label": "zai:default"
}
],

untold flaxBOT Feb 13, 2026, 11:26 PM

#

Ya lo abriste: en el JSON que pegaste se ve esto:

"auth": {
  ...
  "unusableProfiles": []
}

O sea, en el momento en que corriste el comando ya NO había cooldown activo (o ya expiró). Por eso sale vacío, aunque en los logs sí se vea que entró en cooldown justo después del timeout.

Cómo verlo cuando SÍ está en cooldown

Haz esto inmediatamente después de que te salga el error “Provider zai is in cooldown…”:

openclaw models status --json | jq '.auth.unusableProfiles'

#

(Lo importante es correrlo “en caliente”, justo tras el fallo.)

Si quieres filtrar solo Z.AI:

openclaw models status --json | jq '.auth.unusableProfiles[] | select(.provider=="zai")'

Forma alternativa (directo del archivo donde se guarda el cooldown)

El cooldown se guarda en usageStats dentro de:

/home/clawd/.openclaw/agents/main/agent/auth-profiles.json

Puedes mirar ahí así:

jq '.usageStats' /home/clawd/.openclaw/agents/main/agent/auth-profiles.json

#BUG with GLM-5 coldown with out any real coldown

1) First: make sure you’re using a real Z.AI API key

2) Check what the Gateway thinks your Z.AI auth is (and whether it’s in backoff)

3) Fix the most common cause: key is set in the wrong place / wrong user / wrong service env

1) Make sure you’re using a Z.AI API key (long-lived), not a web/session token

2) Confirm the Gateway service is using the same config/state you’re editing (common gotcha)

3) Check if OpenClaw has marked the ZAI profile temporarily unusable/backoff

4) Side note: your Anthropic fallback can’t work right now

What I’d do next (minimal + decisive)

One more important thing

Fix: run ONE gateway (recommended)

Why this matches your symptom

Next thing to paste

1) Ver servicios systemd (system + user)

2) Ver procesos corriendo

3) Ver quién está escuchando en el puerto del Gateway

4) Check rápido desde OpenClaw

1) Confirma cuánto dura el cooldown (y por qué)

2) Encuentra el log que muestra el 429 (la causa)

3) Mitigaciones prácticas

4) Sobre el error de Minimax en tus logs

1) Confirma el cooldownUntil (para ver cuánto dura y si se está rearmando)

2) Mitigación inmediata: evita disparar rate-limit/timeout

3) Te falta un fallback “real” cuando Z.AI se cae

4) Si te pasa con POQUÍSIMOS mensajes (1–2), huele a problema de red/endpoint

Qué hacer (en orden, lo más efectivo)

1) Confirma el cooldownUntil (para saber cuánto dura y si se rearma)

2) Solución práctica: agrega una 2ª API key de Z.AI como otro profile

3) Reduce probabilidad de timeout/rate-limit (si tienes ráfagas)

4) Ten un fallback que realmente funcione

Opción A (recomendado): usando jq

Opción B: sin jq (Python, normalmente viene instalado)

Qué pegar aquí

Cómo verlo cuando SÍ está en cooldown

Forma alternativa (directo del archivo donde se guarda el cooldown)

1) Confirma el `cooldownUntil` (para ver cuánto dura y si se está rearmando)

Opción A (recomendado): usando `jq`