#Openrouter won't work anymore after last update

1 messages · Page 1 of 1 (latest)

molten elbow
#

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.

jaunty portalBOT
#

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

mental brookBOT
icy geodeBOT
#

That sounds like one of two things:

  1. the default model ended up on openai/* instead of openrouter/*, or
  2. 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/auto or another openrouter/<provider>/<model> ref, not openai/...
  • If models status shows openai/... 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:

There have also been auth/model fixes since 04/14, so the exact openclaw --version matters here.

molten elbow
#

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?

icy geodeBOT
#

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:

  • ollama is supported but not auto-detected, so set it explicitly.
  • nomic-embed-text is 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:

  1. openclaw models set openrouter/auto
  2. set memorySearch.provider = "ollama"
  3. restart gateway

Docs:

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.

molten elbow
#

Here is my full json, fell free to recommend a new one (will send in batches):

Part1:

icy geodeBOT
#

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.model
  • agents.defaults.memorySearch
  • agents.defaults.models
  • models.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
molten elbow
#

do i add those lines before "workspace"?

icy geodeBOT
#

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.

molten elbow
#

nah, didnt work

icy geodeBOT
#

Okay, then I’m less suspicious of memory now. Your JSON looks mostly sane, so this is probably either:

  1. a session/thread model override, or
  2. 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.”

molten elbow
#

there is no error

icy geodeBOT
#

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:

  1. Old thread fails, new thread works
    → stale session/thread state

  2. 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.

molten elbow
#

totally silent, no typing/status at all

icy geodeBOT
#

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 --all output
#
  • 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:

  1. Discord event never reaches the Gateway
  2. Gateway receives it but never starts a run
  3. Run starts and dies before visible typing

If you want the fastest path, openclaw logs --follow while sending one message is the key one.

molten elbow
#

Port 18789 is already in use
Tailscale: off . unknown

icy geodeBOT
#

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 target
  • Listening
  • Config (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.

molten elbow
#

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

icy geodeBOT
#

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 status shows 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.

molten elbow
#

give me the last 5 versions so i can choose one

icy geodeBOT
#

Last 5 stable versions I can see are:

  1. 2026.4.15
  2. 2026.4.14
  3. 2026.4.12
  4. 2026.4.11
  5. 2026.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.

molten elbow
icy geodeBOT
#

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.

molten elbow
#

how do i onboard straight to version 2026.4.12 on a fresh install?

icy geodeBOT
#

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:

  1. fresh install
  2. immediately pin to 2026.4.12
  3. verify version
#
  1. 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.

molten elbow
#

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?

icy geodeBOT
#

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:

molten elbow
#

what if i want to use openrouter and models for memory search instead of ollama?

icy geodeBOT
#

Short version, not directly.

For memory search, OpenClaw supports these embedding providers:

  • ollama
  • local
  • openai
  • gemini
  • voyage
  • mistral
  • bedrock
  • github-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 → ollama or local
  • cloud memory → openai, gemini, voyage, or mistral

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.”

molten elbow
#

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

icy geodeBOT
#

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:

  1. OpenClaw wants an OLLAMA_API_KEY marker
  2. the embedding model nomic-embed-text is 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_KEY for local Ollama does not need to be a real paid key, it just needs to exist
  • nomic-embed-text is 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.

molten elbow
#

"Then make sure the Gateway has an Ollama key marker. For local-only Ollama, a placeholder is fine:"
How do i do this?

icy geodeBOT
#

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.

molten elbow
#

i cant find this .env you mentioned

icy geodeBOT
#

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