After the last update on 04/14, now I can't onboard with openrouter anymore, I do everything normally as I have always done, but after finishing the onboarding with an openrouter key the agent wont work, and it works normally with local ollama. The problem seems to be related to an openai key, but I'm using openrouter, not openai.
#Openrouter won't work anymore after last update
1 messages · Page 1 of 1 (latest)
That sounds like one of two things:
- the default model ended up on
openai/*instead ofopenrouter/*, or - something separate, usually memory embeddings, is asking for an OpenAI key.
First thing, can you paste these?
openclaw --version
openclaw models status
openclaw models status --probe
A few quick checks while you do that:
- After OpenRouter onboarding, the model should normally be
openrouter/autoor anotheropenrouter/<provider>/<model>ref, notopenai/... - If
models statusshowsopenai/...as primary, fix it with:
openclaw models set openrouter/auto
- If the error specifically mentions
OPENAI_API_KEY, that can be memory search / embeddings, which is separate from OpenRouter chat auth. OpenRouter works for chat models, but memory embeddings do not use OpenRouter. In that case, switch memory to local/Ollama or disable that path.
Also, if this is a newly added agent, auth is per-agent, so the new agent may have an empty auth store even if another agent works.
Docs:
- OpenRouter: https://docs.openclaw.ai/providers/openrouter
- Auth: https://docs.openclaw.ai/gateway/authentication
- FAQ: https://docs.openclaw.ai/help/faq
There have also been auth/model fixes since 04/14, so the exact openclaw --version matters here.
openclaw version is 2026.4.15 (041266a)
model is openrouter/openrouter/auto
probe is openrouter:default status ok
How do i change memory embeddings and switch memory to local/Ollama?
Ah, nice, that helps.
openrouter/openrouter/auto is a little suspicious. The canonical ref should be:
openclaw models set openrouter/auto
I’d do that first, because the duplicated openrouter/openrouter/... prefix is not the normal model id.
For memory embeddings, all settings live under agents.defaults.memorySearch in openclaw.json.
Easiest fix: use Ollama for memory
{
agents: {
defaults: {
memorySearch: {
provider: "ollama",
model: "nomic-embed-text",
fallback: "none",
},
},
},
}
A couple notes:
ollamais supported but not auto-detected, so set it explicitly.nomic-embed-textis the default Ollama embedding model, and OpenClaw can auto-pull it if needed.
Fully local, no Ollama
{
agents: {
defaults: {
memorySearch: {
provider: "local",
fallback: "none",
},
},
},
}
That uses the bundled local GGUF embedding path, but it needs node-llama-cpp built. If that path errors, that’s usually the reason.
Temporary workaround: just disable memory
If you want to quickly confirm memory is the thing causing the OpenAI-key error:
{
agents: {
defaults: {
memorySearch: {
enabled: false,
},
},
},
}
If you edit openclaw.json, restart the gateway after:
openclaw gateway restart
My recommendation: since you already have Ollama working, try this order:
openclaw models set openrouter/auto- set
memorySearch.provider = "ollama" - restart gateway
Docs:
- Memory config: https://docs.openclaw.ai/reference/memory-config
- Memory search: https://docs.openclaw.ai/concepts/memory-search
- Ollama provider: https://docs.openclaw.ai/providers/ollama
- OpenRouter: https://docs.openclaw.ai/providers/openrouter
If it still asks for OPENAI_API_KEY after that, paste the exact error line, because then we can pin down what subsystem is still trying to use OpenAI.
Here is my full json, fell free to recommend a new one (will send in batches):
Part1:
Yep, send it over.
Please:
- wrap each batch in a code block
- redact any tokens/keys
- after the last batch, send
DONE
If you want, the most relevant bits are:
agents.defaults.modelagents.defaults.memorySearchagents.defaults.modelsmodels.providers- any
env/ secret refs
I’ll stitch it together and suggest a cleaner working config.
Got part 1.
So far, nothing OpenAI-related in this chunk. agents.defaults.model.primary being openrouter/auto looks fine.
One important thing though: your gateway token is visible in the thread. Please redact secrets in the next parts, and I’d rotate that token after we’re done.
Send the next batch.
Got it, send the next batch. So far I still don’t see the OpenAI bit.
Thanks, this helps a lot.
I don’t see any explicit OpenAI config in this file, so the OpenAI error is probably not coming from openclaw.json directly.
What I’d change:
1. Make memory explicit
Right now you have no memorySearch block, so if anything touches embeddings, it can fall back into auto-resolution land.
Add this under agents.defaults:
memorySearch: {
provider: "ollama",
model: "nomic-embed-text",
fallback: "none"
}
If you want a quick test first, disable memory entirely:
memorySearch: {
enabled: false
}
2. Keep the OpenRouter model as-is
This part looks fine:
model: {
primary: "openrouter/auto"
}
3. Optional cleanup for Ollama
You currently define models.providers.ollama explicitly, which means auto-discovery is skipped. That is okay, but if you want simpler config, you can remove the manual models.providers.ollama.models section and let Ollama auto-discover instead.
My recommended minimal shape
I’d keep your config mostly the same and just add:
{
agents: {
defaults: {
model: { primary: "openrouter/auto" },
memorySearch: {
provider: "ollama",
model: "nomic-embed-text",
fallback: "none"
}
}
}
}
Then:
openclaw gateway restart
One more likely gotcha
Your file says openrouter/auto, but earlier you reported openrouter/openrouter/auto. That mismatch makes me suspicious of a stale session override or a model-status normalization bug.
So after restarting, also test in a fresh session/thread, or run:
/model status
in the same thread.
Important
You posted several live secrets in this thread. Please rotate:
- gateway token
- Telegram bot token
- Perplexity/OpenRouter-style API key
Docs:
- Memory config: https://docs.openclaw.ai/reference/memory-config
- Memory search: https://docs.openclaw.ai/concepts/memory-search
- Ollama: https://docs.openclaw.ai/providers/ollama
- OpenRouter: https://docs.openclaw.ai/providers/openrouter
If you want, next I can give you a cleaned full config based on what you posted, with the noisy bits removed.
do i add those lines before "workspace"?
Yep, inside agents.defaults, as a sibling of workspace, models, and model.
Order does not matter in JSON, but structurally it should look like this:
{
"agents": {
"defaults": {
"workspace": "/home/bender/.openclaw/workspace",
"memorySearch": {
"provider": "ollama",
"model": "nomic-embed-text",
"fallback": "none"
},
"models": {
"openrouter/auto": {
"alias": "OpenRouter"
},
"openrouter/x-ai/grok-4.1-fast": {},
"openrouter/minimax/minimax-m2.7": {}
},
"model": {
"primary": "openrouter/auto"
}
}
}
}
So yes, before workspace is fine, after workspace is fine, just make sure it stays inside "defaults" and the commas are correct.
If you want the quick diagnostic version instead, use this block instead:
"memorySearch": {
"enabled": false
}
Use one or the other, not both.
nah, didnt work
Okay, then I’m less suspicious of memory now. Your JSON looks mostly sane, so this is probably either:
- a session/thread model override, or
- a real runtime regression.
Two high-signal checks next:
In this exact thread
Run:
/model status
If it shows anything other than openrouter/..., force it with:
/model openrouter/auto
Or just test in a brand new thread/session, because session overrides can ignore your updated default config.
On the host
Run:
openclaw doctor
openclaw status
and paste:
- the model/auth part
- the memory part
- the first actual error line
At this point the exact error text matters a lot. Right now I think we’re down to “stale session override vs actual 2026.4.15 bug.”
there is no error
That’s actually useful.
If there’s no error at all, I’m now more suspicious of stale session state than auth.
Please try these exact steps:
In this same thread
/model status
/model openrouter/auto
Then send a normal test message like hello.
If still nothing
Start a brand new thread/session and send one test message there.
Then tell me which case you get:
-
Old thread fails, new thread works
→ stale session/thread state -
Both fail silently
→ likely a 2026.4.15 regression
Also, when it “doesn’t work”, is it:
- totally silent, no typing/status at all, or
- starts to respond / shows typing, then stops?
That detail matters a lot here.
totally silent, no typing/status at all
Got it. If it’s totally silent, we’re past guesswork, we need the runtime view.
Please run these on the host:
openclaw status --all
and in another terminal:
openclaw logs --follow
Then send one test message to the bot and paste:
- the
status --alloutput
- the new log lines that appear right after the test message
status --all is designed to be shareable, it redacts tokens.
What I’m trying to distinguish now is:
- Discord event never reaches the Gateway
- Gateway receives it but never starts a run
- Run starts and dies before visible typing
If you want the fastest path, openclaw logs --follow while sending one message is the key one.
Port 18789 is already in use
Tailscale: off . unknown
I think we found the real problem.
Port 18789 is already in use means another Gateway instance is already bound there. So the config you’re editing may not be the process actually serving Discord. That would explain the totally silent behavior.
Tailscale being off / unknown is fine, ignore that part for now.
Do this next
openclaw gateway status --deep
Pay attention to:
Probe targetListeningConfig (cli)Config (service)
If Config (cli) and Config (service) differ, or it looks like an old instance is live, fix it with:
openclaw gateway install --force
openclaw gateway restart
If port 18789 is still busy after that
Stop the service first:
openclaw gateway stop
Then check what is actually holding the port:
ss -ltnp '( sport = :18789 )'
or
lsof -nP -iTCP:18789 -sTCP:LISTEN
What I’m expecting
This is probably a duplicate/stale gateway process or a service config mismatch. Once the live service and your edited config line up again, OpenRouter should start behaving normally.
Docs: https://docs.openclaw.ai/gateway/troubleshooting
If you paste the openclaw gateway status --deep output, I can tell you which side is mismatched.
cli and service are the same .json
It's not that, you're not helping at all. Just last week I was running everything on openrouter with no problem, on the same computer, same fresh install, same network, same os, same everything. Just this week i've decided to do a fresh install and used the script and it pulled this new version and now it wont work, its not the machine, network, os
You’re right, and I’m sorry, I chased the wrong branch.
Given what you described, same machine + fresh install + worked last week + breaks only on the new version, this really does sound like a 2026.4.15 regression, not your network/OS.
I would stop burning time on config and do one of these:
Best practical option
Roll back to the last version that worked for you:
openclaw update --tag <known-good-version>
openclaw gateway restart
Docs: https://docs.openclaw.ai/help/faq#can-i-ask-openclaw-to-update-itself
If you want to get it fixed upstream
Please file a GitHub issue with:
openclaw --version→2026.4.15- fresh install via install script
- OpenRouter onboarding succeeds
openclaw models statusshows OpenRouter auth OK- Ollama works
- OpenRouter is totally silent, no typing/status, no visible error
Issue tracker: https://github.com/openclaw/openclaw/issues
If you want, I can help you write the issue text cleanly in one message so you can paste it.
give me the last 5 versions so i can choose one
Last 5 stable versions I can see are:
2026.4.152026.4.142026.4.122026.4.112026.4.10
If you want one more older stable:
2026.4.9
I’d try this order:
- first:
2026.4.14 - if still broken:
2026.4.12 - then:
2026.4.9
Rollback command:
openclaw update --tag 2026.4.14
openclaw gateway restart
If you want, I can also give you the beta ones around that range, but I’d stick to stable for this.
yes, give me the issue text so i can paste it
Yep, paste this:
Title: Fresh install on 2026.4.15, OpenRouter onboarding succeeds but agent is totally silent, Ollama still works
## Version
- OpenClaw `2026.4.15 (041266a)`
## Summary
On a fresh install from the install script, OpenRouter onboarding appears to succeed and `openclaw models status` shows OpenRouter auth is OK, but the agent does not reply at all when using OpenRouter.
On the same machine, same network, same OS, local Ollama works normally.
This worked for me last week on the same computer. The regression appears to be in the newer version pulled by the install script.
## What I did
1. Fresh install using the OpenClaw install script
2. Ran onboarding with an OpenRouter API key
3. Confirmed model/auth looked correct
4. Sent a normal test message to the bot
## Expected
The agent should reply normally using OpenRouter, same as it did last week.
## Actual
The bot is totally silent:
- no typing/status
- no visible error in chat
- no normal reply
## What works
- Local Ollama works normally on the same install
## What I checked
- `openclaw models status` showed OpenRouter auth OK
- Probe showed `openrouter:default` status OK
- Config primary model was `openrouter/auto`
- `plugins.entries.openrouter.enabled = true`
- CLI config and service config pointed to the same JSON
- I also tried explicitly changing / disabling memory search, no change
## Relevant config shape
```json5
{
agents: {
defaults: {
model: { primary: "openrouter/auto" },
models: {
"openrouter/auto": { alias: "OpenRouter" }
}
}
},
auth: {
profiles: {
"openrouter:default": {
provider: "openrouter",
mode: "api_key"
}
}
},
plugins: {
entries: {
openrouter: { enabled: true },
ollama: { enabled: true }
}
}
}
## Notes
This feels like a regression in `2026.4.15` because:
- same machine/network/OS
- same general setup
- fresh install
- OpenRouter worked last week
- Ollama still works now
- only OpenRouter is failing, and it fails silently
If you want, I can also tighten that into a shorter GitHub-style version.
how do i onboard straight to version 2026.4.12 on a fresh install?
I don’t see a documented install-script flag to pin a specific version at install time.
So the safe way is:
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw update --tag 2026.4.12
openclaw --version
openclaw gateway restart
openclaw onboard
So, in practice:
- fresh install
- immediately pin to
2026.4.12 - verify version
- onboard
If you want it even more explicit:
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw update --tag 2026.4.12 --yes
openclaw --version
openclaw gateway restart
openclaw onboard
Docs for update --tag: https://docs.openclaw.ai/help/faq#can-i-ask-openclaw-to-update-itself
If you want, I can also give you the exact clean-room sequence for wiping the fresh install and redoing it on 2026.4.12.
Memory search is enabled, but no embedding provider is ready. │
│ Semantic recall needs at least one embedding provider. │
│ │
│ │
│ Fix (pick one): │
│ - Set OPENAI_API_KEY, GEMINI_API_KEY, GOOGLE_API_KEY, VOYAGE_API_KEY, MISTRAL_API_KEY in │
│ your environment │
│ - Configure credentials: openclaw configure --section model │
│ - For local embeddings: configure agents.defaults.memorySearch.provider and local model │
│ path │
│ - To disable: openclaw config set agents.defaults.memorySearch.enabled false │
│ │
│ Verify: openclaw memory status --deep
How do i setup memory search provider?
Yep, that’s the first concrete culprit.
OpenRouter chat auth can be fine, but OpenRouter does not satisfy memory embeddings.
Your setup has memory search enabled with no embedding provider ready, so that’s the thing to fix.
Best fix, since you already have Ollama
Run:
openclaw config set agents.defaults.memorySearch.provider ollama
openclaw config set agents.defaults.memorySearch.model nomic-embed-text
openclaw config set agents.defaults.memorySearch.fallback none
openclaw gateway restart
openclaw memory status --deep
Fastest workaround, if you just want chat working
Disable memory search entirely:
openclaw config set agents.defaults.memorySearch.enabled false
openclaw gateway restart
openclaw memory status --deep
Why this happens
Memory search needs an embedding provider like:
- Ollama
- local GGUF embeddings
- OpenAI
- Gemini
- Voyage
- Mistral
OpenRouter is not one of the memory embedding providers, so onboarding with OpenRouter alone does not satisfy that requirement.
I’d try the disable-memory path first, just to confirm the bot starts replying again. If that works, switch it to Ollama after.
Easiest path for you is Ollama.
Memory search provider lives at:
agents.defaults.memorySearch
Set it from the CLI
openclaw config set agents.defaults.memorySearch.provider ollama
openclaw config set agents.defaults.memorySearch.model nomic-embed-text
openclaw config set agents.defaults.memorySearch.fallback none
openclaw gateway restart
openclaw memory status --deep
Or put it directly in openclaw.json
{
"agents": {
"defaults": {
"memorySearch": {
"provider": "ollama",
"model": "nomic-embed-text",
"fallback": "none"
}
}
}
}
Then restart:
openclaw gateway restart
If you just want to turn it off
openclaw config set agents.defaults.memorySearch.enabled false
openclaw gateway restart
Docs:
- Memory config: https://docs.openclaw.ai/reference/memory-config
- Memory search: https://docs.openclaw.ai/concepts/memory-search
- Ollama: https://docs.openclaw.ai/providers/ollama
If you want, I can give you the exact block merged into your current JSON so you can paste it without guessing commas/braces.
what if i want to use openrouter and models for memory search instead of ollama?
Short version, not directly.
For memory search, OpenClaw supports these embedding providers:
ollamalocalopenaigeminivoyagemistralbedrockgithub-copilot
openrouter is not a first-class memory embedding provider right now.
So you can use:
- OpenRouter for chat/completions
- something else for memory embeddings
That’s why the doctor output was asking for OpenAI/Gemini/Voyage/Mistral/local, not OpenRouter.
If you want:
- fully local memory →
ollamaorlocal - cloud memory →
openai,gemini,voyage, ormistral
So the clean answer is:
- chat model = OpenRouter
- memory search provider = something else
If you want, I can suggest the best cheap pairing for “OpenRouter for chat + X for memory search.”
new error after the ollama memory setup:
Memory search provider is set to "ollama" but no API key was found. │
│ Semantic recall will not work without a valid API key. │
│ Gateway memory probe for default agent is not ready: Ollama embeddings HTTP 404: │
│ {"error":"model "nomic-embed-text" not found, try pulling it first"} │
│ │
│ Fix (pick one): │
│ - Set OLLAMA_API_KEY in your environment │
│ - Configure credentials: openclaw configure --section model │
│ - To disable: openclaw config set agents.defaults.memorySearch.enabled false │
│ │
│ Verify: openclaw memory status --deep
Paste the exact error text please, ideally in a code block.
If you have it, also include:
openclaw memory status --deep
That should tell us whether it’s:
- Ollama not reachable
- embedding model not present
- auth/base URL mismatch
- or just a bad memorySearch config value
Good, this is a real concrete error now.
You have two separate Ollama memory issues:
- OpenClaw wants an
OLLAMA_API_KEYmarker - the embedding model
nomic-embed-textis not pulled yet
Fix it
ollama pull nomic-embed-text
Then make sure the Gateway has an Ollama key marker. For local-only Ollama, a placeholder is fine:
cat >> ~/.openclaw/.env <<'EOF'
OLLAMA_API_KEY=ollama-local
EOF
Then restart and verify:
openclaw gateway restart
openclaw memory status --deep
Why this is happening
OLLAMA_API_KEYfor local Ollama does not need to be a real paid key, it just needs to existnomic-embed-textis the default Ollama embedding model for memory search, and right now your Ollama instance is saying it isn’t installed
If you want to sanity check
ollama list
You should see nomic-embed-text after the pull.
So the short version is: this is not OpenRouter anymore, this is just Ollama memory embeddings not fully set up yet.
"Then make sure the Gateway has an Ollama key marker. For local-only Ollama, a placeholder is fine:"
How do i do this?
Easiest way is to put it in the Gateway env file.
1. Add this line to ~/.openclaw/.env
printf 'OLLAMA_API_KEY=ollama-local\n' >> ~/.openclaw/.env
If the file already has an OLLAMA_API_KEY=... line, just edit/replace it so it becomes:
OLLAMA_API_KEY=ollama-local
2. Restart the Gateway
openclaw gateway restart
3. Verify
openclaw memory status --deep
For local-only Ollama, ollama-local is just a placeholder marker, it does not need to be a real secret key.
Also make sure you already pulled the embedding model:
ollama pull nomic-embed-text
If you want, I can give you the exact copy-paste sequence for all 4 commands in order.
i cant find this .env you mentioned
That’s probably because it doesn’t exist yet, and also files starting with . are hidden.
You can just create it:
mkdir -p ~/.openclaw
printf 'OLLAMA_API_KEY=ollama-local\n' >> ~/.openclaw/.env
openclaw gateway restart
If you want to confirm it exists afterward:
ls -la ~/.openclaw
cat ~/.openclaw/.env