#Actualizar a la version 2026.4.19-beta.1

1 messages · Page 1 of 1 (latest)

ebon juniper
#

Quiero actualizar a la version 2026.4.19-beta.1, y verificar si para esta version, la inconsistencia en la implementacion de OpenRouter Preset esta subsanada. Ya que en la version OpenClaw 2026.4.15 (041266a) no funciona, la peticion a OPENROUTER falla y el gateway salta a GPT 4.1 mini

topaz flumeBOT
cedar steppeBOT
#

Sí, pero te diría dos cosas claras:

  1. Para actualizar a 2026.4.19-beta.1
    • Si tu instalación es por npm/pnpm:
      openclaw update --tag 2026.4.19-beta.1 --dry-run
openclaw update --tag 2026.4.19-beta.1
    • Si es una instalación git/source, --tag no aplica. Ahí usa:
      openclaw update --channel beta
    • Luego verifica:
      openclaw --version
openclaw update status
openclaw models status
# 

2. **Sobre el bug de OpenRouter Preset**
   - Revisé el changelog local y **no veo una corrección explícita en `2026.4.19-beta.1`** para el caso de `OpenRouter Preset` / `openrouter/@preset/...`.
   - Sí aparecen fixes relevantes en releases previas, por ejemplo:
     - preservación de rutas `openrouter/@preset/...`
     - clasificación de errores `OpenRouter no-endpoints`
     - algunos arreglos de `reasoning.effort` / payloads OpenRouter
   - O sea, **no te lo puedo confirmar como “ya subsanado” en 2026.4.19-beta.1**. Puede mejorar otras rutas de fallback, pero no veo una nota de release que cierre justo ese caso.

Si quieres, haz la update y, si sigue cayendo a **GPT 4.1 mini**, pégame esto y lo afinamos rápido:

```bash
openclaw --version
openclaw models status
openclaw status --all
ebon juniper
#

tambien tenemos una solucion en realcion al posteo realizado en GitHUB que te lo puedo pasar. Solo que aqui aborada una solucion en relacion a la implementacion de OpenRouter auto, pero que yo no sabria si esto tambien aplica a la configuracion del PRESET que tengo configurado en mi perfil de OpenRouter. Confirmame si te puedo pasar aqui el link de GitHub con la solucion a este inconveniente con OpenRouter auto

cedar steppeBOT
#

Sí, pásamelo 👍

Me sirve mucho si compartes:

  • el link del issue/PR de GitHub
  • el model ref exacto que usas ahora, por ejemplo openrouter/@preset/...
  • y, si puedes, el error exacto del log cuando cae a GPT 4.1 mini

Solo no pegues API keys ni secretos.

Con eso te digo si la solución de OpenRouter auto también debería aplicar a tu caso con PRESET, o si son rutas distintas en OpenClaw/OpenRouter.

ebon juniper
#

Aqui va el link, https://github.com/openclaw/openclaw/pull/69580 y este es la denominacion del PRESET configurado en OpenRouter : @preset/asistente-diario. El error ya te lo habia pasado. Ayer intentamos todas las soluciones y fue imposible reslverlo

cedar steppeBOT
#

Sí, con ese link ya se ve bastante claro.

Mi lectura es esta:

  • El PR #69580 corrige solo el caso openrouter/auto.
  • El cambio hace esto, básicamente: cuando OpenClaw manda openrouter/auto, lo transforma a auto para la API de OpenRouter.
  • Eso no es lo mismo que un preset como @preset/asistente-diario.

Para PRESET, OpenClaw ya tiene una ruta distinta, y en el código/test aparece explícitamente que conserva openrouter/@preset/... como preset, por ejemplo openrouter/@preset/kimi-2-5.

Entonces, mi conclusión es:

1) Ese PR no confirma que tu caso de PRESET esté arreglado

Aplica a openrouter/auto, no a openrouter/@preset/asistente-diario.

2) Si tu modelo en OpenClaw está configurado como:

# 
openrouter/@preset/asistente-diario

entonces el problema parece ser otro bug, no el de openrouter/auto.

3) Sobre 2026.4.19-beta.1

Yo no veo evidencia de que esa beta traiga una corrección específica para @preset/....

Lo que te pediría ahora, para no seguir a ciegas, es esto:

  • confirma si en OpenClaw lo tienes escrito exactamente como
    openrouter/@preset/asistente-diario
  • y vuelve a pegar el error exacto del log, porque en este hilo ahora mismo no lo veo

Si quieres, en el próximo mensaje te digo qué bloque exacto de config pegar aquí, sanitizado, para revisar si el fallback a GPT 4.1 mini viene de:

  • la referencia del modelo,
  • el fallback chain,
#
  • o un error real de OpenRouter con ese preset.
#

Mejor GitHub, no un Discord externo.

Por lo que revisé:

  • PR #69580 corrige openrouter/auto
  • el caso de Ale parece ser otro distinto: openrouter/@preset/asistente-diario

Así que lo correcto sería abrir/comentar un issue y enlazar ese PR como contexto, con:

  • openclaw --version
  • modelo exacto: openrouter/@preset/asistente-diario
  • config saneada de agents.defaults.model y fallbacks
  • error/log exacto cuando salta a GPT 4.1 mini

Issues: https://github.com/openclaw/openclaw/issues

Si quieren, les ayudo a redactar el repro corto para dejarlo bien claro ahí.

ebon juniper
#

ok, hagamos para responder al mismo Issue y ver que respuesta resibimos en solucion a OpenRouter Preset

cedar steppeBOT
#

Sí. Pégales esto en el mismo hilo del issue/PR, en inglés mejor:

I think I am hitting a related but different OpenRouter case.

My issue is not with `openrouter/auto`, but with an OpenRouter preset:
`@preset/asistente-diario`

In OpenClaw, the model is configured as:
`openrouter/@preset/asistente-diario`

On OpenClaw `2026.4.15 (041266a)`, the request to OpenRouter fails and the gateway falls back to GPT 4.1 mini.

From reading PR #69580, it looks like the fix is specific to `openrouter/auto` being converted to the bare OpenRouter API model id `auto`.

Could you confirm whether that fix should also cover `openrouter/@preset/...`, or if presets go through a different code path?
# 

If presets are a different path, is there already a fix or a recommended config format for OpenRouter presets in OpenClaw?

I can provide sanitized logs/config if needed.

Si quieres, te dejo una versión un poco más fuerte, añadiendo que ya probaron varias soluciones y no lograron resolverlo.

ebon juniper
#

ok, hazlo

cedar steppeBOT
#

No puedo responder en GitHub por ti desde aquí, pero pega esto tal cual:

I think I am hitting a related but different OpenRouter issue.

My case is not `openrouter/auto`, but an OpenRouter preset:
`@preset/asistente-diario`

In OpenClaw, the model is configured as:
`openrouter/@preset/asistente-diario`

On OpenClaw `2026.4.15 (041266a)`, the request to OpenRouter fails and the gateway falls back to GPT 4.1 mini.

From reading PR #69580, it looks like the fix is specific to `openrouter/auto` being converted to the bare OpenRouter API model id `auto`.

Could you confirm whether that fix should also cover `openrouter/@preset/...`, or if presets go through a different code path?
# 

We already tried multiple troubleshooting steps and could not get the preset path working.

If presets are a different path, is there already a fix or a recommended config format for OpenRouter presets in OpenClaw?

I can provide sanitized logs/config if needed.

Si quieres, cuando lo publiques, me pegas la respuesta y la analizamos.

ebon juniper
#

explicame que solucion se plantea en esta respuesta del post de GitHub basado en nuestra consulta

cedar steppeBOT
#

Revisé ese hilo, y ahora mismo no hay todavía una respuesta humana del maintainer a tu comentario.

Lo que sí aparece es el resumen del bot de review, y la solución que plantea es esta:

  • detectar cuando el modelo es openrouter/auto
  • y convertirlo a auto antes de enviarlo a la API de OpenRouter
  • hacerlo en varios puntos del plugin:
    • buildDynamicOpenRouterModel
    • prepareDynamicModel
    • isCacheTtlEligible

En simple

OpenClaw hoy estaría mandando openrouter/auto tal cual, pero OpenRouter espera solo auto.
Por eso el request puede fallar o ignorarse y terminar en fallback a otro modelo.

Lo importante para tu caso

Eso no resuelve directamente tu preset:

# 
openrouter/@preset/asistente-diario

Porque esa propuesta es solo para el sentinel openrouter/auto, no para @preset/....

Mi lectura

  • La solución propuesta no aplica directamente a tu problema
  • además, ese PR está cerrado, no mergeado
  • y por ahora tu comentario sigue sin respuesta técnica específica sobre presets

Si quieres, te preparo el siguiente comentario corto para empujar la conversación y pedir una confirmación directa sobre openrouter/@preset/....

#

Sí, ese diff confirma exactamente eso.

Qué cambia ahí

En extensions/openrouter/index.ts agregan esta lógica:

const apiModelId = ctx.modelId === "openrouter/auto" ? "auto" : ctx.modelId;

y luego usan apiModelId en vez de ctx.modelId para:

  • resolver el modelo dinámico
  • preparar el modelo
  • evaluar isCacheTtlEligible

Qué significa

Si OpenClaw recibe:

# 
openrouter/auto

ahora lo transforma a:

auto

antes de hablar con la API de OpenRouter.

Qué NO veo en ese diff

No hay una lógica equivalente para:

# 
openrouter/@preset/asistente-diario

o para @preset/... en general.

Mi conclusión

Ese patch:

  • sí corrige openrouter/auto
  • no demuestra una solución para OpenRouter Preset
  • por eso no alcanza para afirmar que tu caso quedó resuelto

Si quieres, te preparo el comentario final para GitHub tipo:

“I checked the patch diff and it only normalizes openrouter/auto -> auto. I don’t see any equivalent handling for openrouter/@preset/.... Should presets already work through a different path, or is preset support still missing here?”

ebon juniper
#

co0nfiguremos por el momento openrouter auto, probemos como se comporta, y dejemos a Gemini Lite como secundario y a GPT 4.1 mini como 3era opcion

cedar steppeBOT
#

Sí, yo lo haría así por ahora.

Opción CLI

openclaw models set openrouter/auto
openclaw models fallbacks clear
openclaw models fallbacks add <google/gemini-lite-exacto>
openclaw models fallbacks add openai/gpt-4.1-mini
openclaw models status

Importante

No te quiero inventar el ref exacto de Gemini Lite. Sácalo primero con:

openclaw models list --provider google
#

y usa ese model ref exacto en el segundo comando.

Equivalente en config

{
  agents: {
    defaults: {
      model: {
        primary: "openrouter/auto",
        fallbacks: [
          "<google/gemini-lite-exacto>",
          "openai/gpt-4.1-mini"
        ]
      }
    }
  }
# 
}

Después

Verifica con:

openclaw models status
openclaw --version

y prueba un turno real. Si OpenRouter falla, debería pasar a Gemini Lite y luego a GPT 4.1 mini en ese orden.

Si quieres, te ayudo a validar el model ref exacto de Gemini Lite en cuanto pegues la salida de:

# 
openclaw models list --provider google
ebon juniper
#

alexifra@LAPTOP-VIVOBOOK-ALEXIFRA:~$ openclaw models list --provider google

🦞 OpenClaw 2026.4.15 (041266a) — I autocomplete your thoughts—just slower and with more API calls.

Model Input Ctx Local Auth Tags
google/gemini-3.1-flash-lite-preview text+image 1024k no yes configured,alias:gemini-lite
google/gemini-3-flash-preview text+image 1024k no yes configured,alias:gemini-flash

cedar steppeBOT
#

Perfecto, entonces el Gemini Lite exacto es:

google/gemini-3.1-flash-lite-preview

Yo lo dejaría así:

openclaw models set openrouter/auto
openclaw models fallbacks clear
openclaw models fallbacks add google/gemini-3.1-flash-lite-preview
openclaw models fallbacks add openai/gpt-4.1-mini
openclaw models status

Orden final

#
  1. openrouter/auto
  2. google/gemini-3.1-flash-lite-preview
  3. openai/gpt-4.1-mini

Ojo

Sigues en 2026.4.15, y justo el fix que vimos para openrouter/auto no parece estar incorporado ahí.
O sea, puedes configurarlo para probar, pero si openrouter/auto vuelve a fallar en esa versión no sería raro.

Si quieres, el siguiente paso lógico sería:

openclaw update --tag 2026.4.19-beta.1 --dry-run

y te digo si conviene hacer la update o dejar esta cadena de fallback por ahora.

ebon juniper
#

alexifra@LAPTOP-VIVOBOOK-ALEXIFRA:~$ openclaw models set openrouter/auto
openclaw models fallbacks clear
openclaw models fallbacks add google/gemini-3.1-flash-lite-preview
openclaw models fallbacks add openai/gpt-4.1-mini
openclaw models status

🦞 OpenClaw 2026.4.15 (041266a) — I'll refactor your busywork like it owes me money.

Config overwrite: /home/alexifra/.openclaw/openclaw.json (sha256 a39a02bcca0382ed4e9335c472493ef5a872c454eb22ee985e341956148ff433 -> b0ac1b5906951eb991c53c20f9101e8452149a36f253f72deac2bc94b274413b, backup=/home/alexifra/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
Default model: openrouter/auto

🦞 OpenClaw 2026.4.15 (041266a)
Your second brain, except this one actually remembers where you left things.

Config overwrite: /home/alexifra/.openclaw/openclaw.json (sha256 b0ac1b5906951eb991c53c20f9101e8452149a36f253f72deac2bc94b274413b -> 735541b41b5f7ea49cb7cfc718de5259afbf06c58f96054120992c8df462810b, backup=/home/alexifra/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
Fallback list cleared.

🦞 OpenClaw 2026.4.15 (041266a) — Deployed locally, trusted globally, debugged eternally.

Config overwrite: /home/alexifra/.openclaw/openclaw.json (sha256 735541b41b5f7ea49cb7cfc718de5259afbf06c58f96054120992c8df462810b -> 0f08baf09fd016bf41033b590c4ad7aee0bb909c5bd8866bc84bb302b88e3b3c, backup=/home/alexifra/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
Fallbacks: google/gemini-3.1-flash-lite-preview

🦞 OpenClaw 2026.4.15 (041266a)
If something's on fire, I can't extinguish it—but I can write a beautiful postmortem.

Config overwrite: /home/alexifra/.openclaw/openclaw.json (sha256 0f08baf09fd016bf41033b590c4ad7aee0bb909c5bd8866bc84bb302b88e3b3c -> 5ae5e06699577266132bcad6bc50b8c30eb79ad724c8d4336c65076f0db2747f, backup=/home/alexifra/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
Fallbacks: google/gemini-3.1-flash-lite-preview, openai/gpt-4.1-mini

🦞 OpenClaw 2026.4.15 (041266a)
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 : openrouter/openrouter/auto (from openrouter/auto)
Fallbacks (2) : google/gemini-3.1-flash-lite-preview, openai/gpt-4.1-mini
Image model : -
Image fallbacks (0): -
Aliases (4) : GPT -> openai/gpt-5.1-codex, gpt -> openai/gpt-5.4, gemini-lite -> google/gemini-3.1-flash-lite-preview, gemini-flash -> google/gemini-3-flash-preview
Configured models (8): openai/gpt-5.1-codex, openai/gpt-5.4, openrouter/free, google/gemini-3.1-flash-lite-preview, google/gemini-3-flash-preview, openrouter/auto, openai/gpt-4.1-mini, openrouter/@preset/asistente-diario

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

  • brave effective=env:BSAwl7-5...x7NCmChU | env=BSAwl7-5...x7NCmChU | source=env: BRAVE_API_KEY
  • google effective=env:AIzaSyCx...1ghdoEJY | env=AIzaSyCx...1ghdoEJY | source=env: GEMINI_API_KEY
  • openai effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openai:default=sk-proj-...fRb8ZXEA | env=sk-proj-...pSn135wA | source=env: OPENAI_API_KEY
  • openrouter effective=env:sk-or-v1...6a9c8da7 | env=sk-or-v1...6a9c8da7 | source=env: OPENROUTER_API_KEY
  • perplexity effective=env:sk-or-v1...6a9c8da7 | env=sk-or-v1...6a9c8da7 | source=env: OPENROUTER_API_KEY

OAuth/token status

  • none
cedar steppeBOT
#

Sí, ahí ya apareció la pista clave.

Lo raro

models status te está mostrando:

Default : openrouter/openrouter/auto (from openrouter/auto)

Eso está mal.
Esperaríamos algo como:

openrouter/auto

no openrouter/openrouter/auto.

#

Qué significa

En 2026.4.15 OpenClaw te está doble-prefixando el model ref de OpenRouter Auto.
O sea, antes incluso de probar un prompt, ya vemos que la resolución del modelo quedó torcida.

Eso encaja bastante con el problema que veníamos mirando:

  • openrouter/auto no se está tratando bien
  • luego OpenRouter falla
  • y el gateway termina cayendo a los fallbacks

Mi recomendación

Yo no confiaría en openrouter/auto sobre 2026.4.15.

Haría una de estas dos:

Opción A, la más lógica

Primero verificar si la beta mejora esto:

# 
openclaw update status
openclaw update --tag 2026.4.19-beta.1 --dry-run

y después volver a mirar si models status sigue mostrando ese doble prefijo.

Opción B, si quieres estabilidad ya

Dejar por ahora Gemini Lite como primario y GPT 4.1 mini como fallback, y sacar OpenRouter Auto hasta probar una versión más nueva.

En corto: sí, el openrouter/openrouter/auto ya confirma que en 2026.4.15 algo está roto en esa ruta.
Si quieres, te digo ahora mismo cuál sería el comando más seguro para dejar una config estable temporal.

ebon juniper
#

alexifra@LAPTOP-VIVOBOOK-ALEXIFRA:~$ openclaw update status
openclaw update --tag 2026.4.19-beta.1 --dry-run
OpenClaw update status

┌──────────┬───────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├──────────┼───────────────────────────────────────────────────────────────────────────────────────────┤
│ Install │ pnpm │
│ Channel │ stable (default) │
│ Update │ available · pnpm · npm update 2026.4.20 │
└──────────┴───────────────────────────────────────────────────────────────────────────────────────────┘

Update available (npm 2026.4.20). Run: openclaw update
Update dry-run
No changes were applied.

Root: /home/alexifra/.local/lib/node_modules/openclaw
Install kind: package
Mode: npm
Channel: stable
Tag/spec: openclaw@2026.4.19-beta.1
Current version: 2026.4.15
Target version: 2026.4.19-beta.1

Planned actions:

  • Run global package manager update with spec openclaw@2026.4.19-beta.1
  • Run plugin update sync after core update
  • Refresh shell completion cache (if needed)
  • Restart gateway service and run doctor checks
cedar steppeBOT
#

Bien, con eso ya está clarísimo.

Mi recomendación

No iría a 2026.4.19-beta.1.
Tienes disponible 2026.4.20 estable, que es más nueva y en tu caso tiene más sentido probar primero.

Como tu instalación es package/pnpm, yo haría:

openclaw update
openclaw --version
openclaw models status

Por qué

  • 2026.4.20 > 2026.4.19-beta.1
  • tu dry-run ya confirma que la ruta de update está bien
#
  • no vale mucho la pena fijarte en una beta más vieja cuando ya tienes una estable más nueva

Qué mirar después de actualizar

Lo importante no es solo la versión, sino si sigue apareciendo esto:

Default : openrouter/openrouter/auto

Si después de actualizar sigue saliendo ese doble prefijo, entonces el bug sigue vivo.
Si pasa a algo normal como:

Default : openrouter/auto

ahí sí ya vale la pena probar un turno real.

#

Entonces

Yo haría este orden:

  1. openclaw update
  2. openclaw --version
  3. openclaw models status
  4. probar un prompt corto con openrouter/auto

Pégame esos dos outputs después del update y te digo enseguida si mejoró o no.

ebon juniper
#

alexifra@LAPTOP-VIVOBOOK-ALEXIFRA:~$ openclaw update
openclaw --version
openclaw models status
Updating OpenClaw...

│
◇ ✓ Updating via package manager (50.55s)
│
◇ ✓ Running doctor checks (57.17s)

Update Result: OK
Root: /home/alexifra/.local/lib/node_modules/openclaw
Before: 2026.4.15
After: 2026.4.20

Total time: 108.44s

Updating plugins...
Downloading @askjo/camofox-browser…
Extracting /tmp/openclaw-npm-pack-JFdlLh/askjo-camofox-browser-1.6.0.tgz…
WARNING: Plugin "camofox-browser" contains dangerous code patterns: Shell command execution detected (child_process) (/tmp/openclaw-plugin-jIgCOJ/extract/package/scripts/plugin.js:159); Shell command execution detected (child_process) (/tmp/openclaw-plugin-jIgCOJ/extract/package/scripts/plugin.test.js:16); Shell command execution detected (child_process) (/tmp/openclaw-plugin-jIgCOJ/extract/package/plugins/vnc/vnc-launcher.js:38)
npm plugins: 0 updated, 0 unchanged, 1 failed.
Failed to update camofox-browser: Plugin "camofox-browser" installation blocked: dangerous code patterns detected: Shell command execution detected (child_process) (/tmp/openclaw-plugin-jIgCOJ/extract/package/scripts/plugin.js:159); Shell command execution detected (child_process) (/tmp/openclaw-plugin-jIgCOJ/extract/package/scripts/plugin.test.js:16); Shell command execution detected (child_process) (/tmp/openclaw-plugin-jIgCOJ/extract/package/plugins/vnc/vnc-launcher.js:38)

Restarting service...
Daemon restart completed.

Patched, polished, and ready to pinch. Let's go.
OpenClaw 2026.4.20 (115f05d)

🦞 OpenClaw 2026.4.20 (115f05d)
One CLI to rule them all, and one more restart because you changed the port.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openrouter/openrouter/auto (from openrouter/auto)
Fallbacks (2) : google/gemini-3.1-flash-lite-preview, openai/gpt-4.1-mini
Image model : -
Image fallbacks (0): -
Aliases (4) : GPT -> openai/gpt-5.1-codex, gpt -> openai/gpt-5.4, gemini-lite -> google/gemini-3.1-flash-lite-preview, gemini-flash -> google/gemini-3-flash-preview
Configured models (8): openai/gpt-5.1-codex, openai/gpt-5.4, openrouter/free, google/gemini-3.1-flash-lite-preview, google/gemini-3-flash-preview, openrouter/auto, openai/gpt-4.1-mini, openrouter/@preset/asistente-diario

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

  • brave effective=env:BSAwl7-5...x7NCmChU | env=BSAwl7-5...x7NCmChU | source=env: BRAVE_API_KEY
  • google effective=env:AIzaSyCx...1ghdoEJY | env=AIzaSyCx...1ghdoEJY | source=env: GEMINI_API_KEY
  • openai effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openai:default=sk-proj-...fRb8ZXEA | env=sk-proj-...pSn135wA | source=env: OPENAI_API_KEY
  • openrouter effective=env:sk-or-v1...6a9c8da7 | env=sk-or-v1...6a9c8da7 | source=env: OPENROUTER_API_KEY
  • perplexity effective=env:sk-or-v1...6a9c8da7 | env=sk-or-v1...6a9c8da7 | source=env: OPENROUTER_API_KEY

OAuth/token status

  • none
cedar steppeBOT
#

Perfecto, ya tenemos una conclusión bastante sólida.

Resultado

La update salió bien, pero el bug sigue.

Lo importante es esto:

Default : openrouter/openrouter/auto (from openrouter/auto)

En 2026.4.20 sigue apareciendo el doble prefijo, así que openrouter/auto no quedó bien resuelto tampoco en la versión nueva.

Qué sí sabemos ahora

  • No era solo 2026.4.15
  • No se arregló con 2026.4.20
  • por lo tanto, para tu caso, OpenRouter Auto sigue roto
#
  • y eso hace todavía menos probable que @preset/... esté sano en esa misma ruta

Sobre el plugin camofox-browser

Ese warning es aparte.
No parece relacionado con OpenRouter. El update principal sí quedó aplicado.

Mi recomendación práctica

Para dejarlo estable por ahora, yo haría:

openclaw models set google/gemini-3.1-flash-lite-preview
openclaw models fallbacks clear
openclaw models fallbacks add openai/gpt-4.1-mini
openclaw models status

O sea:

#
  1. Gemini Lite como primario
  2. GPT 4.1 mini como fallback
  3. sacar openrouter/auto del camino hasta que lo corrijan

Y en GitHub

Esto ya vale oro como evidencia. Yo comentaría algo así:

I updated from 2026.4.15 to 2026.4.20 and the issue still reproduces.

`openclaw models status` still resolves:
`Default : openrouter/openrouter/auto (from openrouter/auto)`

So `openrouter/auto` is still being normalized incorrectly on 2026.4.20 as well.

This suggests the issue is not fixed in current stable, and it also makes me doubt that `openrouter/@preset/...` is working correctly through the same path.