intento trabajar con modelos a traves de Openrouter

[unkempt oar]

selecciono un modelo con Openrouter pero siempre se cambia al de Backfall (Haiku) , ¿como solucionar esto?

[vale fulcrum]

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

[storm niche]

Eso suele pasar por una de estas dos cosas: el modelo de OpenRouter no quedó seleccionado con el ref completo, o el primario está fallando y OpenClaw entra en fallback.

Primero, ¿puedes pasar tu versión?

openclaw --version

Mientras tanto, revisa esto:

openclaw models status --probe

Ahí deberías ver el primario real, fallbacks y si OpenRouter tiene auth válida. Para OpenRouter, al seleccionar por chat usa siempre el prefijo completo:

[storm niche]

/model openrouter/<provider>/<model-id>
/model status

Importante: los IDs de OpenRouter suelen contener /, así que si escribes solo el ID sin openrouter/, OpenClaw puede resolverlo contra otro proveedor/default.

Si quieres que no caiga a Haiku cuando el primario falla, limpia o cambia los fallbacks:

openclaw models fallbacks list
openclaw models fallbacks clear

O deja fallbacks solo con modelos que sí quieras usar. Si cambiaste el default en config pero esta conversación ya estaba “pinneada” a otro modelo, usa /model status y luego vuelve a seleccionar el modelo, o /reset para limpiar el estado de esa sesión.

Docs relevantes: https://docs.openclaw.ai/concepts/models y https://docs.openclaw.ai/help/faq-models

[storm niche]

Sí, si esto lo arregla: right click en el mensaje que tenga la solución → Apps → ✅ Mark Solution. Así queda indexado en Answer Overflow para la próxima persona.

[unkempt oar]

OpenClaw 2026.5.12 (f066dd2)

[storm niche]

Gracias. En 2026.5.12, el siguiente paso es confirmar si OpenRouter está fallando o si la sesión quedó fijada a otro modelo.

Pasa estos outputs, idealmente sin claves/tokens:

openclaw models status --probe
openclaw models fallbacks list

Y en el chat donde te cambia a Haiku:

/model status

Para seleccionar OpenRouter, usa el ID completo, por ejemplo:

[storm niche]

/model openrouter/anthropic/claude-sonnet-4-6

Si el modelo de OpenRouter falla por auth, límite, o upstream de OpenRouter, OpenClaw puede moverse al fallback configurado. Si no quieres que use Haiku como fallback, quítalo de la lista con:

openclaw models fallbacks remove anthropic/claude-3-5-haiku-latest

Si no sabes el nombre exacto que aparece, usa primero openclaw models fallbacks list.

[unkempt oar]

🦞 OpenClaw 2026.5.12 (f066dd2) — Your second brain, except this one actually remembers where you left things.

│
20:35:49 [agent/embedded] workspace bootstrap file MEMORY.md is 12059 chars (limit 12000); truncating in injected context (sessionKey=probe-anthropic-xxxxxx….)
20:35:50 [agent/embedded] workspace bootstrap file MEMORY.md is 12059 chars (limit 12000); truncating in injected context (sessionKey=probe-ollama-xxxxx…..)
20:35:52 [agent/embedded] workspace bootstrap file MEMORY.md is 12059 chars (limit 12000); truncating in injected context (sessionKey=probe-openrouter-xxxxx…..)
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openrouter/z-ai/glm-5.1
Fallbacks (1) : anthropic/claude-haiku-4-5
Image model : -
Image fallbacks (0): -
Aliases (4) : opus -> anthropic/claude-opus-4-7, Llama-Local -> ollama/llama3.2:1b, Kimi-K2.6 -> openrouter/moonshotai/kimi-k2.6, GLM-5.1 -> openrouter/z-ai/glm-5.1
Configured models (5): anthropic/claude-opus-4-7, anthropic/claude-haiku-4-5, ollama/llama3.2:1b, openrouter/moonshotai/kimi-k2.6, openrouter/z-ai/glm-5.1

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

• anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | anthropic:default=sk-ant-a...JATWvwAA
• ollama effective=models.json:marker(ollama-local) | models.json=marker(ollama-local) | source=models.json: ~/.openclaw/agents/main/agent/models.json | synthetic=plugin-owned | source=models.providers.ollama (synthetic local key)
• openrouter effective=models.json:sk-or-v1...0425986a | models.json=sk-or-v1...0425986a | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

• none

[storm niche]

Ahí se ve el motivo: tienes configurado Haiku como fallback explícito.

Default       : openrouter/z-ai/glm-5.1
Fallbacks (1) : anthropic/claude-haiku-4-5

Si OpenRouter/GLM falla por límite, auth, timeout o error upstream, OpenClaw intenta el fallback y acaba en Haiku. Si no quieres que pase nunca:

openclaw models fallbacks remove anthropic/claude-haiku-4-5
# o, si quieres limpiar todos:
openclaw models fallbacks clear

Luego reinicia el gateway si tu instalación no recoge el cambio al vuelo:

[storm niche]

openclaw gateway restart

Después confirma:

openclaw models status

El mensaje de MEMORY.md ... truncating no es la causa; solo dice que tu memoria se recorta un poco al inyectarse en contexto.

Si después de quitar el fallback sigue cambiando, mira en ese chat:

/model status

[storm niche]

Puede que esa sesión concreta esté fijada a otro modelo; en ese caso selecciona otra vez /model openrouter/z-ai/glm-5.1 o usa /reset.

[unkempt oar]

no me importa que esté Haiku como fallback e s necesario y es correcto, lo que quiero saber es por que se cae el modelo default

[storm niche]

Perfecto, entonces no toquemos el fallback. Para saber por qué cae el default necesitamos el error del intento de OpenRouter, no solo el resumen de config.

Ejecuta esto justo después de reproducir el cambio a Haiku:

openclaw models status --probe
openclaw logs --since 10m | grep -Ei "openrouter|glm-5.1|z-ai|fallback|rate|limit|401|402|403|429|5[0-9][0-9]|provider returned"

Si openclaw logs --since no existe en tu versión, usa:

openclaw logs --follow

y reproduce el problema mientras miras la salida.

[storm niche]

Lo que buscamos es una línea del tipo:

• 401/403: key inválida, sin permisos, crédito/billing
• 402: límite o saldo en OpenRouter
• 429: rate limit
• 5xx / Provider returned error: fallo del upstream de OpenRouter/Z.AI
• error de tool schema/context: el modelo no soporta bien alguna herramienta o se pasó de contexto

También prueba un probe directo del modelo default:

openclaw models list --provider openrouter
openclaw models status --probe

Tu default está bien escrito como openrouter/z-ai/glm-5.1, así que ahora la causa probable está en la respuesta concreta de OpenRouter o del proveedor upstream. Pega solo el bloque de log alrededor del primer fallo de openrouter/z-ai/glm-5.1, con tokens redactados.

[unkempt oar]

como hago eso?

[storm niche]

Hazlo así, paso a paso:

1. Abre una terminal en la máquina donde corre OpenClaw y ejecuta:

openclaw logs --follow --plain

2. Déjala abierta.

3. En Discord/Telegram/WebChat, manda un mensaje que haga que OpenClaw intente usar openrouter/z-ai/glm-5.1 y caiga a Haiku.

4. Vuelve a la terminal y copia las líneas que aparecieron justo en ese momento, especialmente las que mencionen:

openrouter

[storm niche]

z-ai
glm-5.1
fallback
provider returned
401
402
403
429
500
timeout

5. Antes de pegarlas aquí, borra cualquier token/API key si aparece. Normalmente ya vienen redactadas, pero revisa igual.

Alternativa si prefieres no usar terminal: abre el Control UI → pestaña Logs, reproduce el problema y copia el bloque alrededor del fallo.

[storm niche]

Lo importante es capturar el primer error del modelo default. El resumen que pegaste solo dice “si falla, tengo Haiku como fallback”; el log nos dirá por qué falló.

[unkempt oar]

antes de empezar a hablar con él creo que ya está en Haiku, te pego código:
Log file: /tmp/openclaw/openclaw-2026-05-28.log
2026-05-28T20:35:49.818Z warn agent/embedded {"subsystem":"agent/embedded"} workspace bootstrap file MEMORY.md is 12059 chars (limit 12000); truncating in injected context (sessionKey=probe-anthropic-24d…)
2026-05-28T20:35:50.287Z warn agent/embedded {"subsystem":"agent/embedded"} workspace bootstrap file MEMORY.md is 12059 chars (limit 12000); truncating in injected context (sessionKey=probe-ollama-99d62b31-cdc….)
2026-05-28T20:35:52.524Z warn agent/embedded {"subsystem":"agent/embedded"} workspace bootstrap file MEMORY.md is 12059 chars (limit 12000); truncating in injected context (sessionKey=probe-openrouter-b6de1739-d463-......)
2026-05-28T20:35:58.852Z warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","fallback_model"],"runId":"probe-f8f9df22-dbc2-4010-be9f-2932c4f7c3ec","stage":"assistant","decision":"fallback_model","failoverReason":"timeout","profileFailureReason":"timeout","provider":"ollama","model":"llama3.2:1b","sourceProvider":"ollama","sourceModel":"llama3.2:1b","fallbackConfigured":true,"timedOut":true,"aborted":true,"status":408} embedded run failover decision
2026-05-28T20:36:02.008Z info Fallbacks (1):
2026-05-28T20:36:02.022Z info - anthropic/claude-haiku-4-5
2026-05-28T20:46:21.421Z info gateway {"subsystem":"gateway"} device pairing auto-approved device=f182a7ee6e03d07eaba3fce0cbe7d6b7520693f9679778ff8e570183a50d1d60 role=operator

[storm niche]

Ese bloque no muestra que el default se haya caído a Haiku. Muestra otra cosa:

provider":"ollama","model":"llama3.2:1b"
failoverReason":"timeout"
status":408

Eso fue el probe de ollama/llama3.2:1b durante models status --probe, no el default openrouter/z-ai/glm-5.1. O sea: tu Ollama local tardó demasiado y el probe decidió fallback. No es evidencia de que OpenRouter esté fallando.

También esto:

Fallbacks (1):
- anthropic/claude-haiku-4-5

[storm niche]

solo lista la configuración, no dice que ya esté usando Haiku.

Para saber si la conversación ya está en Haiku antes de hablar, en ese mismo chat escribe:

/model status

Si ahí dice que la sesión está pinned/selected a Haiku, entonces no es un fallo de OpenRouter: es estado de sesión. Solución rápida:

/model openrouter/z-ai/glm-5.1

o, si quieres limpiar la sesión:

[storm niche]

/reset

Si /model status dice OpenRouter/GLM pero al mandar un mensaje cae a Haiku, entonces reproduce el fallo y copia las líneas nuevas del log justo después. Necesitamos ver una línea con provider":"openrouter" o model":"z-ai/glm-5.1"; el bloque que pegaste solo habla de Ollama.

[unkempt oar]

desde Telegram funciona bien, me faltaría confirmar dessde la TUI , que es desde donde he notado el fallo

[storm niche]

Eso encaja mejor: Telegram puede estar usando una sesión distinta y la TUI puede estar retomando una sesión vieja fijada a Haiku.

En la TUI haz esta prueba:

/status
/model status

Mira también el footer de la TUI: muestra agente, sesión y modelo actual. Si ahí ves Haiku, no es que OpenRouter se caiga: esa sesión de TUI está usando un override anterior.

Para probar limpio, abre la TUI con una sesión nueva:

openclaw tui --session test-openrouter

[storm niche]

Dentro:

/model openrouter/z-ai/glm-5.1
/model status
hola

Si eso funciona, el problema era la sesión vieja. Puedes seguir con esa sesión nueva, o en la sesión vieja usar:

/model openrouter/z-ai/glm-5.1

o limpiar con:

[storm niche]

/reset

Ojo con esto: openclaw chat y openclaw tui --local no son lo mismo que openclaw tui. El modo local usa el runtime embebido directamente; para comparar con Telegram/Gateway, usa openclaw tui sin --local.

[unkempt oar]

openclaw tui --session test-openrouter
session agent:main:test-openrouter

model set failed: GatewayClientRequestError: model not allowed: openrouter/z-ai/glm-5.1 /model status hola
connected idle
agent main session test-openrouter |openrouter/z-ai/glm-5.1 | tokens ?/200k

[storm niche]

Esto es útil. La línea importante es:

model set failed: ... model not allowed: openrouter/z-ai/glm-5.1

pero el footer luego muestra:

session test-openrouter | openrouter/z-ai/glm-5.1

Eso significa: la TUI está heredando el default correcto, pero cuando intentas fijarlo como override de sesión, la validación de allowlist lo rechaza. Es más un problema de allowlist/estado de Gateway que de caída del modelo.

Prueba añadirlo explícitamente a agents.defaults.models y reiniciar el Gateway:

[storm niche]

openclaw config set agents.defaults.models '{"openrouter/z-ai/glm-5.1":{}}' --strict-json --merge
openclaw gateway restart

Luego vuelve a probar:

openclaw tui --session test-openrouter-2

Dentro de la TUI:

/model openrouter/z-ai/glm-5.1
/model status

[storm niche]

hola

Si sigue saliendo model not allowed, pega estos dos outputs:

openclaw config get agents.defaults.models
openclaw models status

No pegues el API key; esos comandos no deberían mostrarlo completo, pero revisa igual.

[unkempt oar]

parece que por lo menos el hola me lo ha aguantado y todavía estamos en GLM de todas formas te pego el output:
Aquí tienes el estado de modelos:

Default: openrouter/z-ai/glm-5.1 (GLM-5.1)

Fallback: anthropic/claude-haiku-4-5

Aliases configurados:

┌─────────────┬─────────────────────────────────┐
│ Alias │ Modelo │
├─────────────┼─────────────────────────────────┤
│ opus │ anthropic/claude-opus-4-7 │
├─────────────┼─────────────────────────────────┤
│ Kimi-K2.6 │ openrouter/moonshotai/kimi-k2.6 │
├─────────────┼─────────────────────────────────┤
│ GLM-5.1 │ openrouter/z-ai/glm-5.1 │
├─────────────┼─────────────────────────────────┤
│ Llama-Local │ ollama/llama3.2:1b │
└─────────────┴─────────────────────────────────┘

Auth: Todo via API keys (Anthropic, OpenRouter) + synthetic key para Ollama local. Sin OAuth activo.

¿Qué necesitas, Jordi?

———
🤖 openrouter/z-ai/glm-5.1 · GLM-5.1 (default)

hola

¡Hola, Jordi! 👋 ¿Qué tal? ¿En qué te puedo ayudar?

———
🤖 openrouter/z-ai/glm-5.1 · GLM-5.1 (default)
connected | idle
agent main | session test-openrouter-2 | openrouter/z-ai/glm-5.1 | tokens 20k/200k (10%)

[storm niche]

Sí, ese output confirma que ahora la TUI está usando GLM:

openrouter/z-ai/glm-5.1 · GLM-5.1 (default)
session test-openrouter-2 | openrouter/z-ai/glm-5.1

Así que no parece una caída general de OpenRouter. Lo más probable era una de estas dos cosas:

1. La sesión antigua de TUI tenía estado/override/fallback previo.
2. La allowlist rechazaba fijar openrouter/z-ai/glm-5.1 como override, aunque el default sí aparecía en el footer.

Yo seguiría usando test-openrouter-2 un rato. Si vuelve a caer a Haiku, copia solo el bloque de log de ese momento donde aparezca openrouter o z-ai/glm-5.1; ahí ya veríamos la causa real.

Si esto queda estable, puedes cambiar a tu sesión normal y hacer:

[storm niche]

/model openrouter/z-ai/glm-5.1

o directamente arrancar la TUI con una sesión limpia/nueva cuando quieras evitar arrastrar estado viejo:

openclaw tui --session main-2

[unkempt oar]

si se cambia a Haiku como puedo ver los logs?

[storm niche]

Cuando veas que cambia a Haiku, haz esto:

1. En otra terminal, deja los logs vivos:

openclaw logs --follow --plain

2. Reproduce el cambio en la TUI.

3. Copia las líneas que salgan justo en ese momento. Busca especialmente:

openrouter
z-ai
glm-5.1

[storm niche]

fallback
failover
provider returned
timeout
401
402
403
429
500

Si prefieres ver el archivo directamente:

tail -f /tmp/openclaw/openclaw-$(date +%F).log

[storm niche]

Y para sacar solo lo relevante después de reproducir:

grep -Ei "openrouter|z-ai|glm-5.1|fallback|failover|timeout|401|402|403|429|500|provider returned" /tmp/openclaw/openclaw-$(date +%F).log | tail -80

Antes de pegarlo aquí, revisa que no aparezca una API key completa. Normalmente OpenClaw las redacta, pero mejor comprobar.

[unkempt oar]

me esta yendo bien ahora. De momento lo dejo así.

[storm niche]

Perfecto. Entonces lo dejaría así: sesión nueva en TUI + GLM como default, y solo miramos logs si vuelve a caer.

Si esto te lo solucionó, marca el mensaje útil como solución: right click → Apps → ✅ Mark Solution. Así queda encontrable para otros.