An unknown error occurred | Friends of the Crustacean 🦞🤝 | Page 1

wind pendant Apr 20, 2026, 7:16 PM

#

Hey Krill!

I keep getting these unkown error occurred and there seems to be no error handling for it. I am on openclaw 2026.3.24

2026-04-20T19:11:52.414+00:00 [telegram] sendMessage ok chat=1359334095 message=6882
2026-04-20T19:11:55.398+00:00 [telegram] sendMessage ok chat=1359334095 message=6883
2026-04-20T19:11:55.467+00:00 [ws] ⇄ res ✓ sessions.list 54ms conn=b438b76c…b675 id=ea967657…95a7
2026-04-20T19:11:57.644+00:00 [telegram] sendMessage ok chat=1359334095 message=6884
2026-04-20T19:12:02.320+00:00 [agent/embedded] embedded run agent end: runId=9cc93705-4ebb-48c3-90b4-0dd52ccd6d32 isError=true model=gemini-3-flash-preview provider=google error=An unknown error occurred rawError=An unknown error occurred
2026-04-20T19:12:02.640+00:00 [telegram] sendMessage ok chat=1359334095 message=6885
2026-04-20T19:12:03.692+00:00 [telegram] sendMessage ok chat=1359334095 message=6886
2026-04-20T19:12:19.031+00:00 [ws] ⇄ res ✓ sessions.list 50ms conn=b438b76c…b675 id=211f6567…e66a
2026-04-20T19:12:19.120+00:00 [telegram] sendMessage ok chat=1359334095 message=6888
2026-04-20T19:12:21.567+00:00 [telegram] sendMessage ok chat=1359334095 message=6889
2026-04-20T19:12:28.713+00:00 [agent/embedded] embedded run agent end: runId=7740e9ee-5601-41fa-b836-483207a857ba isError=true model=gemini-3-flash-preview provider=google error=An unknown error occurred rawError=An unknown error occurred

I have to send the agent a message to nudge it to continue after this error. It happened twice. Why isn't the system using the configured fallbacks?

hasty sparrowBOT Apr 20, 2026, 7:16 PM

#

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

gusty swanBOT Apr 20, 2026, 7:19 PM

#

Yep, that’s frustrating.

Short version: that "An unknown error occurred" should only stop the run like this if the active run had no usable fallback candidates.

A few important bits from the current fallback logic:

OpenClaw tries the current session model first
then agents.defaults.model.fallbacks
but if the session is currently on a different provider/model override, OpenClaw does not automatically append unrelated fallbacks from another provider unless that current model is already part of the configured chain

So if this thread/session was switched to google/gemini-3-flash-preview, that can explain it. The nudge works because it starts a new run, it doesn’t resume the failed one.

Most likely causes:

Session /model override
- If you manually switched this session to Google, your normal fallback chain may not be getting attached.

#

Agent-level override disabling global fallbacks
- agents.list[].model.fallbacks: [] overrides and disables default fallbacks.
2026.3.24 is a bit behind
- there were more fallback/cooldown fixes after that, so upgrading is worth trying.

What I’d check first:

openclaw models status
openclaw status --all

And specifically:

did you use /model in that session/thread?
what do you have under agents.defaults.model
do you also have any agents.list[].model override for that agent?

#

Docs:

If you paste:

openclaw models status
the relevant agents.defaults.model / agents.list[].model config
whether /model was used in that thread

…I can tell you pretty quickly which of the three it is.

wind pendant Apr 20, 2026, 7:35 PM

#

I did switch the model to the default through out the session. Will it still discard the defaults?

gusty swanBOT Apr 20, 2026, 7:36 PM

#

No, not if it’s actually back on the configured default.

If the run starts on the configured default model, OpenClaw should use the normal chain again:

current model
configured fallbacks
primary again at the end only in some override cases

So switching back to default for later turns should restore default fallback behavior. It does not keep “discarding defaults” just because the session used a different model earlier.

That means if it’s still dying on google/gemini-3-flash-preview with no fallback, I’d look at these next:

the session didn’t truly land on the configured default
that agent has its own model.fallbacks override, especially []
all your fallbacks are same-provider Google models, and 2026.3.24 is old enough that I’d still be a little suspicious of fallback/cooldown behavior there

So the key question becomes: was google/gemini-3-flash-preview actually your configured default at that moment, or was it still a session/agent override?

#

If you want, paste these and I can narrow it down fast:

openclaw models status
openclaw status --all

and the relevant bits of:

agents.defaults.model
agents.list[].model

Docs:

wind pendant Apr 20, 2026, 7:43 PM

#

Quick question: what is the difference between context window and max tokens in ollama configuration?

As for the issue we are discussing, here are the outputs of the commands you requested

Config        : ~/.openclaw/openclaw.json
Agent dir     : ~/.openclaw/agents/main/agent
Default       : google/gemini-3-flash-preview
Fallbacks (2) : google/gemini-3.1-flash-lite-preview, moonshot/kimi-k2.5
Image model   : -
Image fallbacks (0): -
Aliases (4)   : gemini-flash -> google/gemini-3-flash-preview, kimi-k2.5 -> moonshot/kimi-k2.5, gemini-flash-lite -> google/gemini-3.1-flash-lite-preview, gemini-pro -> google/gemini-3.1-pro-preview
Configured models (5): google/gemini-3-flash-preview, moonshot/kimi-k2.5, google/gemini-3.1-flash-lite-preview, google/gemini-3.1-pro-preview, ollama/qwen3.5:9b

Auth overview
Auth store    : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env     : off
Providers w/ OAuth/tokens (0): -
- google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyDb...RFm0UoSY
- moonshot effective=env:sk-qQxni...K3lMlsCI | env=sk-qQxni...K3lMlsCI | source=env: MOONSHOT_API_KEY
- ollama effective=missing:missing | models.json=marker(ollama-local) | source=models.json: ~/.openclaw/agents/main/agent/models.json
- openai effective=env:sk-proj-...-dA0MWMA | env=sk-proj-...-dA0MWMA | source=env: OPENAI_API_KEY

OAuth/token status
- none

The status are all green values.

gusty swanBOT Apr 20, 2026, 7:45 PM

#

Yep, this helps a lot.

On your fallback issue

Your config looks correct. You really do have a fallback chain:

google/gemini-3-flash-preview
→ google/gemini-3.1-flash-lite-preview
→ moonshot/kimi-k2.5

So this does not look like “fallbacks not configured”.

What I think is happening is subtler, and honestly looks like a real bug / classification gap:

that Google message is just An unknown error occurred
in the failover logic, that exact generic text is treated as failover-worthy for some providers, but not for Google
so the run ends as an assistant-side terminal error instead of being escalated into model fallback

#

That matches your behavior exactly:

run dies
no fallback model is tried
sending another message starts a fresh run, so it “nudges” forward

So the good news is: your setup looks sane
The bad news is: this is probably not your fault

Also, the all-green status is expected. It only says auth/config resolution is healthy, not that this specific runtime error path is classified correctly.

What I’d do

Update to latest and retest first
If it still happens, I’d call it a bug and file an issue here:
https://github.com/openclaw/openclaw/issues

Include:

#

your version
the log snippet
openclaw models status
the note that fallback chain exists but Google An unknown error occurred does not advance to fallback

Temporary workaround

If this is hurting reliability right now, I’d temporarily make a non-Google model your primary, or at least put the more reliable provider first.

Ollama: context window vs max tokens

Short version:

contextWindow = how many total tokens the model can see in one request
(system prompt + history + tool results + your new message + room for output)

#

maxTokens = how many tokens the model is allowed to generate back as output

So:

contextWindow is the whole bucket
maxTokens is the response slice

Example:

contextWindow: 131072
maxTokens: 8192

means the model can see up to ~131k total tokens, and OpenClaw will ask for at most ~8k output tokens.

For Ollama specifically, OpenClaw can also inject options.num_ctx on OpenAI-compatible Ollama routes so Ollama doesn’t silently fall back to a tiny context.

Docs:

#

If you want, paste your Ollama model block too and I can sanity-check those numbers.

wind pendant Apr 20, 2026, 7:55 PM

#

Alright! Let's validate the ollama configuration.

I have this in the puligins section

      "ollama": {
        "enabled": true
      }

I also have this in the models

  "models": {
    "providers": {
      "ollama": {
        "baseUrl": "http://192.168.1.70:11434",
        "apiKey": "ollama-local",
        "api": "ollama",
        "models": [
          {
            "id": "qwen3.5:9b",
            "name": "Qwen 3.5 9B",
            "api": "ollama",
            "reasoning": false,
            "input": [
              "text"
            ],
            "cost": {
              "input": 0,
              "output": 0,
              "cacheRead": 0,
              "cacheWrite": 0
            },
            "contextWindow": 262144,
            "maxTokens": 262144
          }
        ]
      }
    }
  },

and I added the model in the defaults.models. Is there anything else to configure? How can I optimize it?

gusty swanBOT Apr 20, 2026, 7:57 PM

#

Mostly yes, but I’d change a couple things.

What looks good

baseUrl: "http://192.168.1.70:11434" is correct
api: "ollama" is correct
no /v1 on the URL, also correct
manual model entry is fine since you’re explicitly defining models.providers.ollama

What I would change

Drop the huge maxTokens
- maxTokens: 262144 is way too aggressive for a local 9B setup
- I’d start with 4096 or 8192
- maxTokens is output cap, not total context
Only keep contextWindow: 262144 if Ollama really exposes that

#

match the actual model/server limit
- don’t set it to a fantasy number just because the model family advertises it
- check with:
```
ollama show qwen3.5:9b
```

Your plugin block is probably not doing what you think
- documented plugin config lives under plugins.entries...
- for normal Ollama model usage, you generally do not need a separate plugin enable block at all
- the important part is models.providers.ollama

My recommendation

For this model, I’d use something closer to:

#

{
  models: {
    mode: "merge",
    providers: {
      ollama: {
        baseUrl: "http://192.168.1.70:11434",
        apiKey: "ollama-local",
        api: "ollama",
        models: [
          {
            id: "qwen3.5:9b",
            name: "Qwen 3.5 9B",
            reasoning: false,
            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },

#

            contextWindow: 32768, // or whatever ollama show reports
            maxTokens: 8192
          }
        ]
      }
    }
  }
}

Is anything else required?

For basic chat model use, no, not really.
What you already have is enough if:

the model exists on the Ollama host

#

OpenClaw can reach that host
you added ollama/qwen3.5:9b to your allowed/default models correctly

How I’d optimize it

keep cloud primary, local as fallback
keep models.mode: "merge" so hosted models stay available
use local 9B mostly for lighter tasks, not heavy tool-calling
keep maxTokens modest, this matters a lot for latency/stability

Tiny warning, local 9B models often get flaky with tool calling in OpenClaw. I wouldn’t trust it as the main agent model unless you’ve tested it pretty hard.

Docs:

#

If you paste the output of ollama show qwen3.5:9b, I can tell you what contextWindow I’d actually set.

wind pendant Apr 20, 2026, 8:00 PM

#

I would be using it for tasks and as a sub agent. For subagents are there any optimizations to be made?

#

With ollama, the agent would stop in the middle of the task with this error

2026-04-20T20:05:31.169+00:00 [agent/embedded] embedded run agent end: runId=ac8ef99a-a1e1-4461-957e-9c3ba979cafd isError=true model=qwen3.5:9b provider=ollama error=Ollama API stream ended without a final response rawError=Ollama API stream ended without a final response

What could be the issue? On ollama, there are no errors in the logs. Is there some sort of a timeout?

gusty swanBOT Apr 20, 2026, 8:12 PM

#

That specific Ollama error does not look like OpenClaw’s built-in timeout path.

If OpenClaw itself hit the LLM idle timeout, you’d usually see something like:

LLM idle timeout (...)
or a message pointing at agents.defaults.llm.idleTimeoutSeconds

What you have instead:

Ollama API stream ended without a final response

means OpenClaw started reading the stream, then the stream closed before Ollama sent the terminating final chunk.

What usually causes that

Most likely one of these:

#

Ollama/server dropped the stream mid-generation
- worker crash/reset
- memory pressure
- model runner died and restarted
Network/proxy interruption
- especially since your Ollama host is remote: 192.168.1.70
- any reverse proxy / tunnel / LB in front can kill long streaming responses
Config is too aggressive
- maxTokens: 262144 is a huge red flag here
- contextWindow: 262144 may also be higher than the box can really sustain
Older Ollama bug / stream bug
- OpenClaw’s native Ollama path expects proper /api/chat streaming with a final completion chunk

My strongest recommendation

#

I would lower the model limits first.

For a 9B local model, try something more conservative:

{
  contextWindow: 32768, // or whatever `ollama show` actually reports
  maxTokens: 4096       // maybe 8192 if the box handles it well
}

I would definitely not leave maxTokens: 262144.

That setting can make runs ridiculously long and fragile, and if the server dies mid-stream, OpenClaw gets exactly the kind of error you’re seeing.

Quick checks

#

Verify actual model/server limits
```
ollama show qwen3.5:9b
```
Make sure you are talking directly to Ollama
- good: http://192.168.1.70:11434
- bad: proxy/tunnel in front of it, if avoidable
Watch Ollama while a failing run happens
- if it’s a service: journalctl -u ollama -f
- also watch RAM/VRAM on the Ollama box
Update Ollama
- this smells like stream termination upstream more than an OpenClaw-only bug

My read

#

So, short answer: probably not an OpenClaw timeout
It looks more like the Ollama stream is ending early upstream, and your very large contextWindow / maxTokens settings are making that more likely.

Also, for agentic runs, a local 9B model is pretty easy to knock over. I’d keep it as a lighter-duty model or fallback, not my main workhorse.

Docs:

If you want, paste the output of ollama show qwen3.5:9b and I’ll suggest sane exact values.

wind pendant Apr 21, 2026, 8:27 AM

#

It has been working fine so far. It managed to complete some tasks. I wonder what model or system are you part of? You seem to be very good at solving issues.

gusty swanBOT Apr 21, 2026, 8:28 AM

#

Heh, thank you, I appreciate that 🦐

I’m Krill, the OpenClaw support crustacean hanging out in Discord.
The useful part is less “magic model” and more that I try to:

read the docs first
check the actual source when docs are fuzzy
avoid guessing config keys
reason from the logs you paste

So basically, patient debugging plus a decent memory for where the weird stuff lives.

I’m not going to claim a runtime model here, since that gets stale fast and is usually not the helpful part anyway. If you want current model chatter or recommendations, #models is the best place for fresh real-world info.

And I’m glad it’s been working for some tasks, that usually means you’re close, not cursed.

#An unknown error occurred

On your fallback issue

What I’d do

Temporary workaround

Ollama: context window vs max tokens

What looks good

What I would change

My recommendation

Is anything else required?

How I’d optimize it

What usually causes that

My strongest recommendation

Quick checks

My read