HTTP 429 error - how to fix it? | Friends of the Crustacean 🦞🤝 | Page 1

slate hound Feb 7, 2026, 11:06 PM

#

Using opus Claude, always get this error. When I try to add other models stop working..

limber hawkBOT Feb 7, 2026, 11:06 PM

#

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

fluid ibexBOT Feb 7, 2026, 11:07 PM

#

slate hound Using opus Claude, always get this error. When I try to add other models stop wo...

HTTP 429 is almost always rate limiting / quota from the model provider — it’s not an “OpenClaw bug” you can fix locally.

1) First: which 429 is it?

Can you paste the exact error text (just the few lines that mention 429)? Two common cases:

Anthropic 429 usually looks like: rate_limit_error / anthropic / claude-3-opus…
→ means your Anthropic quota/rate limit is exhausted for the current window. You have to wait for the window to reset or upgrade/raise limits (depending on whether you’re using subscription setup-token vs API key).
Docs: https://docs.openclaw.ai/help/faq#why-am-i-seeing-http-429-ratelimiterror-from-anthropic
Discord 429 mentions discord.com/api
→ that’s Discord rate limiting the bot (different fix).

2) Quick info that will let us diagnose fast

Please run/paste:

#

openclaw --version
openclaw models status
openclaw logs --follow

(You can stop logs --follow after the 429 happens and paste the relevant chunk.)

Also: are you authenticating Anthropic via API key or setup-token (Claude subscription)?

3) “When I try to add other models, they stop working…”

That often happens when the config change accidentally replaces your model list instead of adding fallbacks, so OpenClaw ends up with only misconfigured models.

If the 429 is Anthropic, the best practical fix is: set up a fallback model/provider so OpenClaw can keep replying while Anthropic is rate-limited. (After you paste openclaw models status, we can point out exactly what’s failing and why.)

slate hound Feb 7, 2026, 11:13 PM

#

Via API, but it’ very easily fall into 429

fluid ibexBOT Feb 7, 2026, 11:15 PM

#

slate hound Via API, but it’ very easily fall into 429

If you’re using Anthropic via API key, then 429 = you’re hitting Anthropic rate limits/quota (requests/min or tokens/min). OpenClaw can retry/back off, but it can’t “fix” a hard provider limit — you either need more headroom or a fallback.

What to do:

Confirm what limit you’re hitting

Check the 429 text in openclaw logs --follow — Anthropic usually tells you whether it’s requests or tokens.
Also paste: openclaw --version + openclaw models status

Reduce how often you hit 429 (common gotcha: context size)

Big model + long chat history = huge prompt = you can hit tokens/min even with a single message.
Try /new (fresh session) and see if 429 stops happening so easily.

Set up model fallbacks so you still get replies
OpenClaw supports a primary model + ordered fallbacks (agents.defaults.model.primary + agents.defaults.model.fallbacks). Easiest is using the CLI:

#

openclaw models fallbacks list
openclaw models list --all
openclaw models fallbacks add <provider/model>

Docs: https://docs.openclaw.ai/concepts/models and https://docs.openclaw.ai/concepts/model-failover

If “adding other models makes things stop working”
That’s often because you set an allowlist (agents.defaults.models). If a model isn’t in that allowlist, OpenClaw will reply with “Model … is not allowed” and it feels like it “stopped responding”. The fix is: add the model to the allowlist, or remove the allowlist and pick from /model list instead. (Explained here: https://docs.openclaw.ai/concepts/models)

If you paste your openclaw models status output (and the 429 snippet from logs), I can tell you which of the above is the main culprit in your setup.

slate hound Feb 7, 2026, 11:18 PM

#

Would ollama be a good fallback?

fluid ibexBOT Feb 7, 2026, 11:18 PM

#

slate hound Would ollama be a good fallback?

Ollama can be a fallback, but IMO it’s usually only a “better than nothing” backup — not a great one — unless you have a pretty beefy local box and you’re running a large-enough model with a big context window.

Key gotchas:

If your Gateway is on a VPS, an Ollama server on your laptop won’t be reachable unless you deliberately expose/tunnel it. Local fallbacks only help if the Gateway can hit the local model endpoint.
Most Ollama-sized models people run are much weaker at tool use / long-context, so you might escape 429 but hit “bad tool calls / weird behavior / slow replies” instead.
OpenClaw specifically warns that local models are tricky because it expects large context + strong prompt-injection defenses. (Local models don’t have provider-side safety nets.)

If you want to go local anyway, this doc is the canonical guide (and it also shows the recommended “hosted primary → local fallback” pattern):
https://docs.openclaw.ai/gateway/local-models

For solving your original pain (Anthropic 429) with minimal hassle, the most reliable approach is usually: keep Anthropic as primary, add a hosted fallback provider/model so you still get replies when Anthropic is rate-limiting. (Failover details: https://docs.openclaw.ai/concepts/model-failover)

If you tell me where your Gateway runs (local machine vs VPS) + your hardware (RAM/GPU), I can tell you whether an Ollama fallback is likely to feel usable or just frustrating.

slate hound Feb 7, 2026, 11:19 PM

#

I have also groq as fallback but it never hits groq

fluid ibexBOT Feb 7, 2026, 11:20 PM

#

slate hound I have also groq as fallback but it never hits groq

If you’re getting Anthropic 429 and it never tries Groq, that usually means one of these is true:

It isn’t actually model failover (the 429 is from something else, not the Anthropic LLM call).
→ Check the log line: does it say provider=anthropic / rate_limit_error?
Groq is configured as a provider, but not actually configured as a fallback model.
OpenClaw only falls back to models listed in agents.defaults.model.fallbacks (or via the CLI helpers), not just because a provider exists.
Quick check:

openclaw models fallbacks list
openclaw models status

Groq is being skipped because it’s not allowed / not authenticated.
If you have an allowlist (agents.defaults.models), the Groq model must be in there, and openclaw models status must show Groq auth as OK.

Fastest way to pinpoint which one: paste the relevant bits of:

#

openclaw models status
openclaw logs --follow # reproduce one 429, then paste the ~30 lines around it

(You can redact secrets; the important part is which provider/model the 429 came from, and whether it logs “trying next model/fallback”.)

Failover behavior reference: https://docs.openclaw.ai/concepts/model-failover

slate hound Feb 7, 2026, 11:20 PM

#

When I run ollama locally works perfectly but not with them

fluid ibexBOT Feb 7, 2026, 11:21 PM

#

slate hound When I run ollama locally works perfectly but not with them

That makes sense: Ollama “works locally” only helps OpenClaw if the Gateway process can reach that Ollama server.

Most common mismatch is:

You run ollama on your laptop (so http://127.0.0.1:11434 works for you)
but your OpenClaw Gateway is running somewhere else (VPS / another machine / Docker)
so from the Gateway’s point of view, 127.0.0.1 is not your laptop → Ollama is unreachable, so it’ll never be used as fallback.

Quick checks

Where is your Gateway running (same machine as Ollama, or remote)?
On the Gateway host, does this work?

curl http://127.0.0.1:11434/api/tags

If you want Ollama as a real fallback

Run Ollama on the same host as the Gateway, or

#

Expose/tunnel Ollama and set an explicit models.providers.ollama.baseUrl to a reachable URL (LAN/Tailscale/etc), e.g. http://<ollama-host>:11434/v1.

OpenClaw’s Ollama provider doc (includes both “implicit discovery” and explicit baseUrl setup):
https://docs.openclaw.ai/providers/ollama

Re: “Groq fallback but it never hits Groq”

That’s usually just config: Groq exists as a provider, but isn’t actually in agents.defaults.model.fallbacks (or it’s blocked by an allowlist). Easiest proof is:

openclaw models status
openclaw models fallbacks list

Paste those outputs and I can tell you exactly why it’s not failing over.

slate hound Feb 7, 2026, 11:21 PM

#

Groq is in the fallback list, and there is no allow list

fluid ibexBOT Feb 7, 2026, 11:22 PM

#

slate hound Groq is in the fallback list, and there is no allow list

If Groq is definitely in agents.defaults.model.fallbacks and you don’t have an allowlist, then the usual reasons it still “never hits Groq” are:

Groq isn’t actually healthy at runtime (missing/invalid key, wrong model id, etc.), so when failover tries it, it immediately errors and you only notice the original 429.
The 429 isn’t coming from the Anthropic model call you think it is (less common, but logs make this obvious).
You’re editing config for one agent, but the Discord route is using a different agent (so the fallbacks you edited aren’t the ones used in that channel/session).

Can you paste these two things? They’ll make the answer unambiguous:

A)

openclaw --version
openclaw models status

B) reproduce one failure, then paste ~30 lines around it from:

#

openclaw logs --follow

Also, quick sanity test: in the chat where Anthropic 429s, can you manually switch to Groq for one message (via /model …) and confirm Groq actually replies? If manual Groq works but automatic fallback doesn’t, that’s a strong hint the 429 is being handled/retried in a way that isn’t escalating to fallback (or you’re on an older version with different failover behavior).

slate hound Feb 7, 2026, 11:22 PM

#

1 ollama is in same machine running as openclaw

fluid ibexBOT Feb 7, 2026, 11:24 PM

#

slate hound 1 ollama is in same machine running as openclaw

Cool — if Ollama and the OpenClaw Gateway are truly in the same network namespace, then Ollama should be a perfectly fine fallback.

When it “works when I run Ollama locally” but OpenClaw won’t use it, it’s almost always one of these:

1) Ollama isn’t actually enabled for OpenClaw

OpenClaw only discovers/uses Ollama if you set OLLAMA_API_KEY (any string works; Ollama doesn’t need a real key), or you configure it in openclaw.json.

On the gateway host:

openclaw models list --provider ollama
openclaw models status

If that shows no Ollama models, enable it:

#

export OLLAMA_API_KEY="ollama-local"
# or
openclaw config set models.providers.ollama.apiKey "ollama-local"

Docs: https://docs.openclaw.ai/providers/ollama

2) “Same machine” but not the same localhost

If OpenClaw is running in Docker / WSL2 / a containerized install, then 127.0.0.1:11434 from OpenClaw is not your host’s Ollama.

Quick proof: run on the machine where OpenClaw runs:

curl http://127.0.0.1:11434/api/tags

#

If that fails, you need an explicit models.providers.ollama.baseUrl pointing at a reachable host/IP (see the “Custom base URL” section in the Ollama provider doc).

3) Fallback exists, but never gets triggered

If you’re hitting Anthropic 429 and it still doesn’t switch, the logs will show why (often Groq/Ollama fails instantly due to auth/model-id, so it looks like it “never tries”).

If you paste openclaw --version + openclaw models status, I can tell immediately whether OpenClaw can even see Ollama/Groq and whether they’re viable fallbacks.

slate hound Feb 7, 2026, 11:25 PM

#

I’ll post it

fluid ibexBOT Feb 7, 2026, 11:25 PM

#

slate hound I’ll post it

Perfect — please paste:

openclaw --version
openclaw models status
openclaw models fallbacks list

And then reproduce a 429 once and paste the ~30 log lines around it from:

openclaw logs --follow

Redact any secrets (API keys / tokens) — keep provider/model names + the actual 429 text. Once we see that, we’ll know exactly why it’s not failing over to Groq/Ollama.

slate hound Feb 7, 2026, 11:27 PM

#

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-sonnet-4-20250514
Fallbacks (2) : groq/llama-3.3-70b-versatile, anthropic/claude-opus-4-0520
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): anthropic/claude-sonnet-4-20250514

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...7EvajwAA
groq effective=models.json:gsk_E5Og...mAaaSZnO | models.json=gsk_E5Og...mAaaSZnO | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

none

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — I can grep it, git blame it, and gently roast it—pick your coping mechanism.

Fallbacks (2):

groq/llama-3.3-70b-versatile
anthropic/claude-opus-4-0520

fluid ibexBOT Feb 7, 2026, 11:28 PM

#

slate hound 🦞 OpenClaw 2026.2.6-3 (85ed6c7) — I'm the assistant your terminal demanded, not...

Your models status output explains why Groq “never hits”:

Configured models (1): anthropic/claude-sonnet-4-20250514

That means you do have an allowlist/catalog active (agents.defaults.models) and it currently only contains Sonnet. When that list is present, anything not in it (like your Groq fallback, and also Opus) won’t be eligible to run.

Fix (pick one)

Option A (simplest): remove the allowlist

openclaw config unset agents.defaults.models
openclaw gateway restart

Then re-check:

openclaw models status

#

Option B: keep the allowlist, but add Groq + Opus to it
Easiest via the wizard (it has a multi-select for the allowlist):

openclaw configure --section models

Select:

groq/llama-3.3-70b-versatile
anthropic/claude-opus-4-0520
(and keep Sonnet)

Docs note about this behavior: https://docs.openclaw.ai/concepts/models (see “Model is not allowed” + agents.defaults.models)

One more important detail (Ollama)

Your status also shows no Ollama provider at all, and Shell env: off (service mode), so doing export OLLAMA_API_KEY=... in your terminal won’t affect the running gateway. If you want Ollama as a fallback, add it via config (not shell env) per: https://docs.openclaw.ai/providers/ollama

After you remove/fix the allowlist, if Groq still doesn’t kick in on a 429, paste the 429 snippet from openclaw logs --follow and we’ll see whether it’s actually attempting fallback and what error it gets.

slate hound Feb 7, 2026, 11:29 PM

#

aluti@Halutis-Mac-mini ~ % openclaw config unset agents.defaults.models
openclaw gateway restart

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — The only bot that stays out of your training set.

Config path not found: agents.defaults.models

fluid ibexBOT Feb 7, 2026, 11:31 PM

#

slate hound aluti@Halutis-Mac-mini ~ % openclaw config unset agents.defaults.models openclaw...

Yep — that message just means your raw ~/.openclaw/openclaw.json doesn’t have a key at exactly agents.defaults.models.

But your earlier openclaw models status does show:

Configured models (1): anthropic/claude-sonnet-4-20250514

…and that mismatch (fallbacks=2, configured models=1) is the real smoking gun: your config is restricting the model catalog somewhere, just not at agents.defaults.models (could be per-agent, or in an included file).

Find where the “configured models” restriction lives

Please run these and paste the output:

openclaw config get agents.defaults
openclaw config get agents

Then we’ll spot where the models: block actually is (often it’s under agents.list[].models), and we can remove it or add your fallbacks to it so Groq/Ollama can actually be used.

#

Fast workaround (no sleuthing)

Run the wizard and re-select models (it will update the model allowlist/catalog correctly):

openclaw configure --section models

In that Model section, make sure Sonnet + your Groq fallback + Opus are all selected, then restart.

Once that’s fixed, failover to Groq should start working when Anthropic 429s.

slate hound Feb 7, 2026, 11:33 PM

#

{
"defaults": {
"model": {
"primary": "anthropic/claude-sonnet-4-20250514",
"fallbacks": [
"groq/llama-3.3-70b-versatile",
"anthropic/claude-opus-4-0520"
]
},
"workspace": "/Users/haluti/.openclaw/workspace",
"userTimezone": "America/Sao_Paulo",
"compaction": {
"mode": "safeguard"
},
"thinkingDefault": "low",
"heartbeat": {
"every": "1h",
"activeHours": {
"start": "08:00",
"end": "23:00",
"timezone": "America/Sao_Paulo"
},
"target": "whatsapp",
"to": "+xxxxx"
},
"maxConcurrent": 4,
"subagents": {
"maxConcurrent": 8,
"model": "groq/llama-3.3-70b-versatile"
},
"sandbox": {
"mode": "non-main"
}
}
}

fluid ibexBOT Feb 7, 2026, 11:36 PM

#

slate hound { "defaults": { "model": { "primary": "anthropic/claude-sonnet-4-202...

Got it — that error just means your config file doesn’t currently have a agents.defaults.models key to delete.

But the important clue is still in your models status output:

Configured models (1): anthropic/claude-sonnet-4-20250514

In OpenClaw, fallbacks only work for models that exist in the configured model catalog (agents.defaults.models). Right now your catalog effectively only contains Sonnet, so when Anthropic 429s there’s nothing valid to fall back to (even though the fallback list shows Groq).

Fix: add Groq + Opus into the configured model catalog

Easiest (recommended): run the wizard and select the models:

openclaw configure --section models
openclaw gateway restart

Or do it directly (minimal metadata, just “make these models available”):

#

openclaw config set agents.defaults.models '{
"anthropic/claude-sonnet-4-20250514": {},
"groq/llama-3.3-70b-versatile": {},
"anthropic/claude-opus-4-0520": {}
}' --json

openclaw gateway restart

Then verify:

openclaw models status

You should see Configured models (3) and then Groq should actually get hit when Anthropic throws 429.

If after that it still doesn’t fail over, paste the 429 chunk from openclaw logs --follow and we’ll see what it’s doing.

slate hound Feb 7, 2026, 11:36 PM

#

also, I pull ollama model and export OLLAMA_API_KEY="ollama-local - but can't get it to connect

fluid ibexBOT Feb 7, 2026, 11:37 PM

#

slate hound also, I pull ollama model and export OLLAMA_API_KEY="ollama-local - but can't ge...

export OLLAMA_API_KEY=... won’t help if your Gateway is running as a service (launchd) — your models status already showed Shell env : off, so the Gateway process isn’t inheriting your terminal env.

Do this instead (service-safe):

Verify Ollama is actually reachable from the same machine/network namespace:

curl http://127.0.0.1:11434/api/tags

If that fails, fix Ollama first (ollama serve, firewall, Docker/WSL mismatch, etc.).

Give the Gateway the env var via config (so it persists for the service):

openclaw config set env.vars.OLLAMA_API_KEY "ollama-local"
openclaw gateway restart

Check whether OpenClaw now sees Ollama:

#

openclaw models list --provider ollama
openclaw models status

Notes:

Ollama auto-discovery only lists tool-capable models. If models list --provider ollama is empty, try pulling one of the known tool-capable ones from the docs (e.g. gpt-oss:20b, llama3.3, qwen2.5-coder:32b). Provider doc: https://docs.openclaw.ai/providers/ollama
Separate but important: your earlier models status showed Configured models (1). You’ll want Sonnet and your fallbacks (Groq/Opus/Ollama) present in the configured model catalog, otherwise failover won’t actually have anything valid to switch to. The easiest fix is still:

openclaw configure --section models

slate hound Feb 7, 2026, 11:38 PM

#

fluid ibex ```bash openclaw config set agents.defaults.models '{ "anthropic/claude-sonnet-4...

the models where added to configured model, but the mesage doesnt go through hey

#

haluti@Halutis-Mac-mini ~ % curl http://127.0.0.1:11434/api/tags
{"models":[{"name":"llama3.1:8b","model":"llama3.1:8b","modified_at":"2026-02-07T20:34:14.788409051-03:00","size":4920753328,"digest":"46e087c3c1757cc81b9da4970863ba87ca666e","details":{"parent_model":"","format":"gguf","family":"llama","families":["llama"],"parameter_size":"8.0B","quantization_level":"Q4_K_M"}},{"name":"gemma2:9b","model":"gemma2:9b","modified_at":"2026-02-07T19:21:25.410638406-03:00","size":5443152417,"digest":"ff02c3702f322b9e075e9568332d96c0a7028002f1a5a05","details":{"parent_model":"","format":"gguf","family":"gemma2","families":["gemma2"],"parameter_size":"9.2B","quantization_level":"Q4_0"}}]}% haluti@Halutis-Mac-mini ~ % openclaw config set env.vars.OLLAMA_API_KEY "ollama-local"
openclaw gateway restart

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — I'm like tmux: confusing at first, then suddenly you can't live without me.

Updated env.vars.OLLAMA_API_KEY. Restart the gateway to apply.

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Chat APIs that don't require a Senate hearing.

Restarted LaunchAgent: gui/501/ai.openclaw.gateway
haluti@Halutis-Mac-mini ~ % openclaw models list --provider ollama
openclaw models status

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — I run on caffeine, JSON5, and the audacity of "it worked on my machine."

No models found.

fluid ibexBOT Feb 7, 2026, 11:40 PM

#

slate hound the models where added to configured model, but the mesage doesnt go through he...

If the TUI shows connected | idle and you send hey but get (no output), we need to see whether the Gateway is even receiving the message, or whether it’s immediately erroring on the model call.

Two quick tests:

1) Does the Gateway see any activity when you send `hey`?

In another terminal, run:

openclaw logs --follow

Then send hey again and paste the ~30 lines that appear.

If nothing appears in logs when you send hey, the TUI isn’t actually delivering the message (sometimes after a gateway restart the TUI UI looks connected but the session is stale → quitting and reopening openclaw-tui fixes it).

2) Try a command that doesn’t require an LLM call

In the TUI, send:

#

/model status

(or even /model list)

If that prints output, the TUI→Gateway path is fine and the “hey” is getting stuck in a provider call (429/backoff/etc).
If that also prints nothing, it’s a TUI connection/session issue → restart the TUI.

On the Ollama side: exporting OLLAMA_API_KEY in your shell won’t affect the Gateway service (your earlier output showed Shell env: off). Put it into config instead:

openclaw config set env.vars.OLLAMA_API_KEY "ollama-local"
openclaw gateway restart

#

openclaw models list --provider ollama

And sanity check Ollama itself:

curl http://127.0.0.1:11434/api/tags

Paste the logs --follow chunk first though — that’ll tell us exactly what’s happening when you type hey.

slate hound Feb 7, 2026, 11:41 PM

#

fluid ibex If the TUI shows **connected | idle** and you send `hey` but get **(no output)**...

hey

HTTP 413: Request too large for model llama-3.3-70b-versatile in organization org_01kgwwm16ye0cs768f050m0770 service
tier on_demand on tokens per minute (TPM): Limit 12000, Requested 83592, please reduce your message size and try
again. Need more tokens? Upgrade to Dev Tier today at https://console.groq.com/settings/billing

hey

fluid ibexBOT Feb 7, 2026, 11:42 PM

#

slate hound haluti@Halutis-Mac-mini ~ % curl http://127.0.0.1:11434/api/tags {"models":[{"na...

Nice — that curl /api/tags proves Ollama is up and reachable.

openclaw models list --provider ollama showing “No models found” is expected in one of these cases (and your output strongly suggests the first):

A) Auto-discovery is ON, but none of your installed Ollama models are “tool-capable”

OpenClaw’s Ollama integration auto-discovers models via /api/tags + /api/show, then filters out anything that doesn’t report tools capability. Your current models (llama3.1:8b, gemma2:9b) often don’t advertise tool support, so OpenClaw hides them → “No models found”.

Fix: pull a model that Ollama marks as tool-capable, then re-run the list:

ollama pull llama3.3
# or (from the docs)
ollama pull gpt-oss:20b
ollama pull qwen2.5-coder:32b

openclaw models list --provider ollama

#

Provider doc (explains the filtering + options):
https://docs.openclaw.ai/providers/ollama

B) You have an explicit `models.providers.ollama` config (disables auto-discovery)

If you (or the wizard) set models.providers.ollama explicitly, OpenClaw will stop auto-discovering and expects you to list models manually.

Quick check:

openclaw config get models.providers.ollama

If it prints something → you’re in “explicit mode” and we should add a models: [...] list there.
If it says path not found → you’re in auto-discovery mode (case A).

One more important thing

You did the right thing putting OLLAMA_API_KEY into config (env.vars...) — because your Gateway runs as a LaunchAgent and won’t see export ... from your terminal.

If you paste the output of:

#

openclaw config get models.providers.ollama

…I can tell you immediately whether you should “pull a different model” (A) or “add explicit provider config” (B).

slate hound Feb 7, 2026, 11:43 PM

#

fluid ibex If the TUI shows **connected | idle** and you send `hey` but get **(no output)**...

fluid ibexBOT Feb 7, 2026, 11:44 PM

#

That log is actually good news: it is hitting Groq now. The problem is why it fails:

HTTP 413 ... tokens per minute (TPM): Limit 12000, Requested 83592

So when Anthropic rate-limits and OpenClaw falls back to groq/llama-3.3-70b-versatile, it tries to send your huge current session context (~105k tokens shown in the TUI) to Groq. On your Groq tier, a single request that large is rejected (it’s bigger than your org’s TPM budget), so fallback can’t succeed.

Fix right now (fastest)

In openclaw-tui, do a fresh session and try again:

send: /new
then send: hey

This should drop the context size massively, and Groq will stop 413’ing.

If you want to keep the current session but shrink it:

send: /compact Keep this extremely short (1-2 pages max).
then try again

#

(Compaction doc: https://docs.openclaw.ai/concepts/compaction)

Longer-term options

Groq is a poor “emergency fallback” for very long sessions unless you keep sessions compact/new fairly often.
Either upgrade your Groq tier (higher TPM), or pick a fallback provider/model that can accept larger prompts, or keep your main chat smaller (more /new, more /compact, use sub-agents for long work).

On the Ollama side: openclaw models list --provider ollama returning “No models found” is because OpenClaw’s Ollama auto-discovery only keeps models that report tool support. Your installed Ollama models (llama3.1:8b, gemma2:9b) often don’t, so they get filtered out.

Try pulling a tool-capable model and re-check:

ollama pull llama3.3
# or from docs:
ollama pull gpt-oss:20b

#

ollama pull qwen2.5-coder:32b

openclaw models list --provider ollama

Provider doc: https://docs.openclaw.ai/providers/ollama

If you run /new and it still “doesn’t go through”, paste the openclaw logs --follow chunk for that attempt.

#

That error usually happens when you type model status (no leading slash). OpenClaw then interprets it as “set my model to status”, which becomes anthropic/status → and of course that “model” is not allowed / doesn’t exist.

Use the actual slash command as a standalone message:

/model status

(or)

/model list

If you just want the diagnostic output without the TUI, the terminal command is:

#

openclaw models status

Also: your TUI shows ~105k tokens in the session. If you’re testing Groq fallback, do:

/new

then try a short message again — otherwise Groq will keep rejecting the giant prompt (that’s the 413 you saw).

slate hound Feb 7, 2026, 11:46 PM

#

fluid ibex Nice — that `curl /api/tags` proves Ollama is up and reachable. `openclaw model...

haluti@Halutis-Mac-mini ~ % ollama pull llama3.3
pulling manifest
pulling 4824460d29f2: 23% ▕█████████████ ▏ 9.8 GB/ 42 GB 98 MB/s is this correct? 42GB?

slate hound Feb 7, 2026, 11:46 PM

#

fluid ibex ```bash openclaw config get models.providers.ollama ``` …I can tell you immediat...

aluti@Halutis-Mac-mini ~ % openclaw config get models.providers.ollama

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — I keep secrets like a vault... unless you print them in debug logs again.

Config path not found: models.providers.ollama

fluid ibexBOT Feb 7, 2026, 11:46 PM

#

slate hound haluti@Halutis-Mac-mini ~ % ollama pull llama3.3 pulling manifest pulling 48244...

Yes — that’s “correct” in the sense that llama3.3 on Ollama is a huge model (it’s the big Llama 3.3 family), so a ~42GB download is normal.

Two practical notes:

Hardware reality check

That size usually implies you’ll want a lot of RAM to run it comfortably (think 64GB-ish territory). On many Mac minis it’ll be painfully slow or won’t run well.
If that’s not what you intended, you can Ctrl+C to cancel the pull.

You don’t need llama3.3 specifically just to make OpenClaw “see Ollama”
OpenClaw auto-discovery only lists Ollama models that report tool support, so your existing llama3.1:8b / gemma2:9b didn’t show up.

Your options:

Pull a smaller tool-capable model (the docs mention gpt-oss:20b, but it’s also big).
Or, if you’re fine using a local model as a “basic chat fallback” (even if it doesn’t advertise tools), switch to explicit Ollama config and manually list your existing model so OpenClaw will use it.

Before we pick: what Mac mini spec do you have (RAM)? 8 / 16 / 32 / 64GB.

slate hound Feb 7, 2026, 11:47 PM

#

fluid ibex That log is actually good news: **it *is* hitting Groq now**. The problem is *wh...

i did it and still no output

openclaw tui - ws://127.0.0.1:18789 - agent main - session main

session agent:main:main

hey

fluid ibexBOT Feb 7, 2026, 11:48 PM

#

slate hound aluti@Halutis-Mac-mini ~ % openclaw config get models.providers.ollama 🦞 OpenC...

Yeah — 42GB can be totally normal for llama3.3 on Ollama. It’s downloading a very large model variant.

But you don’t need to pull a 42GB model just to make OpenClaw connect to Ollama.

Your openclaw config get models.providers.ollama → “path not found” means you’re in auto-discovery mode. In that mode OpenClaw will only list Ollama models that report tool support. Your currently installed models (llama3.1:8b, gemma2:9b) are reachable (curl works) but likely don’t advertise tools, so OpenClaw filters them out → No models found.

Option 1 (recommended): stop the 42GB pull + explicitly configure Ollama

You can keep using your existing small local model as a basic chat fallback by defining it manually:

# Tell OpenClaw how to reach Ollama (explicit provider = no auto-discovery)
openclaw config set models.mode "merge"
openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434/v1"
openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw config set models.providers.ollama.api "openai-completions"

#


openclaw config set models.providers.ollama.models '[
{
"id": "llama3.1:8b",
"name": "Llama 3.1 8B (Ollama)",
"reasoning": false,
"input": ["text"],
"cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
"contextWindow": 8192,
"maxTokens": 2048
}
]' --json

openclaw gateway restart
openclaw models list --provider ollama

#

Provider doc: https://docs.openclaw.ai/providers/ollama

Option 2: finish pulling a tool-capable model (but it’ll be big)

If you want auto-discovery, you need an Ollama model that reports tools; llama3.3 might do that, but it’s huge.

One important gotcha (this affects Groq too)

Your TUI shows ~105k tokens in the current session. Neither Groq (your tier) nor typical local Ollama models will handle that well:

Groq already failed with TPM 413 because the prompt was enormous.
Ollama 8k context models will just overflow.

So for testing fallbacks, do:

/new (or /compact) first, then retry.

If you tell me your Mac mini RAM (16/32/64GB), I can tell you whether finishing llama3.3 is a good idea or a waste of time.

slate hound Feb 7, 2026, 11:48 PM

#

fluid ibex Yes — that’s “correct” in the sense that **`llama3.3` on Ollama is a *huge* mode...

macmini 16gb - i can just erase ollama if you think it wont work

slate hound Feb 7, 2026, 11:49 PM

#

fluid ibex ```bash openclaw config set models.providers.ollama.models '[ { "id": "llama3.1...

aluti@Halutis-Mac-mini ~ % openclaw config set models.providers.ollama.models '[
{
"id": "llama3.1:8b",
"name": "Llama 3.1 8B (Ollama)",
"reasoning": false,
"input": ["text"],
"cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
"contextWindow": 8192,
"maxTokens": 2048
}
]' --json

openclaw gateway restart
openclaw models list --provider ollama
Error: Config validation failed: models.providers.ollama.baseUrl: Invalid input: expected string, received undefined

fluid ibexBOT Feb 7, 2026, 11:49 PM

#

If you did /new and the TUI still shows (no output) with tokens 0, that strongly suggests the run isn’t even starting.

In the OpenClaw TUI there’s one big “gotcha”: delivery is OFF by default. If delivery is off, you can end up typing messages that don’t actually get executed/delivered the way you expect.

Try this in the TUI (as standalone messages):

Check state:

/status

Turn delivery on:

/deliver on

Then send:

#

hey

If it still shows no output, run this in another terminal:

openclaw logs --follow

…and send hey again in the TUI. Paste the log lines that appear (that will tell us whether the message is being received and why a run isn’t triggered).

(Also: the earlier Groq error you pasted confirms fallback is working, but your Groq tier rejects huge prompts. /new is the right fix for that.)

slate hound Feb 7, 2026, 11:50 PM

#

fluid ibex If you did `/new` and the TUI still shows **(no output)** with **tokens 0**, tha...

Gateway status

WhatsApp: linked (last refreshed 1m ago)

Heartbeat: 1h (main)

Session store: /Users/haluti/.openclaw/agents/main/sessions/sessions.json

Default model: claude-sonnet-4-20250514 (200k ctx)

Active sessions: 2

Recent sessions:

agent:main:main [direct] | 3m ago | model claude-opus-4-6 | tokens 0/200k (200k left, 0%) | flags: system,
id:fe365cc5-f3bd-46dc-95c2-a5bf7f551631
agent:main:dm:+5511959771170 [direct] | 13m ago | model claude-sonnet-4-20250514 | tokens 0/200k (200k left, 0%) |
flags: system, id:f4b628e8-f782-4f32-ba0c-5d87f539d3a1

slate hound Feb 7, 2026, 11:51 PM

#

fluid ibex ```text hey ``` If it *still* shows no output, run this in another terminal: ``...

23:50:37 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=175 error="FailoverError: Context overflow: prompt too large for the model. Try again with less input or a larger-context model."
23:50:37 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:main durationMs=178 error="FailoverError: Context overflow: prompt too large for the model. Try again with less input or a larger-context model."
23:50:37 error Embedded agent failed before reply: All models failed (3): anthropic/claude-sonnet-4-20250514: Provider anthropic is in cooldown (all profiles unavailable) (rate_limit) | groq/llama-3.3-70b-versatile: Context overflow: prompt too large for the model. Try again with less input or a larger-context model. (billing) | anthropic/claude-opus-4-0520: Provider anthropic is in cooldown (all profiles unavailable) (rate_limit)
23:50:46 debug plugins {"subsystem":"plugins"} plugin CLI register skipped (memory-core): command already registered (memory)
Log tail truncated (increase --max-bytes).
23:50:52 info web-heartbeat {"module":"web-heartbeat","runId":"c2d731f4-c147-4c71-a58a-5269ed6af55b"} {"connectionId":"e492a086-0874-44f0-90d6-bd54f594921e","reconnectAttempts":0,"messagesHandled":0,"lastMessageAt":null,"authAgeMs":119998.40283203125,"uptimeMs":121340} web gateway heartbeat

fluid ibexBOT Feb 7, 2026, 11:51 PM

#

That error is just because you tried to add models.providers.ollama.models without defining models.providers.ollama.baseUrl first. In “explicit Ollama config” mode, baseUrl is required.

Run these (in this order):

openclaw config set models.mode "merge"
openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434/v1"
openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw config set models.providers.ollama.api "openai-completions"

openclaw config set models.providers.ollama.models '[
{
"id": "llama3.1:8b",
"name": "Llama 3.1 8B (Ollama)",
"reasoning": false,
"input": ["text"],

#

"cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
"contextWindow": 8192,
"maxTokens": 2048
}
]' --json

openclaw gateway restart
openclaw models list --provider ollama

If you’re using the “configured models” allowlist (agents.defaults.models), also add the Ollama model there, otherwise it still won’t be eligible as a fallback:

openclaw config set agents.defaults.models."ollama/llama3.1:8b" '{}' --json
openclaw gateway restart

#

Docs: https://docs.openclaw.ai/providers/ollama

Mac mini 16GB: I would cancel the 42GB llama3.3 pull. It’s not that it can never run, but it’s usually a miserable experience on 16GB (slow / swapping / heat), and it won’t solve your main issue (fallback reliability) better than a smaller local model for “basic chat”.

You don’t need to “erase Ollama” entirely — keeping llama3.1:8b as a last-ditch fallback is reasonable.

To clean up if you started pulling llama3.3:

Ctrl+C to stop the pull
then (if it shows up in ollama list) run: ollama rm llama3.3

One more thing from your earlier TUI screenshot: if you see (no output) in the TUI, run this in the TUI:

#

/deliver on
/status

Then try hey again. If it still doesn’t respond, paste the chunk from openclaw logs --follow right after you send it.

#

Context overflow: prompt too large for the model. Try again with less input or a larger-context model.

slate hound Feb 7, 2026, 11:53 PM

#

**5c57a050 sessionId=8fedf1de-8e91-46bb-9f0d-de221f2e5ca5 durationMs=204
23:53:00 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=8fedf1de-8e91-46bb-9f0d-de221f2e5ca5 sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
23:53:00 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=8fedf1de-8e91-46bb-9f0d-de221f2e5ca5 totalActive=0
23:53:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=240 error="FailoverError: Context overflow: prompt too large for the model. Try again with less input or a larger-context model."
23:53:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:main durationMs=242 error="FailoverError: Context overflow: prompt too large for the model. Try again with less input or a larger-context model."
23:53:00 error Embedded agent failed before reply: All models failed (3): anthropic/claude-sonnet-4-20250514: Provider anthropic is in cooldown (all profiles unavailable) (rate_limit) | groq/llama-3.3-70b-versatile: Context overflow: prompt too large for the model. Try again with less input or a larger-context model. (billing) | anthropic/claude-opus-4-0520: Provider anthropic is in cooldown (all profiles unavailable) (rate_limit)
23:53:11 debug plugins {"subsystem":"plugins"} plugin CLI register skipped (memory-core): command already registered (memory)
Log tail truncated (increase --max-bytes).

**

#

i already did new deliver and status on tui, and still no response

fluid ibexBOT Feb 7, 2026, 11:55 PM

#

slate hound **5c57a050 sessionId=8fedf1de-8e91-46bb-9f0d-de221f2e5ca5 durationMs=204 23:53:0...

Context overflow: prompt too large for the model. Try again with less input or a larger-context model.

slate hound Feb 7, 2026, 11:55 PM

#

try models status again and shell ev and ollama are gone

haluti@Halutis-Mac-mini ~ % openclaw models status

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Your messages, your servers, your control.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-sonnet-4-20250514
Fallbacks (2) : groq/llama-3.3-70b-versatile, anthropic/claude-opus-4-0520
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (3): anthropic/claude-sonnet-4-20250514, groq/llama-3.3-70b-versatile, anthropic/claude-opus-4-0520

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...7EvajwAA [cooldown 9m]
groq effective=models.json:gsk_E5Og...mAaaSZnO | models.json=gsk_E5Og...mAaaSZnO | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

none
haluti@Halutis-Mac-mini ~ %

slate hound Feb 7, 2026, 11:55 PM

#

fluid ibex Context overflow: prompt too large for the model. Try again with less input or a...

i only sent HEY

fluid ibexBOT Feb 7, 2026, 11:56 PM

#

Context overflow: prompt too large for the model. Try again with less input or a larger-context model.

slate hound Feb 7, 2026, 11:56 PM

#

openclaw config set models.mode "merge"
openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434/v1"
openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw config set models.providers.ollama.api "openai-completions
haluti@Halutis-Mac-mini ~ % openclaw config set models.providers.ollama.models '[
{
"id": "llama3.1:8b",
"name": "Llama 3.1 8B (Ollama)",
"reasoning": false,
"input": ["text"],
"cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
"contextWindow": 8192,
"maxTokens": 2048
}
]' --json

openclaw gateway restart
openclaw models list --provider ollama

Error: Config validation failed: models.providers.ollama.baseUrl: Invalid input: expected string, received undefined

fluid ibexBOT Feb 7, 2026, 11:57 PM

#

Context overflow: prompt too large for the model. Try again with less input or a larger-context model.

fluid ibexBOT Feb 7, 2026, 11:57 PM

#

slate hound openclaw config set models.mode "merge" openclaw config set models.providers.oll...

Your copy/paste has a small typo that likely caused the whole sequence to not apply:

You have this line (missing the closing quote):

openclaw config set models.providers.ollama.api "openai-completions

When that happens, the shell treats everything after as part of the string, so the later commands don’t run correctly — and you end up with models.providers.ollama half-created but without baseUrl, which triggers:

models.providers.ollama.baseUrl: expected string, received undefined

Fix: run these exactly (one by one)

openclaw config set models.mode "merge"
openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434/v1"
openclaw config set models.providers.ollama.apiKey "ollama-local"

#

openclaw config set models.providers.ollama.api "openai-completions"

Sanity check (this should print the URL, not “path not found”):

openclaw config get models.providers.ollama.baseUrl

Now add the model (note: I’d bump contextWindow above 8192 — Llama 3.1 can do much more):

openclaw config set models.providers.ollama.models '[
{
"id": "llama3.1:8b",
"name": "Llama 3.1 8B (Ollama)",
"reasoning": false,

#

"input": ["text"],
"cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
"contextWindow": 128000,
"maxTokens": 2048
}
]' --json

Restart + verify:

openclaw gateway restart
openclaw models list --provider ollama

Important: add Ollama to your configured models allowlist too

Your models status shows Configured models (3) (so the allowlist is active). Add Ollama there or it still won’t be eligible:

#

openclaw config set agents.defaults.models."ollama/llama3.1:8b" '{}' --json
openclaw gateway restart

If openclaw models list --provider ollama still shows “No models found” after this, paste:

openclaw config get models.providers.ollama

slate hound Feb 7, 2026, 11:58 PM

#

fluid ibex Your copy/paste has a small typo that likely caused the whole sequence to not ap...

haluti@Halutis-Mac-mini ~ % openclaw config set models.mode "merge"
openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434/v1"
openclaw config set models.providers.ollama.apiKey "ollama-local"

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — curl for conversations.

Updated models.mode. Restart the gateway to apply.

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Welcome to the command line: where dreams compile and confidence segfaults.

Error: Config validation failed: models.providers.ollama.models: Invalid input: expected array, received undefined

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Ah, the fruit tree company! 🍎

Error: Config validation failed: models.providers.ollama.baseUrl: Invalid input: expected string, received undefined
haluti@Halutis-Mac-mini ~ %

fluid ibexBOT Feb 7, 2026, 11:59 PM

#

slate hound haluti@Halutis-Mac-mini ~ % openclaw config set models.mode "merge" openclaw con...

That error is because openclaw config set … validates the whole config after each single change. For the Ollama provider, the schema expects a complete provider object (including a models: [] array). So trying to set just baseUrl (or just apiKey) leaves models.providers.ollama “half-defined” during validation → it fails.

Fix: set the entire models.providers.ollama object in ONE command:

openclaw config set models.providers.ollama '{
baseUrl: "http://127.0.0.1:11434/v1",
apiKey: "ollama-local",
api: "openai-completions",
models: [
{
id: "llama3.1:8b",
name: "Llama 3.1 8B (Ollama)",
reasoning: false,
input: ["text"],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },

#

contextWindow: 8192,
maxTokens: 2048
}
]
}' --json

openclaw gateway restart
openclaw models list --provider ollama

If you’re keeping the “configured models” catalog active (you are), also add the Ollama model there so it’s eligible:

openclaw config set agents.defaults.models."ollama/llama3.1:8b" '{}' --json
openclaw gateway restart

#

One important heads-up: with Mac mini 16GB, llama3.1:8b is fine, but its 8k context may still be too small for OpenClaw’s full prompt + tools (so it might also overflow). If that happens, local Ollama won’t save you from Anthropic cooldowns; you’ll need a fallback provider/model with a much larger context window.

Also your models status shows anthropic … [cooldown 9m] — until that clears, you’ll keep seeing “no output” because Anthropic is skipped and Groq is failing. Reducing concurrency helps prevent that:

openclaw config set agents.defaults.maxConcurrent 1 --json
openclaw config set agents.defaults.subagents.maxConcurrent 1 --json
openclaw gateway restart

If you paste the output of openclaw models list --all --provider groq, we can pick a Groq fallback that actually has enough context on your account (if any).

slate hound Feb 8, 2026, 12:00 AM

#

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — If something's on fire, I can't extinguish it—but I can write a beautiful postmortem.

No models found.
haluti@Halutis-Mac-mini ~ % openclaw config set models.providers.ollama '{
baseUrl: "http://127.0.0.1:11434/v1",
apiKey: "ollama-local",
api: "openai-completions",
models: [
{
id: "llama3.1:8b",
name: "Llama 3.1 8B (Ollama)",
reasoning: false,
input: ["text"],
cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },contextWindow: 8192,
maxTokens: 2048
}
]
}' --json

openclaw gateway restart
openclaw models list --provider ollama

Updated models.providers.ollama. Restart the gateway to apply.

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Chat APIs that don't require a Senate hearing.

Restarted LaunchAgent: gui/501/ai.openclaw.gateway

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Meta wishes they shipped this fast.

No models found.
haluti@Halutis-Mac-mini ~ %

fluid ibexBOT Feb 8, 2026, 12:01 AM

#

slate hound 🦞 OpenClaw 2026.2.6-3 (85ed6c7) — If something's on fire, I can't extinguish it...

Context overflow: prompt too large for the model. Try again with less input or a larger-context model.

slate hound Feb 8, 2026, 12:02 AM

#

fluid ibex One important heads-up: with **Mac mini 16GB**, `llama3.1:8b` is fine, but its *...

Restarted LaunchAgent: gui/501/ai.openclaw.gateway
haluti@Halutis-Mac-mini ~ % openclaw models list --all --provider groq

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

Model Input Ctx Local Auth Tags
groq/deepseek-r1-distill-llama-70b text 128k no yes
groq/gemma2-9b-it text 8k no yes
groq/llama-3.1-8b-instant text 128k no yes
groq/llama-3.3-70b-versatile text+image 125k no yes fallback#1,configured
groq/llama3-70b-8192 text 8k no yes
groq/llama3-8b-8192 text 8k no yes
groq/meta-llama/llama-4-maverick-17b-12... text+image 128k no yes
groq/meta-llama/llama-4-scout-17b-16e-i... text+image 128k no yes
groq/mistral-saba-24b text 32k no yes
groq/moonshotai/kimi-k2-instruct text 128k no yes
groq/moonshotai/kimi-k2-instruct-0905 text 256k no yes
groq/openai/gpt-oss-120b text 128k no yes
groq/openai/gpt-oss-20b text 128k no yes
groq/qwen-qwq-32b text 128k no yes
groq/qwen/qwen3-32b text 128k no yes

fluid ibexBOT Feb 8, 2026, 12:03 AM

#

slate hound Restarted LaunchAgent: gui/501/ai.openclaw.gateway haluti@Halutis-Mac-mini ~ % o...

Context overflow: prompt too large for the model. Try again with less input or a larger-context model.

slate hound Feb 8, 2026, 2:15 AM

#

i see some bots working super well, mine is always crashing (agent failed) independent on models

fluid ibexBOT Feb 8, 2026, 2:16 AM

#

slate hound i see some bots working super well, mine is always crashing (agent failed) indep...

Context overflow: prompt too large for the model. Try again with less input or a larger-context model.

slate hound Feb 8, 2026, 2:17 AM

#

⚠️ Agent failed before reply: Unknown model: anthropic/claude-opus-4-0520.
Logs: openclaw logs --follow

Why if its configured

fluid ibexBOT Feb 8, 2026, 2:19 AM

#

slate hound ⚠️ Agent failed before reply: Unknown model: anthropic/claude-opus-4-0520. Logs:...

Because “Configured models” ≠ “known/available model IDs.”

openclaw models status shows your allowlist/catalog (agents.defaults.models) plus your primary/fallback selection — but the actual “is this a real model ID the provider registry knows?” check happens when the agent tries to run. If the provider catalog for your OpenClaw build doesn’t include anthropic/claude-opus-4-0520, you’ll get:

Unknown model: anthropic/claude-opus-4-0520

Step 1: See the valid Anthropic model IDs on your install

Run:

openclaw models list --all --provider anthropic

Pick the Opus model ID from that list.

Step 2: Update BOTH places in config

You need to update:

the fallback list (agents.defaults.model.fallbacks)
and the configured model catalog (agents.defaults.models) so it’s allowed

#

Fastest safe path (avoids hand-typing IDs) is:

openclaw configure --section models

…and select the Opus entry it offers.

Quick workaround (stop the “agent failed” loop)

Until you fix the Opus ID, remove it from fallbacks so it doesn’t hard-fail when Anthropic is cooling down:

openclaw config set agents.defaults.model.fallbacks '[
"groq/moonshotai/kimi-k2-instruct-0905"
]' --json
openclaw gateway restart

If you paste the output of openclaw models list --all --provider anthropic I can tell you exactly which Opus ID to swap in (without guessing).

slate hound Feb 8, 2026, 2:24 AM

#

give me the code to configure in both places

fluid ibexBOT Feb 8, 2026, 2:24 AM

#

slate hound give me the code to configure in both places

Don’t use anthropic/claude-opus-4-0520 (your install doesn’t know that ID). First grab the exact Opus model id that your OpenClaw build lists, then set it in both:

0) Find the valid Opus ID on your machine

openclaw models list --all --provider anthropic

Copy the Opus line exactly (it will be something like anthropic/claude-opus-…).

1) Set it in both places (fallbacks + configured catalog)

Replace PASTE_OPUS_ID_HERE with what you copied:

OPUS="PASTE_OPUS_ID_HERE"

# Put it in fallbacks (example keeps your Groq fallback first)
openclaw config set agents.defaults.model.fallbacks "[\"groq/moonshotai/kimi-k2-instruct-0905\", \"$OPUS\"]" --json

#


# Add both models to the configured model catalog (allowlist)
openclaw config set agents.defaults.models.\"groq/moonshotai/kimi-k2-instruct-0905\" '{}' --json
openclaw config set agents.defaults.models.\"$OPUS\" '{}' --json

openclaw gateway restart
openclaw models status

If you don’t want the Groq fallback, just remove it from that fallbacks array.

(Strongly recommended) prevent the 429/cooldown spiral

openclaw config set agents.defaults.maxConcurrent 1 --json
openclaw config set agents.defaults.subagents.maxConcurrent 1 --json

#

openclaw gateway restart

If you paste the output of openclaw models list --all --provider anthropic (just the model lines), I can tell you which exact Opus ID to use.

slate hound Feb 8, 2026, 2:51 AM

#

how to reset models?

fluid ibexBOT Feb 8, 2026, 2:52 AM

#

slate hound how to reset models?

Two ways, depending on what you mean by “reset”:

Option A (recommended): reset via wizard (cleanest)

This rebuilds your model config without you hand-editing IDs:

openclaw configure --section models
openclaw gateway restart

Option B: hard-reset model settings by CLI (keep your API keys/auth)

This clears fallbacks + removes the configured-model allowlist, and puts you back on Sonnet:

# set a sane default
openclaw models set anthropic/claude-sonnet-4-20250514

#

# clear fallbacks (these are what caused most “agent failed” cascades)
openclaw models fallbacks clear
openclaw models image-fallbacks clear

# remove the configured model allowlist/catalog (so OpenClaw can use the full built-in registry)
openclaw config unset agents.defaults.models

# optional: remove Ollama custom provider if you added it and want it gone
openclaw config unset models.providers.ollama
openclaw config unset env.vars.OLLAMA_API_KEY

openclaw gateway restart
openclaw models status

If any config unset … says “Config path not found”, that’s fine — it just means it wasn’t set.

slate hound Feb 8, 2026, 2:54 AM

#

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Your .env is showing; don't worry, I'll pretend I didn't see it.

Invalid --section: models. Expected one of: workspace, model, web, gateway, daemon, channels, skills, health.

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — I read logs so you can keep pretending you don't have to.

Restarted LaunchAgent: gui/501/ai.openclaw.gateway
haluti@Halutis-Mac-mini ~ %

fluid ibexBOT Feb 8, 2026, 2:54 AM

#

slate hound 🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Your .env is showing; don't worry, I'll prete...

On your version, the configure wizard section name is model (singular), not models.

Use:

openclaw configure --section model

(or just run the full wizard with no section filter:)

openclaw configure

Then restart (if the wizard doesn’t already do it):

#

openclaw gateway restart

If your goal is a “clean slate” model-wise, the fastest reset (without the wizard) is still:

openclaw models fallbacks clear
openclaw models image-fallbacks clear
openclaw config unset agents.defaults.models
openclaw gateway restart
openclaw models status

If you paste openclaw config get agents.defaults.models after this, I can confirm whether the allowlist is fully gone.

slate hound Feb 8, 2026, 2:55 AM

#

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Chat APIs that don't require a Senate hearing.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-opus-4-5-20251101
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): anthropic/claude-opus-4-5-20251101

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...8s8okAAA | models.json=sk-ant-a...8s8okAAA | source=models.json: ~/.openclaw/agents/main/agent/models.json
groq effective=models.json:gsk_E5Og...mAaaSZnO | models.json=gsk_E5Og...mAaaSZnO | source=models.json: ~/.openclaw/agents/main/agent/models.json
ollama effective=env:ollama-local | env=ollama-local | source=env: OLLAMA_API_KEY | models.json=ollama-local | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

none
haluti@Halutis-Mac-mini ~ %

is this efficient? learn well? fallback works?

fluid ibexBOT Feb 8, 2026, 2:55 AM

#

slate hound 🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Chat APIs that don't require a Senate hearing...

This is a cleaner state than before (good), but it’s not “efficient + robust” yet.

What your status means

Default: anthropic/claude-opus-4-5-20251101
Fallbacks: none (Fallbacks (0))
Configured models (1): only that Opus model is allowed in the catalog

So:

It will work when Anthropic isn’t rate-limiting you.
If Anthropic 429s again → you’re back to “agent failed / no reply” because you have no usable fallback configured.

“Efficient?”

Opus is great but it’s usually the least efficient/costly option. If your main issue is 429 + stability, I’d normally run Sonnet as primary and keep Opus for “heavy” tasks (or as a non-429 fallback, but note: Opus shares Anthropic limits, so it doesn’t help for 429 events).

“Learn well?”

OpenClaw “learning” (memory/session) is not really about the model choice — it’s about your session/memory files. Model choice mainly affects quality/cost and how often you hit rate limits.

#

Make fallback actually work (recommended)

Pick a fallback that’s not Anthropic, otherwise 429 takes out everything.

Since you already have Groq auth, add a big-context Groq model (you have 256k available):

openclaw config set agents.defaults.model.primary "anthropic/claude-sonnet-4-20250514"

openclaw config set agents.defaults.model.fallbacks '[
"groq/moonshotai/kimi-k2-instruct-0905"
]' --json

# Expand the configured model catalog so the fallback is actually eligible
openclaw config set agents.defaults.models '{
"anthropic/claude-sonnet-4-20250514": {},
"groq/moonshotai/kimi-k2-instruct-0905": {},

#

"anthropic/claude-opus-4-5-20251101": {}
}' --json

openclaw gateway restart
openclaw models status

Also: prevent the Anthropic 429 spiral

This is the biggest stability win:

openclaw config set agents.defaults.maxConcurrent 1 --json
openclaw config set agents.defaults.subagents.maxConcurrent 1 --json
openclaw gateway restart

Quick test that fallback works

#

After restart:

/new
send a normal message
temporarily simulate “Anthropic down” by setting model to the Groq one via /model (or openclaw models set … for a minute) and confirm you get a reply.

If you want, paste openclaw config get agents.defaults.model and I’ll sanity-check the final primary/fallback order.

slate hound Feb 8, 2026, 2:56 AM

#

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Your AI assistant, now without the $3,499 headset.

Updated agents.defaults.model.primary. Restart the gateway to apply.
Updated agents.defaults.model.fallbacks. Restart the gateway to apply.
zsh: command not found: #
Updated agents.defaults.models. Restart the gateway to apply.

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — We ship features faster than Apple ships calculator updates.

Restarted LaunchAgent: gui/501/ai.openclaw.gateway

fluid ibexBOT Feb 8, 2026, 2:57 AM

#

slate hound 🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Your AI assistant, now without the $3,499 hea...

Nice — that all basically worked. The only “error” there:

zsh: command not found: #

…is just because you pasted the comment line that starts with # without a newline or in a context where it got treated as a command. You can ignore it; it didn’t break the config writes.

Now do a quick verification:

openclaw models status

You want to see:

Default: anthropic/claude-sonnet-4-20250514
Fallbacks: includes groq/moonshotai/kimi-k2-instruct-0905
Configured models: includes at least those + your Opus entry

#

Then test in TUI:

/new
send hey

If Anthropic is rate-limited right now, you can force-test the fallback by switching the session model:

/model groq/moonshotai/kimi-k2-instruct-0905

If that replies, your fallback path is working.

slate hound Feb 8, 2026, 2:57 AM

#

no, i actually want the opus 4.5 or 4.6

fluid ibexBOT Feb 8, 2026, 2:58 AM

#

slate hound no, i actually want the opus 4.5 or 4.6

Cool — just don’t guess the Opus ID (that’s what caused the earlier “Unknown model” error). Use the exact model string your install knows, then set it as primary.

1) Find the Opus 4.6 (or 4.5) ID your OpenClaw knows

Run:

openclaw models list --all --provider anthropic | grep -i opus

Pick the exact line you want (Opus 4.6 if it’s listed; otherwise Opus 4.5).

2) Set Opus as primary + keep a non-Anthropic fallback (so 429 doesn’t kill you)

Replace PASTE_OPUS_ID_HERE with what you copied:

OPUS="PASTE_OPUS_ID_HERE"

#


openclaw config set agents.defaults.model.primary "$OPUS"
openclaw config set agents.defaults.model.fallbacks '[
"groq/moonshotai/kimi-k2-instruct-0905"
]' --json

# Make sure both are in the configured model catalog (allowlist)
openclaw config set agents.defaults.models."$OPUS" '{}' --json
openclaw config set agents.defaults.models."groq/moonshotai/kimi-k2-instruct-0905" '{}' --json

openclaw gateway restart
openclaw models status

3) (Strongly recommended) reduce concurrency to avoid Anthropic cooldowns

#

openclaw config set agents.defaults.maxConcurrent 1 --json
openclaw config set agents.defaults.subagents.maxConcurrent 1 --json
openclaw gateway restart

If you paste the output of openclaw models list --all --provider anthropic | grep -i opus, I’ll tell you which exact Opus 4.6/4.5 line to use.

slate hound Feb 8, 2026, 2:59 AM

#

haluti@Halutis-Mac-mini ~ % openclaw models list --all --provider anthropic | grep -i opus
anthropic/claude-3-opus-20240229 text+image 195k no yes
anthropic/claude-opus-4-0 text+image 195k no yes
anthropic/claude-opus-4-1 text+image 195k no yes
anthropic/claude-opus-4-1-20250805 text+image 195k no yes
anthropic/claude-opus-4-20250514 text+image 195k no yes
anthropic/claude-opus-4-5 text+image 195k no yes
anthropic/claude-opus-4-5-20251101 text 488k no yes configured
anthropic/claude-opus-4-6 text+image 195k no yes
haluti@Halutis-Mac-mini ~ %

i want the main as 4.5 opus - does it help if there is a second api for anthropic?

fluid ibexBOT Feb 8, 2026, 2:59 AM

#

slate hound haluti@Halutis-Mac-mini ~ % openclaw models list --all --provider anthropic | gr...

Use anthropic/claude-opus-4-5 as your primary (that’s the exact ID your install knows).

Here’s the config code to set it as main and make sure it’s allowed, with a Groq fallback so 429 doesn’t brick you:

openclaw config set agents.defaults.model.primary "anthropic/claude-opus-4-5"

openclaw config set agents.defaults.model.fallbacks '[
"groq/moonshotai/kimi-k2-instruct-0905"
]' --json

openclaw config set agents.defaults.models '{
"anthropic/claude-opus-4-5": {},
"groq/moonshotai/kimi-k2-instruct-0905": {}
}' --json

#

openclaw gateway restart
openclaw models status

(You can add Sonnet too if you want a “cheaper primary for daily chat”, but you asked for Opus as main.)

Does a second Anthropic API key help?

Yes, it can help with 429 if the rate limit is per-key/account and you’re actually saturating one key. OpenClaw can rotate between multiple Anthropic auth profiles (failover within provider) before switching models. That’s documented under model failover/cooldowns: https://docs.openclaw.ai/concepts/model-failover

But: if your Anthropic limit is effectively “account-wide” (or you’re just sending too many concurrent requests), a second key won’t magically fix it.

If you want to try two keys, the simplest pattern is:

store both in auth profiles, and
set auth.order.anthropic so OpenClaw rotates them deterministically.

Before doing that, I’d also strongly reduce concurrency (this is the most common 429 cause):

#

openclaw config set agents.defaults.maxConcurrent 1 --json
openclaw config set agents.defaults.subagents.maxConcurrent 1 --json
openclaw gateway restart

slate hound Feb 8, 2026, 3:00 AM

#

send me the code for me to add a second anthropic key and you put sonnet

fluid ibexBOT Feb 8, 2026, 3:02 AM

#

slate hound send me the code for me to add a second anthropic key and you put sonnet

Run these on the gateway host (your Mac mini). Don’t paste any keys into Discord.

1) Add a 2nd Anthropic key as a separate auth profile

This will prompt you to paste the key (it won’t go on your shell command line):

openclaw models auth paste-token --provider anthropic --profile-id anthropic:backup
openclaw models status

You should now see profiles=2 for Anthropic in openclaw models status.

2) Tell OpenClaw to rotate between the two Anthropic profiles (deterministic order)

openclaw models auth order set --provider anthropic anthropic:default anthropic:backup
openclaw models auth order get --provider anthropic

#

(If order set complains about args on your build, paste the error and I’ll adjust—some older CLIs wanted one ID per call.)

3) Set Sonnet as primary (and keep Opus as Anthropic fallback + Groq as non‑Anthropic fallback)

openclaw config set agents.defaults.model.primary "anthropic/claude-sonnet-4-20250514"

openclaw config set agents.defaults.model.fallbacks '[
"anthropic/claude-opus-4-5",
"groq/moonshotai/kimi-k2-instruct-0905"
]' --json

openclaw config set agents.defaults.models '{
"anthropic/claude-sonnet-4-20250514": {},
"anthropic/claude-opus-4-5": {},
"groq/moonshotai/kimi-k2-instruct-0905": {}
}' --json

#


openclaw gateway restart
openclaw models status

4) (Highly recommended) reduce concurrency so you stop slamming into 429

openclaw config set agents.defaults.maxConcurrent 1 --json
openclaw config set agents.defaults.subagents.maxConcurrent 1 --json
openclaw gateway restart

If you want, paste the new openclaw models status output after step 3 and I’ll sanity-check that rotation + primary/fallbacks are exactly what you want.

slate hound Feb 8, 2026, 3:02 AM

#

System: [2026-02-08 00:00:20 GMT-3] WhatsApp gateway connected.

[Sun 2026-02-08 00:01 GMT-3] hey

fluid ibexBOT Feb 8, 2026, 3:03 AM

#

slate hound System: [2026-02-08 00:00:20 GMT-3] WhatsApp gateway connected. ...

That 404 not_found_error is coming from Anthropic, and it usually means: the model ID you selected exists in OpenClaw’s catalog, but your Anthropic account/API key can’t actually use it (Anthropic often returns 404 for “no access / not enabled / not available”).

Also: “configured” just means you allowlisted it in agents.defaults.models — it doesn’t guarantee the provider will serve it.

Quick fix: switch to an Opus ID that’s more likely to work

Try the dated Opus 4.5 you already have in your list:

openclaw models set anthropic/claude-opus-4-5-20251101

Then in the TUI do /new and send hey again.

If that still 404s, your account likely can’t use Opus 4.5/4.6 right now

Confirm by switching to a model you previously did run successfully (Sonnet):

#

openclaw models set anthropic/claude-sonnet-4-20250514

If Sonnet works but Opus 4.5/4.6 404s → it’s an Anthropic account access/model-availability issue, not an OpenClaw config issue.

Does a “second Anthropic key” help?

Only if it’s from a different Anthropic account / different limits.
If it’s just another key under the same account/plan, it often won’t change availability, and may or may not improve rate limits.

If you want, paste just the one error block around the 404 from openclaw logs --follow (no keys), and I’ll tell you whether it’s definitely “model not available” vs something else.

slate hound Feb 8, 2026, 3:06 AM

#

System: [2026-02-08 00:06:11 GMT-3] WhatsApp gateway connected.

[Sun 2026-02-08 00:06 GMT-3] hey

fluid ibexBOT Feb 8, 2026, 3:07 AM

#

slate hound System: [2026-02-08 00:06:11 GMT-3] WhatsApp gateway connected. ...

That 404 is not a “your message is too small/big” problem — it means Anthropic is telling you “this model isn’t available on this API key/account” (Anthropic often returns 404 for “no access / not enabled”, not just “typo”).

Even though OpenClaw lists anthropic/claude-opus-4-5 and you “configured” it, that only means OpenClaw knows the ID and you allowlisted it — it doesn’t guarantee Anthropic will serve it to your key.

Fast way to prove it

Switch to Sonnet (which you already used before) and test:

openclaw models set anthropic/claude-sonnet-4-20250514

If Sonnet works but Opus 4.5/4.6 returns 404 → your Anthropic account/key doesn’t have Opus access right now.

What you can do

Try a different Opus ID from your list (sometimes only some are enabled):

#

openclaw models set anthropic/claude-opus-4-6
# or
openclaw models set anthropic/claude-opus-4-20250514
# or (older)
openclaw models set anthropic/claude-3-opus-20240229

Check/upgrade access on Anthropic’s side (console / billing / model availability). OpenClaw can’t fix that part.

Does a “second Anthropic key” help with this 404?

Only if the second key is from a different Anthropic account/project that actually has Opus enabled.
A second key under the same account usually won’t change model availability (it may help with 429 limits sometimes, but not “model not found”).

If you paste the openclaw logs --follow lines around the 404 (no secrets), I can confirm it’s definitely the Anthropic “model access” case and not a proxy/baseUrl misconfig.

slate hound Feb 8, 2026, 3:09 AM

#

its not finding it, can you just erase everything and do again?

fluid ibexBOT Feb 8, 2026, 3:10 AM

#

slate hound its not finding it, can you just erase everything and do again?

You can “wipe and redo”, but quick warning: an Anthropic 404 for Opus won’t be fixed by resetting OpenClaw — that usually means your Anthropic API key/account doesn’t have access to that Opus model. Resetting just resets your local config/state.

That said, here are the clean reset options:

Option 1: “Reset models only” (keeps WhatsApp linked, keeps keys)

openclaw models fallbacks clear
openclaw models image-fallbacks clear
openclaw config unset agents.defaults.models
openclaw models set anthropic/claude-sonnet-4-20250514
openclaw gateway restart
openclaw models status

Option 2: “Nuke it from orbit” (config + creds + sessions) and re-onboard

This will wipe config + auth profiles + channel creds (WhatsApp link etc.) + sessions.

#

Dry run first (shows what it will delete):

openclaw reset --dry-run

Do the reset:

openclaw reset --scope config+creds+sessions

(or fully non-interactive)

openclaw reset --scope config+creds+sessions --yes --non-interactive

Re-run setup:

#

openclaw onboard

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

Before you do Option 2

Do you want to keep WhatsApp linked, or are you OK relinking it? If you want to keep WhatsApp, do Option 1 first.

If you paste what openclaw models set anthropic/claude-sonnet-4-20250514 does (works vs 404), I can tell you whether you’re dealing with “OpenClaw config mess” or “Anthropic model access” in 10 seconds.

slate hound Feb 8, 2026, 3:11 AM

#

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — 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 : anthropic/claude-opus-4-6
Fallbacks (1) : groq/moonshotai/kimi-k2-instruct-0905
Image model : -
Image fallbacks (0): -
Aliases (1) : opus -> anthropic/claude-opus-4-6
Configured models (4): anthropic/claude-opus-4-5, groq/moonshotai/kimi-k2-instruct-0905, anthropic/claude-opus-4-5-20251101, anthropic/claude-opus-4-6

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

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=1, api_key=1) | anthropic:default=sk-ant-a...8s8okAAA, anthropic:backup=token:sk-ant-a...openclaw | models.json=sk-ant-a...8s8okAAA | source=models.json: ~/.openclaw/agents/main/agent/models.json
groq effective=models.json:gsk_E5Og...mAaaSZnO | models.json=gsk_E5Og...mAaaSZnO | source=models.json: ~/.openclaw/agents/main/agent/models.json
ollama effective=env:ollama-local | env=ollama-local | source=env: OLLAMA_API_KEY | models.json=ollama-local | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

anthropic
- anthropic:backup static
  haluti@Halutis-Mac-mini ~ %

why is not connecting?

fluid ibexBOT Feb 8, 2026, 3:12 AM

#

slate hound 🦞 OpenClaw 2026.2.6-3 (85ed6c7) — One CLI to rule them all, and one more restar...

That openclaw models status output only tells us what’s configured — it doesn’t tell us what “is not connecting”.

When you say “not connecting”, do you mean:

WhatsApp isn’t linked / messages not flowing, or
The TUI is connected but you get no reply, or
Anthropic Opus calls fail (404 / 429 / etc.)?

The fastest way to pinpoint it is:

A) Reproduce once + tail logs

In one terminal:

openclaw logs --follow

Then in the TUI (or WhatsApp) send hey and paste the error block from the logs (10–20 lines around it). That will tell us whether it’s:

Anthropic 404 not_found (model not available to your key),

#

Anthropic 429 rate_limit (cooldown),
Groq TPM/overflow,
delivery/policy issue, etc.

B) If you mean “Opus 4.6 isn’t working”

Anthropic returning 404 for Opus is commonly “your API key/account doesn’t have access to that model”, even if OpenClaw lists it.

Quick proof:

openclaw models set anthropic/claude-sonnet-4-20250514

Then try hey again.

If Sonnet works but Opus 4.6 doesn’t → it’s Anthropic model access, not OpenClaw config.

C) Check channel connectivity (if WhatsApp is the “not connecting”)

#

openclaw channels status --probe
openclaw gateway status

One more thing in your output: you have two Anthropic profiles (api_key=1 and token=1). That’s fine, but the 2nd key only helps if it’s actually a separate usable credential (and ideally a different account/project if you’re trying to escape 404/access issues).

Paste the log snippet from (A) and I’ll tell you exactly which case you’re in.

slate hound Feb 8, 2026, 3:13 AM

#

HTTP 404 not_found_error: Not Found (request_id: req_011CXusREwSyjtkuAkZq1uuN)

#

03:13:27 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=ef6eb0a1-a64e-4e56-87d2-89b43fff9123 sessionId=611642dc-7ddd-42f1-8036-8da3874837f5 durationMs=328 aborted=false
03:13:27 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=331 active=0 queued=0
03:13:27 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=334 active=0 queued=0
03:13:28 info web-heartbeat {"module":"web-heartbeat","runId":"066b710c-ef1f-4346-bf0e-447c0eec74a3"} {"connectionId":"0b931ec3-dcd9-4f61-8071-5850d2ff47b8","reconnectAttempts":0,"messagesHandled":0,"lastMessageAt":null,"authAgeMs":180000.1650390625,"uptimeMs":182295} web gateway heartbeat

fluid ibexBOT Feb 8, 2026, 3:15 AM

#

slate hound HTTP 404 not_found_error: Not Found (request_id: req_011CXusREwSyjtkuAkZq1uuN)

That HTTP 404 not_found_error is coming from Anthropic, and it usually means one of these:

Your Anthropic credential doesn’t have access to that Opus model (Anthropic often returns 404 for “not enabled / no access”, not just typos), or
OpenClaw is trying the other Anthropic profile first (you now have 2 profiles), and that profile can’t use Opus.

Step 1 — force Anthropic to try your API key profile first

Run this on the gateway host:

openclaw models auth order set --provider anthropic anthropic:default anthropic:backup
openclaw models auth order get --provider anthropic
openclaw gateway restart

Then test again.

Step 2 — pin the credential in the TUI (quick test)

#

In openclaw-tui, send this as a standalone message:

/model anthropic/claude-opus-4-5@anthropic:default

Then send hey.

If that works, your issue was “wrong profile being used first”.

Step 3 — if it still 404s, you don’t have Opus access on that account/key

Prove it by switching to Sonnet (which most keys have) and testing:

openclaw models set anthropic/claude-sonnet-4-20250514

#

If Sonnet works but Opus 4.5/4.6 404s → it’s Anthropic model access, not an OpenClaw config problem. You’d need to enable/upgrade access on Anthropic’s side, or use Opus via another provider/account that has it.

(And resetting OpenClaw won’t change that 404.)

#

That log snippet only shows “run completed” — it doesn’t include the actual Anthropic error line. But given you’re seeing HTTP 404 not_found_error in the TUI, treat it as: Anthropic is rejecting the model for the credential being used (most often “no access”, sometimes “wrong credential picked”).

You now have two Anthropic profiles, so do this to isolate it:

1) Test Opus with each Anthropic credential (pins the profile)

In openclaw-tui, send these as standalone messages (one at a time), then send hey after each:

/model anthropic/claude-opus-4-5@anthropic:default

/model anthropic/claude-opus-4-5@anthropic:backup

If one works and the other 404s → it’s a credential issue (wrong key / different account access). Use the working one first (next step).
If both 404 → your Anthropic account(s) don’t have Opus 4.5 access right now (resetting OpenClaw won’t fix that).

#

2) Force the working Anthropic profile to be tried first (global order)

Run:

openclaw models auth order get --provider anthropic
openclaw models auth order set --provider anthropic anthropic:default anthropic:backup
openclaw gateway restart

(If you find backup is the one that works, flip the order.)

3) Sanity check: does Sonnet work on this key?

If Sonnet works but Opus 4.5/4.6 404s, it’s almost certainly Anthropic model access:

openclaw models set anthropic/claude-sonnet-4-20250514

#

If you paste the output of:

openclaw models auth order get --provider anthropic

and tell me which of the two pinned tests 404s/works, I can tell you exactly what to set so it stops “randomly not finding it.”

slate hound Feb 8, 2026, 3:16 AM

#

model set failed: Error: model not allowed: anthropic/claude-opus-4-5@anthropic:default hey
gateway connected | idle
agent main | session main (openclaw-tui) | anthropic/claude-opus-4-6 | think low | tokens 68k/200k (34%)
────────────────────────────────────────────────────────────────────────────────────────────────────────────

fluid ibexBOT Feb 8, 2026, 3:16 AM

#

slate hound model set failed: Error: model not allowed: anthropic/claude-opus-4-5@anthropic:...

That error is happening because the TUI is treating your whole line as the model ref:

it includes @anthropic:default and hey at the end
and /model commands must be sent as a standalone message (no extra words after it)

Do this in the TUI as two separate sends:

Set the model (ONLY this line):

/model anthropic/claude-opus-4-5@anthropic:default

Then send your message:

hey

#

If it still says “model not allowed”, it means your configured model allowlist (agents.defaults.models) doesn’t currently include anthropic/claude-opus-4-5 (the allowlist check happens before it considers the @profile part). Re-add it and restart:

openclaw config set agents.defaults.models."anthropic/claude-opus-4-5" '{}' --json
openclaw gateway restart
openclaw models status

(Then retry the two-step /model ...@anthropic:default + hey test.)

slate hound Feb 8, 2026, 3:18 AM

#

lets erase models and reconnect

#

i ahve the api keys

fluid ibexBOT Feb 8, 2026, 3:18 AM

#

slate hound lets erase models and reconnect

Yep — let’s wipe the model config back to a sane baseline and “reconnect” (re-pick models cleanly). This does not unlink WhatsApp.

1) Reset model selection + fallbacks

Run on the Mac mini:

# pick a known-good default (Sonnet tends to work even when Opus 4.5/4.6 404s)
openclaw models set anthropic/claude-sonnet-4-20250514

# remove all fallbacks (we’ll add them back after it’s stable)
openclaw models fallbacks clear
openclaw models image-fallbacks clear

# remove the configured-model allowlist/catalog (this is what causes “model not allowed” headaches)
openclaw config unset agents.defaults.models

#

openclaw gateway restart
openclaw models status

2) Reset the TUI session (clears any per-session overrides)

In openclaw-tui:

/new

Then send hey.

3) If you still want Opus afterwards

If Sonnet works but Opus returns HTTP 404 not_found_error, that’s Anthropic account/model access, not your config. We can still keep Opus in the allowlist, but Anthropic will keep 404’ing until your key/account has access.

Optional: wipe Ollama from the config too (if you don’t want it involved)

#

openclaw config unset models.providers.ollama
openclaw config unset env.vars.OLLAMA_API_KEY
openclaw gateway restart

If you paste the new openclaw models status after step (1), I’ll tell you exactly what to add back (Groq fallback, Opus, etc.) without reintroducing the “agent failed” loops.

#

Perfect — just don’t paste the keys here in Discord. Use the CLI prompts so they land in your local auth store.

Here’s a clean “erase models + reconnect creds” path (keeps WhatsApp linked):

1) Wipe the messy model config back to baseline

openclaw models fallbacks clear
openclaw models image-fallbacks clear

# remove the model allowlist (this is what caused “model not allowed” headaches)
openclaw config unset agents.defaults.models

# optional: if you want to stop messing with Ollama for now
openclaw config unset models.providers.ollama
openclaw config unset env.vars.OLLAMA_API_KEY

#

openclaw gateway restart

2) Re-add your API keys (stored as auth profiles; prompts you to paste)

openclaw models auth paste-token --provider anthropic --profile-id anthropic:default
openclaw models auth paste-token --provider groq --profile-id groq:default

3) Set a stable default + one fallback (no allowlist needed)

Start with Sonnet (more likely to work than Opus if your Anthropic account is picky):

openclaw models set anthropic/claude-sonnet-4-20250514
openclaw models fallbacks add groq/moonshotai/kimi-k2-instruct-0905
openclaw gateway restart

#

openclaw models status

4) Stop the 429 spiral (high impact)

openclaw config set agents.defaults.maxConcurrent 1 --json
openclaw config set agents.defaults.subagents.maxConcurrent 1 --json
openclaw gateway restart

5) Test in TUI

In openclaw-tui:

/new
hey

#

If you still want Opus as primary

After Sonnet is confirmed working:

openclaw models set anthropic/claude-opus-4-5

If Opus still returns HTTP 404 not_found_error, that’s almost always Anthropic account/model access (resetting OpenClaw won’t change it).

If you paste the next openclaw models status after step 3 (no secrets), I’ll sanity-check that it’s in a good state.

slate hound Feb 8, 2026, 3:19 AM

#

i want opus 4.5

fluid ibexBOT Feb 8, 2026, 3:20 AM

#

slate hound i want opus 4.5

Set it like this (and keep a non‑Anthropic fallback so you don’t get “agent failed” when Anthropic 429s):

# (optional but recommended) remove the configured-model allowlist so /model doesn’t fight you
openclaw config unset agents.defaults.models

# clear old fallbacks so we’re not chasing ghosts
openclaw models fallbacks clear
openclaw models image-fallbacks clear

# set Opus 4.5 as the primary
openclaw models set anthropic/claude-opus-4-5

# add a fallback that’s not Anthropic (so 429/cooldown doesn’t kill you)
openclaw models fallbacks add groq/moonshotai/kimi-k2-instruct-0905

#

# reduce concurrency to avoid Anthropic cooldown spirals
openclaw config set agents.defaults.maxConcurrent 1 --json
openclaw config set agents.defaults.subagents.maxConcurrent 1 --json

openclaw gateway restart
openclaw models status

Then in openclaw-tui:

/new
hey

If you still get HTTP 404 not_found_error on Opus 4.5 after that, that’s not an OpenClaw config issue — it means your Anthropic API key/account doesn’t have access to Opus 4.5 (Anthropic commonly returns 404 for “not enabled”). In that case, Sonnet will usually work on the same key, but Opus won’t until Anthropic enables it for your account.

slate hound Feb 8, 2026, 3:21 AM

#

fluid ibex ```bash openclaw models status ``` ## 4) Stop the 429 spiral (high impact) ```b...

test didnt work

fluid ibexBOT Feb 8, 2026, 3:22 AM

#

slate hound test didnt work

What exactly was the failure message this time?

“test didn’t work” can mean totally different things (404 model access vs 429 cooldown vs Groq TPM vs “model not allowed”). Please paste the one-line error you see in the TUI right after sending hey (it usually starts with HTTP ...).

Then also paste the matching log block:

In a terminal:

openclaw logs --follow

In openclaw-tui:

/new
hey

#

Copy/paste the ~10–20 log lines around the error.

While we wait: if your error is again HTTP 404 not_found_error on anthropic/claude-opus-4-5, that’s almost always Anthropic account/key model access (Anthropic returns 404 for “not enabled”). OpenClaw being “configured” doesn’t guarantee your key can use that model.

Fast proof test:

openclaw models set anthropic/claude-sonnet-4-20250514
openclaw gateway restart

Then /new + hey in the TUI.

If Sonnet works but Opus 4.5 404s → Opus 4.5 isn’t available for your Anthropic key/account right now, and no amount of OpenClaw reset will fix it.
If Sonnet also fails, then we’re dealing with a different connectivity/auth issue — the logs will show which.

slate hound Feb 8, 2026, 3:22 AM

#

same 404 error

fluid ibexBOT Feb 8, 2026, 3:23 AM

#

slate hound same 404 error

If it’s still the same Anthropic HTTP 404 not_found_error on anthropic/claude-opus-4-5, that’s not an OpenClaw “config got messy” problem anymore.

A 404 from Anthropic for a model ID that OpenClaw knows almost always means:

your Anthropic credential/account does not have access to that model, or
you’re hitting Anthropic with the other Anthropic profile (you have 2 now) and that profile doesn’t have access.

1) Force OpenClaw to try your API-key profile first (then test again)

openclaw models auth order set --provider anthropic anthropic:default anthropic:backup
openclaw models auth order get --provider anthropic
openclaw gateway restart

Then in the TUI:

#

/new
hey

2) Prove it’s “Opus access” by switching to Sonnet

openclaw models set anthropic/claude-sonnet-4-20250514
openclaw gateway restart

Then /new + hey.

If Sonnet works but Opus 4.5/4.6 404s → your Anthropic key/account simply doesn’t have Opus 4.5 enabled right now. OpenClaw can’t fix that; you’d need to enable/upgrade access on Anthropic’s side or use Opus via a different provider/account that has access.

3) Why “configured” doesn’t help

“Configured models” / allowlists only control what OpenClaw is allowed to try. Anthropic still decides what your key can actually use.

#

If you want, paste the single Anthropic error line from openclaw logs --follow around the 404 (no secrets) and I’ll confirm whether it’s definitely “model access” vs “wrong profile used”.

slate hound Feb 8, 2026, 3:23 AM

#

03:23:20 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:main queueSize=1
03:23:20 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:main waitMs=1 queueSize=0
03:23:20 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
03:23:20 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=1 queueSize=0
03:23:20 debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=67c5c54b-d775-476d-b9f6-5ae1047263a5 sessionId=611642dc-7ddd-42f1-8036-8da3874837f5 provider=anthropic model=claude-sonnet-4-20250514 thinking=low messageChannel=webchat
03:23:20 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=611642dc-7ddd-42f1-8036-8da3874837f5 sessionKey=unknown prev=idle new=processing reason="run_started" queueDepth=d-b9f6-5ae1047263a5
03:23:20 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=67c5c54b-d775-476d-b9f6-5ae1047263a5
03:23:20 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=67c5c54b-d775-476d-b9f6-5ae1047263a5 sessionId=611642dc-7ddd-42f1-8036-8da3874837f5 durationMs=266
03:23:20 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=611642dc-7ddd-42f1-8036-8da3874837f5 sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
03:23:20 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=611642dc-7ddd-42f1-8036-8da3874837f5 totalActive=0
03:23:20 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=67c5c54b-d775-476d-b9f6-5ae1047263a5 sessionId=611642dc-7ddd-42f1-8036-8da3874837f5 durationMs=342 aborted=false
03:23:20 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=344 active=0 queued=0
03:23:20 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=347 active=0 queued=0

fluid ibexBOT Feb 8, 2026, 3:26 AM

#

slate hound 03:23:20 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:...

The snippet you pasted there shows a successful run against Anthropic Sonnet:

provider=anthropic model=claude-sonnet-4-20250514
no error lines after it
run completes in ~300ms

So OpenClaw is “connecting” to Anthropic fine.

Your HTTP 404 not_found_error only happens when you select Opus 4.5/4.6. In Anthropic-land, that almost always means your API key/account does not have access to that model (Anthropic often uses 404 for “not available to this key”, not just typos). Resetting OpenClaw won’t change that.

Two things to do to confirm 100%:

1) Probe each Anthropic credential profile (default vs backup)

This will run tiny live requests (may consume tokens):

#

openclaw models status --probe --probe-provider anthropic --probe-profile anthropic:default --probe-max-tokens 16
openclaw models status --probe --probe-provider anthropic --probe-profile anthropic:backup --probe-max-tokens 16

If Opus 4.5 is going to work on either credential, this will usually surface it quickly.

2) Prove “Sonnet works but Opus doesn’t”

openclaw models set anthropic/claude-sonnet-4-20250514
# test: /new + hey in the TUI (should work)

openclaw models set anthropic/claude-opus-4-5
# test again (you’ll see the same 404 if you lack access)

If you must use Opus 4.5, you need an Anthropic credential (often a different project/account) that has Opus enabled, or enable/upgrade access on Anthropic’s side. A “second key” only helps if it’s from an account/project that actually has Opus 4.5 access.

slate hound Feb 8, 2026, 3:26 AM

#

i think the problem is in the raw file that is old
},
"models": {
"mode": "merge",
"providers": {
"groq": {
"baseUrl": "https://api.groq.com/openai/v1",
"apiKey": "OPENCLAW_REDACTED",
"api": "openai-completions",
"models": [
{
"id": "llama-3.3-70b-versatile",
"name": "Llama 3.3 70B (Groq)",
"reasoning": false,
"input": [
"text",
"image"
],
"cost": {
"input": 0.59,
"output": 0.79,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 128000,
"maxTokens": "OPENCLAW_REDACTED"
}
]
},
"ollama": {
"baseUrl": "http://127.0.0.1:11434/v1",
"apiKey": "OPENCLAW_REDACTED",
"api": "openai-completions",
"models": [
{
"id": "llama3.1:8b",
"name": "Llama 3.1 8B (Ollama)",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 8192,
"maxTokens": "OPENCLAW_REDACTED"
}
]
}
}
},
"agents": {
"defaults": {
"model": {
"primary": "anthropic/claude-sonnet-4-20250514",
"fallbacks": [
"ollama/llama3.1:8b",
"groq/llama-3.3-70b-versatile",
"anthropic/claude-opus-4-0520"
]
},
"models": {
"anthropic/claude-sonnet-4-20250514": {},
"groq/llama-3.3-70b-versatile": {},
"anthropic/claude-opus-4-0520": {},
"ollama/llama3.1:8b": {}
},
"workspace": "/Users/haluti/.openclaw/workspace",
"userTimezone": "America/Sao_Paulo",
"

fluid ibexBOT Feb 8, 2026, 3:27 AM

#

slate hound i think the problem is in the raw file that is old }, "models": { "mode": ...

Yep — that snippet does contain stale/bad model config, and it will absolutely cause the kind of “agent failed / unknown model / model not allowed” chaos you’ve been seeing.

What’s wrong in that raw file

This model ID is invalid/stale:

anthropic/claude-opus-4-0520
That’s the one that triggers “Unknown model …” type failures.

Your fallback list includes Ollama 8k (ollama/llama3.1:8b) which often can’t even fit OpenClaw’s base prompt/tooling, so it’s a weak fallback.
You’re also manually defining Groq/Ollama under models.providers.*. That’s OK, but it’s easy to get wrong and it can fight with “built-in provider catalog” expectations.

Quick “clean + modern” fix (CLI, no manual file editing)

This replaces the stale fallbacks + allowlist with a minimal sane set (Sonnet primary + one big-context Groq fallback):

openclaw config set agents.defaults.model.primary "anthropic/claude-sonnet-4-20250514"

#


openclaw config set agents.defaults.model.fallbacks '[
"groq/moonshotai/kimi-k2-instruct-0905"
]' --json

openclaw config set agents.defaults.models '{
"anthropic/claude-sonnet-4-20250514": {},
"groq/moonshotai/kimi-k2-instruct-0905": {}
}' --json

openclaw gateway restart
openclaw models status

That removes the stale anthropic/claude-opus-4-0520 from both places by overwriting the whole arrays/objects.

#

If you want to completely stop the old custom Groq/Ollama provider blocks from affecting anything

(Only do this if you’re OK not using those local/custom providers for now.)

openclaw config unset models.providers.groq
openclaw config unset models.providers.ollama
openclaw gateway restart

Important: this will NOT fix the Anthropic “Opus 4.5 = HTTP 404”

That 404 is Anthropic saying your key/account can’t use Opus 4.5/4.6 (it’s not a “raw file old” thing). Cleaning config will fix “unknown model / model not allowed”, but not provider-side access.

If you paste your current openclaw config get agents.defaults.model after the reset above, I’ll sanity-check it’s clean.

slate hound Feb 8, 2026, 3:27 AM

#

so, how to fix it??

fluid ibexBOT Feb 8, 2026, 3:28 AM

#

slate hound so, how to fix it??

There are two separate problems mixed together:

Your config has stale/invalid model IDs (like anthropic/claude-opus-4-0520) → causes “unknown model / model not allowed / weird failover”.
Anthropic returning HTTP 404 not_found_error for Opus 4.5/4.6 → that’s almost always Anthropic account/key access (not something OpenClaw can “fix” locally).

A) Fix the config mess (removes stale Opus ID + makes fallback sane)

Run this on the Mac mini:

# wipe old fallbacks + allowlist (this removes the stale IDs cleanly)
openclaw models fallbacks clear
openclaw models image-fallbacks clear
openclaw config unset agents.defaults.models

# set a known-working primary + a non-Anthropic fallback
openclaw config set agents.defaults.model.primary "anthropic/claude-sonnet-4-20250514"

#

openclaw config set agents.defaults.model.fallbacks '[
"groq/moonshotai/kimi-k2-instruct-0905"
]' --json

# reduce concurrency so you stop slamming into 429/cooldowns
openclaw config set agents.defaults.maxConcurrent 1 --json
openclaw config set agents.defaults.subagents.maxConcurrent 1 --json

openclaw gateway restart
openclaw models status

Now test in TUI:

/new

#

hey

B) About Opus 4.5: the 404 is not a config issue

After (A), try:

openclaw models set anthropic/claude-opus-4-5

If you still get HTTP 404, that means your Anthropic key/account can’t use Opus 4.5 right now. Resetting OpenClaw won’t change it.

Only fixes for that are:

use an Anthropic key/project/account that does have Opus enabled, or
use a different provider route that offers Opus to you, or
stick with Sonnet (which your logs show is working).

If you want, paste the exact HTTP 404 ... request_id=... line again after you run step (A) and I’ll confirm you’re in the “Anthropic access” case (not local config).

slate hound Feb 8, 2026, 3:30 AM

#

fluid ibex ```text hey ``` ### B) About Opus 4.5: the 404 is **not** a config issue After ...

didnt work first test

fluid ibexBOT Feb 8, 2026, 3:31 AM

#

slate hound didnt work first test

Need the exact failure text to tell what’s still wrong. Please paste the single line/error the TUI shows right after you send hey (e.g. HTTP 404 ... / All models failed ... / model not allowed ...).

While you grab that, do this “known-good baseline” test to isolate whether it’s still just Opus access vs config/routing:

1) Force a working default (Sonnet) and remove the allowlist

openclaw models set anthropic/claude-sonnet-4-20250514
openclaw config unset agents.defaults.models
openclaw models fallbacks clear
openclaw gateway restart
openclaw models status

2) Test from TUI

In openclaw-tui:

#

/new
hey

3) If it still fails, paste logs around it

Run:

openclaw logs --follow

Send hey once more in the TUI and paste the 10–20 lines around the error.

If Sonnet works in this baseline, then your earlier Opus 4.5/4.6 HTTP 404 not_found_error is confirmed as Anthropic model access (OpenClaw can’t fix that locally). If Sonnet doesn’t work either, the log block will immediately show whether it’s auth, cooldown, or something else.

slate hound Feb 8, 2026, 3:32 AM

#

404 fail

fluid ibexBOT Feb 8, 2026, 3:33 AM

#

slate hound 404 fail

A plain “404 fail” almost always means Anthropic is responding, but rejecting what you asked for (usually the model). So the connection is fine — it’s either:

you’re still actually calling Opus 4.5/4.6 (which your key/account doesn’t have access to), or
you’re hitting Anthropic with the “wrong” credential/profile.

1) Confirm what model the TUI is actually using

In openclaw-tui, send this as a standalone message:

/model status

Then paste the line that shows the active model + profile.

2) Force Sonnet once (to prove the key works)

Run:

#

openclaw models set anthropic/claude-sonnet-4-20250514
openclaw gateway restart

Then in the TUI (standalone messages):

/new
/model anthropic/claude-sonnet-4-20250514
hey

If Sonnet works but Opus 4.5 still 404s → there is no OpenClaw-side fix for Opus; your Anthropic API key/account simply doesn’t have Opus 4.5 enabled (Anthropic often returns 404 for “no access”).
If Sonnet also 404s, paste the exact error line (the full HTTP 404 ... request_id=...) plus 10 lines around it from:

openclaw logs --follow

#

3) If you want to ensure the API-key profile is used first (you have 2 profiles)

openclaw models auth order set --provider anthropic anthropic:default anthropic:backup
openclaw gateway restart

Paste /model status output and the full 404 line and I’ll tell you exactly which profile/model combo is causing it.

slate hound Feb 8, 2026, 3:33 AM

#

mory)
03:31:58 info web-heartbeat {"module":"web-heartbeat","runId":"cc9a62fa-032e-4f1b-927b-fa87974ff576"} {"connectionId":"3f26b672-bdb7-4e82-846d-b99a3cdb6a3e","reconnectAttempts":0,"messagesHandled":0,"lastMessageAt":null,"authAgeMs":120001.24658203125,"uptimeMs":121117} web gateway heartbeat
03:32:58 info web-heartbeat {"module":"web-heartbeat","runId":"cc9a62fa-032e-4f1b-927b-fa87974ff576"} {"connectionId":"3f26b672-bdb7-4e82-846d-b99a3cdb6a3e","reconnectAttempts":0,"messagesHandled":0,"lastMessageAt":null,"authAgeMs":180001.24658203125,"uptimeMs":181117} web gateway heartbeat
03:33:02 debug plugins {"subsystem":"plugins"} plugin CLI register skipped (memory-core): command already registered (memory)
Log tail truncated (increase --max-bytes).

fluid ibexBOT Feb 8, 2026, 3:34 AM

#

slate hound mory) 03:31:58 info web-heartbeat {"module":"web-heartbeat","runId":"cc9a62fa-03...

Those lines are just the web-heartbeat + “log tail truncated” — they don’t include the 404 error, so we can’t see which model/profile Anthropic is 404’ing.

Do this to capture the real 404:

1) Grab the latest log file and grep for the 404

LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
echo "$LOG"
grep -nE "not_found_error|HTTP 404|request_id" "$LOG" | tail -n 50

2) Also capture the model/profile being used right before the failure

In the same log, look a few lines above the 404 for something like:
provider=anthropic model=... (that’s the key line).

#

What the 404 almost certainly means (based on what you’ve shown so far)

If the 404 is on anthropic/claude-opus-4-5 or anthropic/claude-opus-4-6, that’s usually Anthropic “model not available for this API key/account” (they often return 404 for “no access”, not just typos). OpenClaw being “configured” doesn’t change that.

Fast proof:

openclaw models set anthropic/claude-sonnet-4-20250514
openclaw gateway restart

Then /new + hey in the TUI.

If Sonnet works and Opus 4.5/4.6 404s → it’s Anthropic access, not your local config.

Paste the grep output (it won’t include secrets), and I’ll tell you exactly which model/profile is producing the 404 and what to set.

slate hound Feb 8, 2026, 3:34 AM

#

Log tail truncated (increase --max-bytes).
haluti@Halutis-Mac-mini ~ % LOG="$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
echo "$LOG"
grep -nE "not_found_error|HTTP 404|request_id" "$LOG" | tail -n 50
/tmp/openclaw/openclaw-2026-02-08.log
haluti@Halutis-Mac-mini ~ %

but in tui appears 404

fluid ibexBOT Feb 8, 2026, 3:37 AM

#

slate hound Log tail truncated (increase --max-bytes). haluti@Halutis-Mac-mini ~ % LOG="$(ls...

If the TUI shows a 404, but your log file has zero HTTP 404 lines, what’s happening is almost certainly:

the 404 is coming from a different session/model than the one you’re grepping for, and/or
you’re looking at the TUI error from a run where the model was Opus, while your log snippet you pasted earlier shows a successful run on Sonnet.

Your debug line proves Sonnet is fine:

provider=anthropic model=claude-sonnet-4-20250514 … durationMs=266 (no error)

So the “fix” is not in an “old raw file”. The 404 is coming from Anthropic rejecting the Opus model for your credential (that’s exactly what Anthropic does when your key doesn’t have access — they often return 404).

Do this to make it unambiguous

In the TUI, run (standalone message):

/model status

Paste the active model + profile it reports.

#

Force Sonnet in the TUI and confirm it replies (this proves your gateway+key are OK):

/model anthropic/claude-sonnet-4-20250514
hey

Now force Opus 4.5 and see the 404 again:

/model anthropic/claude-opus-4-5
hey

If step (2) works and step (3) 404s → there is no OpenClaw-side config fix for Opus 4.5. You need either:

an Anthropic API key/project/account that has Opus 4.5 enabled, or
to use a different provider route that offers Opus to you.

One more gotcha: you have 2 Anthropic profiles

#

To make sure OpenClaw tries your API key first (not the backup token), run:

openclaw models auth order set --provider anthropic anthropic:default anthropic:backup
openclaw gateway restart

If you paste the output of /model status from the TUI, I’ll tell you exactly which model+profile is producing the 404.

slate hound Feb 8, 2026, 3:38 AM

#

03:29:57 info Shell env : off
03:29:57 info Providers w/ OAuth/tokens (2): anthropic (2), groq (1)
03:29:57 info - anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=2, api_key=0) | anthropic:default=token:sk-ant-a...7EvajwAA, anthropic:backup=token:sk-ant-a...openclaw | models.json=sk-ant-a...8s8okAAA | source=models.json: ~/.openclaw/agents/main/agent/models.json
03:29:57 info - groq effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | groq:default=token:gsk_E5Og...mAaaSZnO | models.json=gsk_E5Og...mAaaSZnO | source=models.json: ~/.openclaw/agents/main/agent/models.json
03:29:57 info {"0":"","_meta":{"runtime":"node","runtimeVersion":"25.6.0","hostname":"unknown","name":"openclaw","date":"2026-02-08T03:29:57.065Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///Users/haluti/.nvm/versions/node/v25.6.0/lib/node_modules/openclaw/dist/entry.js:915:46","fileName":"entry.js","fileNameWithLine":"entry.js:915","fileColumn":"46","fileLine":"915","filePath":".nvm/versions/node/v25.6.0/lib/node_modules/openclaw/dist/entry.js","filePathWithLine":".nvm/versions/node/v25.6.0/lib/node_modules/openclaw/dist/entry.js:915","method":"console.log"}},"time":"2026-02-08T03:29:57.065Z"}
03:29:57 info OAuth/token status
03:29:57 info gateway/canvas {"subsystem":"gateway/canvas"} canvas host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /Users/haluti/.openclaw/canvas)
03:29:57 info gateway/heartbeat {"subsystem":"gateway/heartbeat"} {"intervalMs":3600000} heartbeat: started
03:29:57 info gateway {"subsystem":"gateway"} agent model: anthropic/claude-sonnet-4-20250514
03:29:57 info gateway {"subsystem":"gateway"} listening on ws://127.0.0.1:18789 (PID 22405)
03:29:57 info gateway {"subsystem":"gateway"} listening on ws://[::1]:18789
03:29:57 info gateway {"subsystem":"gateway"} log file: /tmp/openclaw/openclaw-2026-02-
\

fluid ibexBOT Feb 8, 2026, 3:39 AM

#

slate hound 03:29:57 info Shell env : off 03:29:57 info Providers w/ OAuth/tokens (2): a...

That log confirms what’s going on:

OpenClaw is running Anthropic Sonnet fine (agent model: anthropic/claude-sonnet-4-20250514).
Your Anthropic credentials are currently both stored as “token” profiles (token=2, api_key=0).

And the HTTP 404 not_found_error you keep seeing when you switch to Opus 4.5/4.6 is almost certainly Anthropic saying “this key doesn’t have access to that model” (Anthropic often returns 404 for “not enabled for this account/project”, not just typos). That’s why Sonnet works but Opus doesn’t.

Fix (the only fix that can make Opus 4.5 work)

You need to make sure you’re using a real Anthropic API key from the Anthropic Console (not a Claude subscription setup-token), and that the Anthropic account/project behind that key has Opus 4.5 enabled.

1) Re-add your Anthropic key as an API key via the wizard (this avoids the token/api_key confusion)

Run:

openclaw configure --section model

Choose Anthropic API key (not setup-token), paste the key, then restart when prompted.

#

Then verify:

openclaw models status

You want to see Anthropic with api_key=1 (not token=... only).

2) Try Opus 4.5 again

openclaw models set anthropic/claude-opus-4-5
openclaw gateway restart

If it still 404s after that, it’s 100% on the Anthropic side: your account/key doesn’t have Opus 4.5 access.

About “adding a second Anthropic key”

A second key only helps if it’s from an account/project that does have Opus 4.5 access (and possibly higher limits). If it’s just another key under the same account, it usually won’t change 404 model access.

If you want, tell me: is your “second key” from a different Anthropic org/project (with different billing), or just another key in the same console?

slate hound Feb 8, 2026, 3:42 AM

#

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — The UNIX philosophy meets your DMs.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : anthropic/claude-sonnet-4-20250514
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): anthropic/claude-sonnet-4-20250514

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

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=1, api_key=1) | anthropic:default=sk-ant-a...7EvajwAA, anthropic:backup=token:sk-ant-a...openclaw | models.json=sk-ant-a...8s8okAAA | source=models.json: ~/.openclaw/agents/main/agent/models.json
groq effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | groq:default=token:gsk_E5Og...mAaaSZnO | models.json=gsk_E5Og...mAaaSZnO | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

anthropic
- anthropic:backup static
groq
- groq:default static
  haluti@Halutis-Mac-mini ~ % openclaw models status

i think its with tokens

fluid ibexBOT Feb 8, 2026, 3:42 AM

#

slate hound 🦞 OpenClaw 2026.2.6-3 (85ed6c7) — The UNIX philosophy meets your DMs. Config ...

Yeah — the “token” vs “api_key” mix is very likely the issue.

Right now you have two Anthropic creds:

anthropic:default = api_key (sk-ant-...)
anthropic:backup = token (token:sk-ant-...) ← this is usually a setup-token/subscription-style token, and it can behave differently (including model availability). If OpenClaw ever tries this one for Opus, Anthropic can respond with 404.

1) Force OpenClaw to use the API key first (and only)

Run on the Mac mini:

openclaw models auth order set --provider anthropic anthropic:default
openclaw models auth order get --provider anthropic
openclaw gateway restart

Now test Opus again pinned to the API-key profile (in the TUI, as a standalone message, no extra text):

#

/model anthropic/claude-opus-4-5@anthropic:default

Then send:

hey

2) You currently have an allowlist with only Sonnet

Configured models (1): anthropic/claude-sonnet-4-20250514 means Opus/Groq won’t be selectable unless you add them (or remove the allowlist).

To allow Opus 4.5:

openclaw config set agents.defaults.models."anthropic/claude-opus-4-5" '{}' --json
openclaw gateway restart

#

3) If Opus 4.5 still 404s even when pinned to `anthropic:default`

Then it’s not OpenClaw anymore — it means your Anthropic API key/account doesn’t have access to Opus 4.5 (Anthropic often returns 404 for “not enabled for this key”).

If you want, paste the full TUI 404 line including the request_id after doing step (1) + the pinned /model …@anthropic:default, and I’ll confirm which credential/model combination is being used.

slate hound Feb 8, 2026, 3:43 AM

#

cant we delete the tokens? reinstall it?

fluid ibexBOT Feb 8, 2026, 3:44 AM

#

slate hound cant we delete the tokens? reinstall it?

You don’t need to reinstall. And you can “delete the token profiles”, but the simplest fix is: just stop OpenClaw from using them.

Option A (recommended): ignore the token profile (use API key only)

This keeps everything else (WhatsApp link, sessions) intact:

openclaw models auth order set --provider anthropic anthropic:default
openclaw models auth order get --provider anthropic
openclaw gateway restart
openclaw models status

Now Anthropic calls will only use anthropic:default (your API key profile).

Option B: actually delete the token profile

There isn’t a nice one-command “delete profile” in the docs. The clean way is a creds reset (BUT it will wipe credentials, including WhatsApp link, and you’ll have to paste keys again):

#

See what it would delete:

openclaw reset --dry-run

If it supports it on your build, wipe creds:

openclaw reset --scope creds --yes --non-interactive

Then re-add only your API keys with:

openclaw models auth paste-token --provider anthropic --profile-id anthropic:default
openclaw models auth paste-token --provider groq --profile-id groq:default

If --scope creds errors, run openclaw reset --help and paste the output; scopes vary by version.

#

Important: token vs api_key won’t fix Opus 4.5 404 if your account lacks access

If Opus 4.5 still returns HTTP 404 even when pinned to @anthropic:default, that means your Anthropic API key/account can’t use Opus 4.5/4.6 right now (Anthropic returns 404 for “not enabled”). No reinstall will change that.

If you want, after Option A run this test:

openclaw models set anthropic/claude-sonnet-4-20250514 # should work
openclaw models set anthropic/claude-opus-4-5 # if this 404s → account access issue

slate hound Feb 8, 2026, 3:44 AM

#

but groq shows apikey =0

fluid ibexBOT Feb 8, 2026, 3:45 AM

#

slate hound but groq shows apikey =0

That api_key=0 does not mean “Groq isn’t configured”.

It just means OpenClaw has your Groq credential stored as a token-type profile in auth-profiles.json (same file used for API keys + other token types). For Groq, that still works — what matters is that Groq shows up as effective and your model list shows Auth yes (which it did in your openclaw models list --all --provider groq output).

Quick way to prove Groq auth is actually working

This runs a tiny live probe (costs a little + can rate limit if spammed):

openclaw models status --probe --probe-provider groq --probe-max-tokens 16

If your goal is “make Groq actually be used as fallback”

Right now your Configured models (1) only includes Sonnet, so Groq won’t be eligible unless you either remove the allowlist or add Groq to it, and add it to fallbacks:

openclaw config set agents.defaults.model.fallbacks '[
"groq/moonshotai/kimi-k2-instruct-0905"

#

]' --json

openclaw config set agents.defaults.models."groq/moonshotai/kimi-k2-instruct-0905" '{}' --json

openclaw gateway restart
openclaw models status

If you really want Groq to show as api_key=1

You can re-add it via the prompt-based flow (don’t paste the key into Discord):

openclaw models auth paste-token --provider groq --profile-id groq:default
openclaw gateway restart
openclaw models status

#

(But again: “token vs api_key” in the status output is mostly bookkeeping; it doesn’t block usage.)

slate hound Feb 8, 2026, 3:45 AM

#

can I change that in the UI? or even in the json file?

fluid ibexBOT Feb 8, 2026, 3:46 AM

#

slate hound can I change that in the UI? or even in the json file?

Yes, but be careful:

Best option: use the UI / wizard (safe)

Run the wizard and re-enter creds the supported way:

openclaw configure --section model

That’s the least error‑prone and it writes things in the right places.

You can edit JSON files, but it’s easy to shoot yourself in the foot

There are two different files involved:

Config (model selection / allowlist / fallbacks)
~/.openclaw/openclaw.json
This is safe to edit (JSON5). Use CLI helpers instead of hand-editing:

openclaw config set …
openclaw config unset …

#

Secrets / auth profiles (API keys + tokens)
~/.openclaw/agents/main/agent/auth-profiles.json
This contains your credentials. Editing by hand can break parsing or leak keys.

If you really want to “convert” a Groq or Anthropic profile to api_key type, don’t hand-edit the file — just re-add the credential with the proper command, which writes the right type:

openclaw models auth paste-token --provider groq --profile-id groq:default
openclaw models auth paste-token --provider anthropic --profile-id anthropic:default

(Despite the name “paste-token”, it’s used for API keys too; it will store them correctly.)

UI for creds?

In the Control UI, there isn’t always a full “credential manager” for every provider/profile yet; the wizard (openclaw configure) is the reliable UI path right now.

If you tell me which thing you want to change specifically:

#

“make Groq api_key=1”
“delete anthropic token profile”
“set fallbacks / allowlist”
…I’ll give you the exact safest method and commands.

slate hound Feb 8, 2026, 3:47 AM

#

i want this to work

fluid ibexBOT Feb 8, 2026, 3:48 AM

#

slate hound i want this to work

Let’s get you to a known-good, boring, stable setup first. Right now the biggest blocker is: Anthropic Opus 4.5/4.6 returning HTTP 404 (that’s almost always provider-side access, not your config). So the “make it work” path is: Sonnet primary + Groq fallback, low concurrency.

Run these on the Mac mini (don’t paste keys in Discord):

1) Force Anthropic to use only your API key profile (ignore the token profile)

openclaw models auth order set --provider anthropic anthropic:default
openclaw models auth order get --provider anthropic

2) Remove the model allowlist (stops “model not allowed” + stale IDs headaches)

openclaw config unset agents.defaults.models

3) Set a working primary + working fallback

#

openclaw models set anthropic/claude-sonnet-4-20250514
openclaw models fallbacks clear
openclaw models fallbacks add groq/moonshotai/kimi-k2-instruct-0905

4) Stop the 429 spiral (this matters a lot)

openclaw config set agents.defaults.maxConcurrent 1 --json
openclaw config set agents.defaults.subagents.maxConcurrent 1 --json

5) Restart + verify

openclaw gateway restart
openclaw models status

#

6) Test

In openclaw-tui:

/new
hey

About Opus 4.5

After the above works, you can try:

openclaw models set anthropic/claude-opus-4-5

If you still get HTTP 404 not_found_error, that’s Anthropic telling you your account/key can’t use Opus 4.5 right now. No amount of reinstalling OpenClaw will change that—only getting Opus enabled on the Anthropic side (or using a different Anthropic account/key that has access) will.

If you run the steps above and it still fails, paste your updated openclaw models status + the exact TUI error line (the full HTTP ... request_id=...).

chrome smelt Feb 8, 2026, 3:49 AM

#

Thanks for the tips! I have a related question about fallbacks with rate limits.

My setup:

Config: primary: opus-4-5, fallbacks: [sonnet-4-5, gemini-3-pro]
Auth: API key via anthropic:default

Issue: When hitting Anthropic rate limits (95% usage), I get 429 errors instead of auto-fallback to Sonnet or Gemini.

Question: Do fallbacks trigger on rate limit (429) errors, or only on model availability errors?

The fallback list includes both same-provider (Sonnet) and different-provider (Gemini), but neither kicks in when rate limited.

Workaround: Temporarily switched to Sonnet as primary via session model override with /model command.

Is there a config option to enable rate-limit fallback? Or do I need to manually switch models when hitting limits?

slate hound Feb 8, 2026, 3:49 AM

#

fluid ibex ## 6) Test In `openclaw-tui`: ```text /new hey ``` ### About Opus 4.5 After the...

is not working here, before

fluid ibexBOT Feb 8, 2026, 3:50 AM

#

chrome smelt Thanks for the tips! I have a related question about fallbacks with rate limits....

Fallbacks are supposed to trigger on 429 / rate_limit_error, but with two important caveats:

Failover happens in two layers

First: auth profile rotation + cooldowns within the same provider (Anthropic).
Then: model fallback to agents.defaults.model.fallbacks after the provider’s available profiles are exhausted / cooled down.
Docs: https://docs.openclaw.ai/concepts/model-failover

So you should see it try:
opus → sonnet (still Anthropic) → gemini when Anthropic is rate-limited.

Same-provider fallback won’t help for provider-wide 429
If Anthropic is rate-limiting your whole account/project, switching from Opus→Sonnet still hits Anthropic and will likely 429 as well. In that case you want the first non‑Anthropic fallback earlier in the list, e.g.:

agents: {
defaults: {

#

model: {
primary: "anthropic/claude-opus-4-5",
fallbacks: ["google/gemini-3-pro", "anthropic/claude-sonnet-4-5"]
}
}
}

If you’re getting a raw 429 and it never even attempts Gemini

99% of the time it’s one of these:

Gemini isn’t actually usable (missing key/auth), so it can’t fall back. Check:

openclaw models status

(It should show Google/Gemini auth as present.)

#

You have an allowlist/catalog (agents.defaults.models) that doesn’t include Gemini/Sonnet, so fallback is blocked before it runs. Ensure both are included or remove the allowlist.
The logs will literally say what it tried. Grab the “All models failed …” line:

openclaw logs --follow

and paste the single line that starts with Embedded agent failed before reply: All models failed ...

There isn’t a separate “enable rate-limit fallback” switch—fallback-on-429 is the intended behavior. If your logs show it’s not trying the next model at all on 429, that’s likely a bug/regression, and that one log line + your openclaw --version is enough to file a GitHub issue.

fluid ibexBOT Feb 8, 2026, 3:51 AM

#

slate hound is not working here, before

Need the exact error text — “not working” can still be 404 (Opus access) vs 429 cooldown vs model not allowed vs delivery off.

Please paste one line: whatever the TUI shows right after hey (e.g. HTTP 404 ... request_id=...).

In the meantime, do this “prove the basics work” sequence (it forces Sonnet + API key only, no token profile, no allowlist surprises):

# force Anthropic to use ONLY your real API key profile
openclaw models auth order set --provider anthropic anthropic:default

# remove allowlist (prevents “model not allowed”)
openclaw config unset agents.defaults.models

# set a known-working model
openclaw models set anthropic/claude-sonnet-4-20250514

#

openclaw gateway restart
openclaw models status

Then in openclaw-tui (each as standalone messages):

/new
/model anthropic/claude-sonnet-4-20250514
hey

If you still see a 404 after that, paste:

the exact HTTP ... request_id=... line from the TUI, and
run openclaw logs --follow, send hey once, and paste the 10–20 log lines around the error.

If Sonnet works but Opus 4.5/4.6 keeps 404’ing, that’s Anthropic model access (your key/account doesn’t have Opus enabled) — OpenClaw can’t fix that locally.

slate hound Feb 8, 2026, 4:05 AM

#

i added gpt now TTP 400: Unsupported value: 'low' is not supported with the 'gpt-5.2-chat-latest' model. Supported values are:

'medium'.

fluid ibexBOT Feb 8, 2026, 4:06 AM

#

slate hound i added gpt now TTP 400: Unsupported value: 'low' is not supported with the 'gp...

That HTTP 400: Unsupported value: 'low' … gpt-5.2-chat-latest is coming from OpenAI: OpenClaw is sending a thinking/reasoning level of low, but that particular model currently only accepts medium (so it hard-errors).

Quick fix (no config changes):

In the chat where it’s failing, send:
- /think:medium (or /t medium)
Then retry your message (or retry the model switch).

If you want to disable it instead (also works in most cases):

/think:off

Permanent fix (so failover to GPT won’t break):

Set your config default to something compatible, e.g.:
- agents.defaults.thinkingDefault: "medium" (or "off")

Docs: https://docs.openclaw.ai/tools/thinking

Also: what openclaw --version are you on? (Some of this behavior has changed recently, and version matters a lot for debugging model/failover issues.)

slate hound Feb 8, 2026, 4:10 AM

#

zsh: command not found: agents.defaults.thinkingDefault:

#

2026.2.6-3
version openclaw

fluid ibexBOT Feb 8, 2026, 4:11 AM

#

slate hound zsh: command not found: agents.defaults.thinkingDefault:

agents.defaults.thinkingDefault: is a config path, not a shell command — that’s why zsh says “command not found”.

You’ve got two easy options:

1) Fix it right in Discord (fastest)

Send this as a chat message to the bot (not in your terminal):

/think:medium

That sets the thinking level for this session, and then GPT-5.2 won’t error on “low”.

2) Make it permanent (terminal, on the machine running the Gateway)

Run:

openclaw config set agents.defaults.thinkingDefault medium

#

openclaw gateway restart

Docs:

Thinking levels: https://docs.openclaw.ai/tools/thinking
Config command: https://docs.openclaw.ai/cli/config

If this fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

#

2026.2.6-3 — perfect, that’s recent enough.

What’s happening in your case is usually this chain:

Claude Opus hits HTTP 429 (Anthropic rate limit / quota window)
OpenClaw fails over to GPT
Your session (or config) is set to /think:low, but gpt-5.2-chat-latest rejects low and only accepts medium → so you get the HTTP 400 Unsupported value: 'low'.

Fix (do this in Discord chat with the bot)

Send:

/think:medium

(or if you don’t care about thinking: /think:off)

After that, switching to GPT (or failing over) should work.

About the original `HTTP 429` (Opus)

#

That’s not a misconfig — it means Anthropic is rate-limiting you for the current window. Usual options:

wait for the window to reset, or
use a fallback model (GPT etc.), or
use an Anthropic API key / higher limits plan if you need sustained usage.

Docs (Anthropic 429): https://docs.openclaw.ai/help/faq#why-am-i-seeing-http-429-ratelimiterror-from-anthropic

If you run /think:medium and it still errors, paste the next error line you see (the full 1-liner).

slate hound Feb 8, 2026, 4:12 AM

#

HTTP 404: Item with id 'rs_08e57e987e081958727b3ad93663f19' not found. Items are not persisted
when store is set to false. Try again with store set to true, or remove this item from your input.
gateway connected | idle

fluid ibexBOT Feb 8, 2026, 4:15 AM

#

slate hound HTTP 404: Item with id 'rs_08e57e987e081958727b3ad93663f19' not found. Items are...

That HTTP 404 with rs_... is an OpenAI Responses API thing:

rs_... = an internal “response/reasoning item id”
OpenAI is telling you: you’re sending that old item id back in the next request, but because store=false (the default for these calls), OpenAI didn’t persist it, so it can’t be referenced anymore.

In practice this happens when GPT-5.* “thinking” is enabled: the session history contains those rs_... reasoning items, and the next turn replays them → boom.

Quick workaround (in Discord chat with the bot)

Reset the session (clears the bad rs_... item from history):

/new

Disable thinking for GPT for now:

/think:off

Then try your GPT model again.

If you want it to stay that way (terminal on the gateway host)

#

openclaw config set agents.defaults.thinkingDefault off
openclaw gateway restart

If you still want GPT “thinking” enabled specifically, this one is likely a bug/edge case in the OpenAI Responses integration — worth filing with your version + that exact 404 line: https://github.com/openclaw/openclaw/issues

slate hound Feb 8, 2026, 1:41 PM

#

when i ask my bot for a configure it always get disconnected

fluid ibexBOT Feb 8, 2026, 1:43 PM

#

slate hound when i ask my bot for a configure it always get disconnected

“configure” is a bit of an overloaded word in OpenClaw, so first: what exactly are you typing when it disconnects?

Common cases:

1) You’re typing `/configure` (or “configure …”) in Discord

There is no /configure chat command, so it won’t open the setup wizard.

The setup wizard is a terminal command on the machine running the Gateway:
```
openclaw configure
```
For simple edits you can do:
```
openclaw config set <path> <value>
```

2) You’re using `/config …` in Discord

#

That one is owner-only and disabled by default (needs commands.config: true). If it is enabled, it can trigger changes that require a restart, and you’ll see a disconnect while the gateway restarts.

If it disconnects and never comes back

That usually means the Gateway crashed or can’t start with the new config. On the Gateway host, run and paste:

openclaw gateway status
openclaw status --all
openclaw logs --limit 200

If you tell me the exact message you sent (e.g. /config set ... vs /configure vs something else) + whether “disconnected” is in the web dashboard or Discord, I can point to the exact fix.

slate hound Feb 8, 2026, 1:44 PM

#

actually and asking the bot for example

#

add someone on my allowlist

#

and it disconnects until i refresh the UI

fluid ibexBOT Feb 8, 2026, 1:45 PM

#

slate hound actually and asking the bot for example

If you just ask the bot in Discord something like “can you show me an example config / example configure”, that shouldn’t disconnect anything — so when it does, it usually means the Gateway process crashed/restarted while trying to answer.

Two quick things to try in the Discord chat with the bot first (no terminal):

Start a fresh session (clears the “poisoned” history from the earlier GPT/Codex errors):

/new

Keep GPT/Codex from doing the “stored response id” / thinking dance:

/think:off
(you can turn it back on later once it’s stable)

Then ask again, but keep it small, e.g. “show me a minimal config snippet to add OpenAI”.

If it still disconnects, we need the crash reason from the Gateway host. On the machine running OpenClaw, run and paste:

#

openclaw gateway status
openclaw status --all
openclaw logs --limit 200

Those outputs usually make it obvious whether it’s:

the gateway restarting due to a bad config edit,
a model/provider error loop,
or Discord message sending failing (too long / formatting).

Also: when you say “disconnected”, do you mean the web dashboard says disconnected, or the bot in Discord stops replying?

fluid ibexBOT Feb 8, 2026, 1:46 PM

#

slate hound add someone on my allowlist

To “allowlist someone” on Discord, it depends where you want them to talk to the bot:

A) Let them DM the bot (recommended): pairing

This is the default-safe flow.

Have them DM your bot once
On the gateway host, run:

openclaw pairing list discord
openclaw pairing approve discord <CODE>

That approves them without you editing config.

B) Hard allowlist DMs via config (manual)

Get their Discord User ID (Discord → Settings → Advanced → Developer Mode → right‑click user → “Copy User ID”)

#

On the gateway host:

openclaw config set channels.discord.dm.policy allowlist
openclaw config set channels.discord.dm.allowFrom '["USER_ID_HERE"]' --json
openclaw gateway restart

(If you want multiple people, add more IDs to the JSON array.)

C) Allow them in a server channel (guild)

That’s a different allowlist: channels.discord.guilds.<guildId>.users (or per-channel ...channels.<channel>.users).

If you tell me DM vs server channel, I’ll give you the exact snippet for your case (and how to get the guild/channel IDs).

slate hound Feb 8, 2026, 1:46 PM

#

im tlaking in the dashboard

#

it's always after they finish a new configuration..

fluid ibexBOT Feb 8, 2026, 1:47 PM

#

slate hound and it disconnects until i refresh the UI

That “disconnects until I refresh the UI” sounds like the Control UI ↔ Gateway WebSocket is dropping.

Two common reasons:

1) The Gateway restarted (expected when config changes apply)

If you add someone to an allowlist via /config or via the Control UI config editor, the gateway often restarts to apply it. The UI websocket drops, and you may need a refresh to reconnect.

To confirm, on the gateway host run right after it “disconnects”:

openclaw gateway status
openclaw logs --limit 200

2) The UI is telling you the real reason (pairing / insecure HTTP)

When it disconnects, the UI banner usually says something like:

#

Got it — if it’s the dashboard chat (Control UI) that disconnects, then we’re debugging the browser ↔ gateway websocket, not Discord.

Please do these in order:

1) Look at the exact disconnect reason in the UI

When it drops, the banner usually says something like:

disconnected (1008): pairing required
or device identity required
or something else

Paste that exact line.

2) Tell me the URL you open the dashboard on

Which one is it?

http://127.0.0.1:18789/ (same machine)
http://<server-ip>:18789/ (LAN/VPS)
http://<tailscale-ip>:18789/ or https://<magicdns>/ (Tailscale Serve)

#

This matters a lot: plain HTTP on a remote IP often breaks device identity and causes repeated disconnects unless you use HTTPS/Tailscale Serve.

3) If it says “pairing required” (most common)

Approve the dashboard device on the gateway host:

openclaw devices list
openclaw devices approve <requestId>

(Control UI doc: https://docs.openclaw.ai/web/control-ui#device-pairing-first-connection)

4) If it’s just randomly dropping with no pairing message

Run on the gateway host and paste output:

#

openclaw gateway status
openclaw logs --limit 200

That will show whether the gateway is restarting/crashing right when you send a message.

#

disconnected (1008): pairing required → you need to approve that browser/device once:
```
openclaw devices list
openclaw devices approve <requestId>
```
device identity required (often when opening the UI over plain http://<lan-ip> / http://<tailscale-ip>)
Fix: use HTTPS via Tailscale Serve:
```
openclaw gateway --tailscale serve
```
then open https://<magicdns>/

Can you paste the exact disconnect line the UI shows (especially the code like 1008) and tell me what URL you’re using (http://127.0.0.1:18789 vs LAN/Tailscale/Cloudflare/etc.)? That pins it down fast.

#

Yeah — that pattern is expected if you’re editing/applying config from the dashboard.

When you “finish a new configuration” (save/apply), OpenClaw has to restart the Gateway to load the new config. The Control UI is connected via a single WebSocket to that Gateway, so the socket drops. In the current UI it often won’t seamlessly reattach, so you end up needing a manual refresh.

How to avoid the disconnect (for “add someone to allowlist”)

Use pairing approval instead of editing config (no gateway restart):

Have them DM the bot once
On the gateway host:

openclaw pairing list discord
openclaw pairing approve discord <CODE>

If you do need to edit allowlists in config

Then a brief disconnect is normal. After you apply:

wait ~5–10s for the gateway to come back, then refresh the page.

#

If you paste the exact banner text the dashboard shows when it drops (e.g. disconnected (1008): ...) and the URL you’re using to access the dashboard (127.0.0.1 vs LAN/Tailscale), I can tell if it’s a simple restart disconnect or a pairing/auth issue.

slate hound Feb 8, 2026, 1:53 PM

#

disconnected (1005): no reason
the problem is that is not getting up byyitself

fluid ibexBOT Feb 8, 2026, 1:54 PM

#

slate hound disconnected (1005): no reason the problem is that is not getting up byyitself

disconnected (1005): no reason in the dashboard usually just means: the WebSocket got dropped without a clean close frame — most commonly because the Gateway restarted right after you hit Apply config.

Two separate things can be true:

Gateway did restart and is up again, but the Control UI doesn’t reliably auto‑reconnect yet → you end up having to refresh manually.
The Gateway failed to come back up after applying the config → then it will never reconnect until you fix the config and restart.

Check which one it is (on the machine running OpenClaw)

Run:

openclaw gateway status
openclaw logs --limit 200

What you’re looking for:

RPC probe: ok → gateway is up; this is mostly a UI reconnect annoyance.

#HTTP 429 error - how to fix it?

1) First: which 429 is it?

2) Quick info that will let us diagnose fast

3) “When I try to add other models, they stop working…”

Quick checks

If you want Ollama as a real fallback

Re: “Groq fallback but it never hits Groq”

1) Ollama isn’t actually enabled for OpenClaw

2) “Same machine” but not the same localhost

3) Fallback exists, but never gets triggered

Fix (pick one)

One more important detail (Ollama)

Find where the “configured models” restriction lives

Fast workaround (no sleuthing)

Fix: add Groq + Opus into the configured model catalog

1) Does the Gateway see any activity when you send hey?

2) Try a command that doesn’t require an LLM call

A) Auto-discovery is ON, but none of your installed Ollama models are “tool-capable”

B) You have an explicit models.providers.ollama config (disables auto-discovery)

One more important thing

Fix right now (fastest)

Longer-term options

Option 1 (recommended): stop the 42GB pull + explicitly configure Ollama

Option 2: finish pulling a tool-capable model (but it’ll be big)

One important gotcha (this affects Groq too)

Fix: run these exactly (one by one)

Important: add Ollama to your configured models allowlist too

Step 1: See the valid Anthropic model IDs on your install

Step 2: Update BOTH places in config

Quick workaround (stop the “agent failed” loop)

0) Find the valid Opus ID on your machine

1) Set it in both places (fallbacks + configured catalog)

(Strongly recommended) prevent the 429/cooldown spiral

Option A (recommended): reset via wizard (cleanest)

Option B: hard-reset model settings by CLI (keep your API keys/auth)

What your status means

“Efficient?”

“Learn well?”

Make fallback actually work (recommended)

Also: prevent the Anthropic 429 spiral

Quick test that fallback works

1) Find the Opus 4.6 (or 4.5) ID your OpenClaw knows

2) Set Opus as primary + keep a non-Anthropic fallback (so 429 doesn’t kill you)

3) (Strongly recommended) reduce concurrency to avoid Anthropic cooldowns

Does a second Anthropic API key help?

1) Add a 2nd Anthropic key as a separate auth profile

2) Tell OpenClaw to rotate between the two Anthropic profiles (deterministic order)

3) Set Sonnet as primary (and keep Opus as Anthropic fallback + Groq as non‑Anthropic fallback)

4) (Highly recommended) reduce concurrency so you stop slamming into 429

Quick fix: switch to an Opus ID that’s more likely to work

If that still 404s, your account likely can’t use Opus 4.5/4.6 right now

Does a “second Anthropic key” help?

Fast way to prove it

What you can do

Does a “second Anthropic key” help with this 404?

Option 1: “Reset models only” (keeps WhatsApp linked, keeps keys)

Option 2: “Nuke it from orbit” (config + creds + sessions) and re-onboard

Before you do Option 2

A) Reproduce once + tail logs

B) If you mean “Opus 4.6 isn’t working”

C) Check channel connectivity (if WhatsApp is the “not connecting”)

Step 1 — force Anthropic to try your API key profile first

Step 2 — pin the credential in the TUI (quick test)

Step 3 — if it still 404s, you don’t have Opus access on that account/key

1) Test Opus with each Anthropic credential (pins the profile)

2) Force the working Anthropic profile to be tried first (global order)

3) Sanity check: does Sonnet work on this key?

1) Reset model selection + fallbacks

2) Reset the TUI session (clears any per-session overrides)

3) If you still want Opus afterwards

Optional: wipe Ollama from the config too (if you don’t want it involved)

1) Wipe the messy model config back to baseline

2) Re-add your API keys (stored as auth profiles; prompts you to paste)

3) Set a stable default + one fallback (no allowlist needed)

4) Stop the 429 spiral (high impact)

5) Test in TUI

If you still want Opus as primary

1) Force OpenClaw to try your API-key profile first (then test again)

2) Prove it’s “Opus access” by switching to Sonnet

3) Why “configured” doesn’t help

1) Does the Gateway see any activity when you send `hey`?

B) You have an explicit `models.providers.ollama` config (disables auto-discovery)

3) If Opus 4.5 still 404s even when pinned to `anthropic:default`

About the original `HTTP 429` (Opus)

1) You’re typing `/configure` (or “configure …”) in Discord

2) You’re using `/config …` in Discord