400 error | Friends of the Crustacean 🦞🤝 | Page 1

hoary gulch Feb 14, 2026, 1:48 PM

#

why it show 400 in v1/api/comp....

time=2026-02-14T14:32:51.529+05:30 level=INFO source=routes.go:1725 msg="entering low vram mode" "total vram"="0 B" threshold="20.0 GiB"

[GIN] 2026/02/14 - 14:32:56 | 400 |     72.2898ms |       127.0.0.1 | POST     "/v1/chat/completions"

[GIN] 2026/02/14 - 14:34:24 | 200 |      3.1542ms |       127.0.0.1 | GET      "/api/tags"

[GIN] 2026/02/14 - 14:34:24 | 200 |    165.5041ms |       127.0.0.1 | POST     "/api/show"

[GIN] 2026/02/14 - 14:35:54 | 400 |     67.0378ms |       127.0.0.1 | POST     "/v1/chat/completions"

[GIN] 2026/02/14 - 14:35:57 | 400 |      85.173ms |       127.0.0.1 | POST     "/v1/chat/completions"

[GIN] 2026/02/14 - 14:36:07 | 400 |     63.8674ms |       127.0.0.1 | POST     "/v1/chat/completions"

"models": {
    "providers": {
      "ollama": {
        "api": "openai-conpletions",
        "baseUrl": "http://127.0.0.1:11434/v1",
        "apiKey": "ollama-local",
        "models": [
          {
            "id": "llama3",
            "name": "llama3"
          }
        ]
      }
    }
  },```

fervent vineBOT Feb 14, 2026, 1:48 PM

#

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

vagrant boughBOT Feb 14, 2026, 1:49 PM

#

That 400 is coming from Ollama (the Gin logs are Ollama’s HTTP server), and it usually means the request payload it received is invalid for /v1/chat/completions.

Two problems jump out in the config you pasted:

Typo in api

api: "openai-conpletions"

Should be:

api: "openai-completions"

That typo can make OpenClaw treat the provider API mode wrong and send a payload Ollama rejects.

Model/tool mismatch (common)
OpenClaw will often include tools / function-calling fields in the request. Many Ollama models (or some tags) don’t support tool calling → Ollama returns 400.

#

Recommended fix (simplest)

Don’t hardcode the provider block at all—let OpenClaw auto-detect Ollama:

Set OLLAMA_API_KEY=ollama-local (any value is fine; Ollama doesn’t need a real key)
Set your model like:

{
  agents: {
    defaults: {
      model: { primary: "ollama/llama3.3" } // or another tool-capable model you have
    }
  }
}

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

#

If you want to keep explicit config

At minimum fix the typo:

models: {
  providers: {
    ollama: {
      baseUrl: "http://127.0.0.1:11434/v1",
      apiKey: "ollama-local",
      api: "openai-completions",
      models: [{ id: "llama3", name: "llama3" }],
    }
  }
}

Next step to pinpoint the exact cause

#

Paste the actual error text (not just 400) from OpenClaw’s logs:

openclaw logs --follow
# or
openclaw status --all
openclaw models status

Ollama usually includes a message like “unsupported field …” / “tools not supported” / “invalid model”, and that will tell us exactly what to change.

hoary gulch Feb 14, 2026, 2:03 PM

#

``pu library=cpu compute="" name=cpu description=cpu libdirs=ollama driver="" pci_id="" type="" total="15.4 GiB" available="7.0 GiB"
time=2026-02-14T19:24:51.661+05:30 level=INFO source=routes.go:1725 msg="entering low vram mode" "total vram"="0 B" threshold="20.0 GiB"
[GIN] 2026/02/14 - 19:28:53 | 400 | 70.7392ms | 127.0.0.1 | POST "/v1/chat/completions"


``` "hooks": {
    "internal": {
      "enabled": true,
      "entries": {
        "boot-md": {
          "enabled": true
        },
        "bootstrap-extra-files": {
          "enabled": true
        },
        "command-logger": {
          "enabled": true
        },
        "session-memory": {
          "enabled": true
        }
      }
    }
  },
  "messages": {
    "ackReactionScope": "group-mentions"
  },
  "meta": {
    "lastTouchedAt": "2026-02-14T07:32:00.663Z",
    "lastTouchedVersion": "2026.2.13"
  },
  "models": {
    "providers": {
      "ollama": {
        "api": "openai-completions",
        "baseUrl": "http://127.0.0.1:11434/v1",
        "apiKey": "ollama-local",
        "models": [
          {
            "id": "llama3",
            "name": "llama3"
          }
        ]
      }
    }
  },```
Copyright (C) Microsoft Corporation. All rights reserved.

Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows

PS C:\Users\rion> openclaw models status

🦞 OpenClaw 2026.2.13 (203b5bd) — Because texting yourself reminders is so 2024.

Config        : ~\.openclaw\openclaw.json
Agent dir     : ~\.openclaw\agents\main\agent
Default       : ollama/llama3
Fallbacks (0) : -
Image model   : -
Image fallbacks (0): -
Aliases (0)   : -
Configured models (0): all

Auth overview
Auth store    : ~\.openclaw\agents\main\agent\auth-profiles.json
Shell env     : off
Providers w/ OAuth/tokens (0): -
- ollama effective=models.json:ollama-local | models.json=ollama-local | source=models.json: ~\.openclaw\agents\main\agent\models.json

OAuth/token status
- none

vagrant boughBOT Feb 14, 2026, 2:05 PM

#

That 400 line is Ollama rejecting the request to its OpenAI-compatible endpoint (/v1/chat/completions). The missing piece is: what is the JSON error body Ollama returns (it will tell us exactly which field/model is invalid).

1) First: confirm Ollama itself accepts a minimal OpenAI request

Run this in PowerShell (this shows the real error message):

$body = @{
  model    = "llama3"
  messages = @(@{ role = "user"; content = "hi" })
} | ConvertTo-Json -Depth 10

Invoke-RestMethod `
  -Uri "http://127.0.0.1:11434/v1/chat/completions" `
  -Method Post `
  -ContentType "application/json" `
  -Body $body

#

Also paste:

ollama --version
ollama list

Common outcomes:

“model not found” → your model name is wrong or not pulled. Use the exact name from ollama list (often includes a tag like :latest).
“unknown field tools / tool_choice / response_format …” → your Ollama version doesn’t support some OpenAI fields OpenClaw sends (usually tool-calling related). Updating Ollama usually fixes this.

2) If the minimal request works, but OpenClaw still gets 400

Then OpenClaw is sending a richer payload than the minimal one (usually includes tools/function-calling), and your Ollama model/version combo is rejecting it.

Quick isolation test (disables all tools — OpenClaw becomes “chat only”):

#

  tools: { deny: ["*"] }
}

Restart the gateway and see if the 400 goes away. If it does, the fix is: use a tool-capable model (or rely on auto-discovery), not “deny all tools” long term.

3) Best-practice Ollama setup for OpenClaw

If possible, let OpenClaw auto-detect Ollama + filter to tool-capable models (recommended):

remove your explicit models.providers.ollama block
set OLLAMA_API_KEY (any value) via config so the service sees it:

{
  env: { OLLAMA_API_KEY: "ollama-local" },
  agents: { defaults: { model: { primary: "ollama/llama3.3" } } }
}

#

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

Paste the output of the PowerShell Invoke-RestMethod call (the error JSON). With that, we can tell you the exact one-line fix.

hoary gulch Feb 14, 2026, 2:09 PM

#

ler size = 0.50 MiB
llama_kv_cache: CPU KV buffer size = 512.00 MiB
llama_kv_cache: size = 512.00 MiB ( 4096 cells, 32 layers, 1/1 seqs), K (f16): 256.00 MiB, V (f16): 256.00 MiB
llama_context: Flash Attention was auto, set to enabled
llama_context: CPU compute buffer size = 258.50 MiB
llama_context: graph nodes = 999
llama_context: graph splits = 1
time=2026-02-14T19:36:31.008+05:30 level=INFO source=server.go:1385 msg="llama runner started in 4.55 seconds"
time=2026-02-14T19:36:31.008+05:30 level=INFO source=sched.go:526 msg="loaded runners" count=1
time=2026-02-14T19:36:31.008+05:30 level=INFO source=server.go:1347 msg="waiting for llama runner to start responding"
time=2026-02-14T19:36:31.009+05:30 level=INFO source=server.go:1385 msg="llama runner started in 4.55 seconds"
[GIN] 2026/02/14 - 19:36:34 | 200 | 8.3075373s | 127.0.0.1 | POST "/v1/chat/completions"


Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows

PS C:\Users\rion> $body = @{
>>   model    = "llama3"
>>   messages = @(@{ role = "user"; content = "hi" })
>> } | ConvertTo-Json -Depth 10
PS C:\Users\rion>
PS C:\Users\rion> Invoke-RestMethod `
>>   -Uri "http://127.0.0.1:11434/v1/chat/completions" `
>>   -Method Post `
>>   -ContentType "application/json" `
>>   -Body $body


id                 : chatcmpl-683
object             : chat.completion
created            : 1771077994
model              : llama3
system_fingerprint : fp_ollama
choices            : {@{index=0; message=; finish_reason=stop}}
usage              : @{prompt_tokens=11; completion_tokens=25; total_tokens=36}



PS C:\Users\rion>

PS C:\Users\rion> ollama --version
ollama version is 0.15.1
PS C:\Users\rion> ollama list
NAME ID SIZE MODIFIED
llama3:latest 365c0bd3c000 4.7 GB 6 hours ago
PS C:\Users\rion>

vagrant boughBOT Feb 14, 2026, 2:11 PM

#

Nice — that proves Ollama + llama3 + /v1/chat/completions works (your manual request got 200). So the 400 you see in the Ollama Gin logs is almost certainly because OpenClaw is sending extra fields that your Ollama OpenAI-compat endpoint is rejecting.

In practice, the usual culprit is: tool/function-calling payload (OpenClaw sends a big tools schema; many local stacks/models choke on it and return HTTP 400).

Quick confirmation (fastest)

Temporarily make OpenClaw “chat-only” (no tools), restart gateway, try again:

{
  tools: { deny: ["*"] }
}

If that makes the 400 disappear → confirmed: it’s tool schema/tool-calling causing the 400.

If you want to confirm directly against Ollama

Try a minimal “tools” request to see if Ollama accepts tools at all:

#

$body = @{
  model    = "llama3"
  messages = @(@{ role = "user"; content = "call ping" })
  tools    = @(@{
    type     = "function"
    function = @{
      name        = "ping"
      description = "returns pong"
      parameters  = @{ type = "object"; properties = @{} }
    }
  })
} | ConvertTo-Json -Depth 20

Invoke-RestMethod `
  -Uri "http://127.0.0.1:11434/v1/chat/completions" `

#

  -Method Post `
  -ContentType "application/json" `
  -Body $body

If this returns 400 → your Ollama build doesn’t support OpenAI tools (or expects a different shape) → OpenClaw will fail whenever tools are enabled.
If this returns 200 → Ollama supports tools, but OpenClaw’s tool schema is too complex (browser/canvas/etc). Then you can restrict tools for Ollama instead of disabling everything.

Best “real” fix (recommended)

Let OpenClaw auto-detect Ollama and only expose tool-capable models (this avoids a lot of manual mismatches):

remove the explicit models.providers.ollama block
set env.OLLAMA_API_KEY in config (any string)

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

One more thing: paste the OpenClaw-side error

#

Ollama logs only show 400, not why. Please paste the few lines around the failure from:

openclaw logs --follow

That will usually include the actual Ollama error message (e.g. “unknown field tools”, “invalid tool schema”, etc.), and then we can give the exact minimal config to keep what you need.

hoary gulch Feb 14, 2026, 2:17 PM

#

  "meta": {
    "lastTouchedVersion": "2026.2.13",
    "lastTouchedAt": "2026-02-14T14:04:27.870Z"
  },
  "wizard": {
    "lastRunAt": "2026-02-14T07:32:00.638Z",
    "lastRunVersion": "2026.2.13",
    "lastRunCommand": "onboard",
    "lastRunMode": "local"
  },
  "models": {
    "providers": {
      "ollama": {
        "baseUrl": "http://127.0.0.1:11434/v1",
        "apiKey": "ollama-local",
        "api": "openai-completions",
        "models": [
          {
            "id": "llama3",
            "name": "llama3"
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "ollama/llama3:latest"
      },
      "tools": {
        "deny": ["*"]
      }
    }
  },```
```C:\Users\rion\.openclaw\agents\main\agent\auth-profiles.json (agentDir: C:\Users\rion\.openclaw\agents\main\agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir."
14:16:25 [diagnostic] lane task error: lane=session:agent:main:main durationMs=39 error="Error: No API key found for provider "anthropic". Auth store: C:\Users\rion\.openclaw\agents\main\agent\auth-profiles.json (agentDir: C:\Users\rion\.openclaw\agents\main\agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir."
19:46:25 Embedded agent failed before reply: No API key found for provider "anthropic". Auth store: C:\Users\rion\.openclaw\agents\main\agent\auth-profiles.json (agentDir: C:\Users\rion\.openclaw\agents\main\agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir.```

vagrant boughBOT Feb 14, 2026, 2:19 PM

#

Good news: your PowerShell test shows Ollama is fine (/v1/chat/completions returns 200). The new failure you pasted is not Ollama — OpenClaw is trying to call Anthropic, then failing because you don’t have an Anthropic API key:

No API key found for provider "anthropic"

So the immediate problem is: your OpenClaw session/model selection is still on an Anthropic model somewhere, instead of Ollama.

Fix 1: Make the configured model unambiguously Ollama (and no fallbacks)

In your config you currently have a mismatch:

provider model id: "llama3"
agent primary: "ollama/llama3:latest"

To remove ambiguity, set the primary to the exact model id you defined (llama3) and disable fallbacks:

#

  models: {
    providers: {
      ollama: {
        baseUrl: "http://127.0.0.1:11434/v1",
        apiKey: "ollama-local",
        api: "openai-completions",
        models: [{ id: "llama3", name: "llama3" }],
      },
    },
  },

  agents: {
    defaults: {
      model: { primary: "ollama/llama3", fallbacks: [] },
    },

#

  },

  // if you still want the “avoid tool-calls” workaround for 400:
  tools: { deny: ["*"] },
}

Then restart:

openclaw gateway restart

Fix 2: Your Discord thread may still be “pinned” to Anthropic

Even after changing config, a Discord session can keep the previously selected /model.

#

In the Discord chat, send:

/model status
then: /model ollama/llama3
if it still insists, do /new and then /model ollama/llama3

After this, if you again see `400` in Ollama logs

That’s the other issue (tool/function schema). Keeping tools: { deny: ["*"] } at the top-level is the quick workaround while you confirm the bot replies.

If you paste the OpenClaw log lines right before a 400 (from openclaw logs --follow), we can narrow down exactly which field Ollama is rejecting.

hoary gulch Feb 14, 2026, 2:27 PM

#

14:24:26 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root
14:24:26 [gateway] agent model: ollama/llama3:latest
14:24:26 [gateway] listening on ws://127.0.0.1:18789 (PID 3580)
14:24:26 [gateway] log file: \tmp\openclaw\openclaw-2026-02-14.log
14:24:26 [browser/service] Browser control service ready (profiles=2)
14:24:27 [hooks:loader] Registered hook: boot-md -> gateway:startup
14:24:27 [hooks:loader] Registered hook: bootstrap-extra-files -> agent:bootstrap
14:24:27 [hooks:loader] Registered hook: command-logger -> command
14:24:27 [hooks:loader] Registered hook: session-memory -> command:new
14:24:27 [hooks] loaded 4 internal hook handlers
14:24:28 [telegram] [default] starting provider (@Misa1212bot)
14:24:28 [telegram] autoSelectFamily=false (default-node22)
14:24:36 [ws] webchat connected conn=f01de9bb-f21b-4b6f-b43f-aafb922c279c remote=127.0.0.1 client=openclaw-control-ui webchat vdev
14:24:36 [ws] ⇄ res ✓ chat.history 55ms conn=f01de9bb…279c id=3dce0306…0fbe
14:24:40 [hooks/session-memory] Session context saved to ~.openclaw\workspace\memory\2026-02-14-1424.md

msg="waiting for llama runner to start responding"
time=2026-02-14T19:36:31.009+05:30 level=INFO source=server.go:1385 msg="llama runner started in 4.55 seconds"
[GIN] 2026/02/14 - 19:36:34 | 200 | 8.3075373s | 127.0.0.1 | POST "/v1/chat/completions"
[GIN] 2026/02/14 - 19:37:32 | 404 | 3.7233ms | 127.0.0.1 | POST "/v1/chat/completions"
[GIN] 2026/02/14 - 19:39:28 | 200 | 0s | 127.0.0.1 | GET "/api/version"
[GIN] 2026/02/14 - 19:39:30 | 200 | 1.6101ms | 127.0.0.1 | HEAD "/"
[GIN] 2026/02/14 - 19:39:30 | 200 | 1.0382ms | 127.0.0.1 | GET "/api/tags"
[GIN] 2026/02/14 - 19:54:41 | 400 | 68.3359ms | 127.0.0.1 | POST "/v1/chat/completions"
[GIN] 2026/02/14 - 19:54:47 | 400 | 67.396ms | 127.0.0.1 | POST "/v1/chat/completions"

vagrant boughBOT Feb 14, 2026, 2:34 PM

#

You’re super close — the key detail is this:

Your `tools.deny` is in the wrong place, so OpenClaw is probably still sending `tools` to Ollama

This part of your config:

agents: {
  defaults: {
    tools: { deny: ["*"] }
  }
}

…doesn’t match the config structure OpenClaw documents for tool policy. Tool allow/deny is top-level (tools: { ... }) or per-agent in agents.list[].tools.

So even though you think tools are disabled, OpenClaw may still be including a big tools schema in the /v1/chat/completions request — and that’s a very common reason Ollama returns 400.

#

Fix: move it to top-level

Edit ~\.openclaw\openclaw.json to:

{
  tools: { deny: ["*"] },

  agents: {
    defaults: {
      model: { primary: "ollama/llama3:latest", fallbacks: [] }
    }
  }
}

Then:

#

openclaw gateway restart

Why you still see 200 sometimes

Your manual PowerShell call works (200) because it sends a minimal payload.
OpenClaw sometimes sends extra fields (especially tools / structured stuff) → Ollama rejects (400).

If you still get 400 after moving `tools.deny`

Then we need the actual error body Ollama returns. Turn on debug logs temporarily:

{
  logging: { level: "debug", consoleLevel: "debug" }
}

#

Restart, reproduce once, then paste the OpenClaw log lines around the failure from:

openclaw logs --follow

(Feel free to redact message content — we just need the JSON error reason.)

hoary gulch Feb 14, 2026, 2:52 PM

#

it work but it like [GIN] 2026/02/14 - 20:09:43 | 500 | 52.9924696s | 127.0.0.1 | POST "/v1/chat/completions"
msg="truncating input prompt" limit=4096 prompt=5616 keep=25 new=4096
[GIN] 2026/02/14 - 20:19:59 | 200 | 1.5571ms | 127.0.0.1 | GET "/api/tags"
time=2026-02-14T20:20:00.960+05:30 level=INFO source=download.go:179 msg="downloading 74701a8c35f6 in 14 100 MB part(s)"
[GIN] 2026/02/14 - 20:20:27 | 500 | 50.0400638s | 127.0.0.1 | POST "/v1/chat/completions"
[GIN] 2026/02/14 - 20:20:30 | 200 | 5.2478ms | 127.0.0.1 | GET "/api/tags"
[GIN] 2026/02/14 - 20:20:34 | 200 | 1.6014ms | 127.0.0.1 | GET "/api/tags"
time=2026-02-14T20:20:34.748+05:30 level=WARN source=runner.go:153 msg="truncating input prompt" limit=4096 prompt=5614 keep=25 new=4096
time=2026-02-14T20:20:47.303+05:30 level=INFO source=download.go:376 msg="74701a8c35f6 part 12 stalled; retrying. If this persists, press ctrl-c to exit, then 'ollama pull' to find a faster connection."
[GIN] 2026/02/14 - 20:21:00 | 200 | 1.0371ms | 127.0.0.1 | GET "/api/tags"
time=2026-02-14T20:21:24.303+05:30 level=INFO source=download.go:376 msg="74701a8c35f6 part 10 stalled; retrying. If this persists, press ctrl-c to exit, then 'ollama pull' to find a faster connection."
time=2026-02-14T20:21:25.303+05:30 level=INFO source=download.go:376 msg="74701a8c35f6 part 9 stalled; retrying. If this persists, press ctrl-c to exit, then 'ollama pull' to find a faster connection."
[GIN] 2026/02/14 - 20:21:30 | 200 | 1.4049ms | 127.0.0.1 | GET "/api/tags"
too slow the hardware spec is 5600g with 16gb ram

vagrant boughBOT Feb 14, 2026, 2:54 PM

#

Yep — that’s the next (very normal) bottleneck with CPU-only Ollama.

You’re seeing two separate things in the Ollama logs:

1) `truncating input prompt limit=4096 … prompt=5616`

Your model is effectively running with a 4096 context window, but OpenClaw is sending a prompt bigger than that (system prompt + chat history). Ollama chops it down, which can make replies worse and slower.

Fix: reduce how much history OpenClaw sends

Add a small history limit (Discord is a group chat):

{
  messages: {
    groupChat: { historyLimit: 10 } // try 5–15
  }
}

#

Also do a fresh session once:

send /new in the chat, then try again

2) `POST /v1/chat/completions -> 500` after ~50s + “downloading … stalled”

On a 5600G + 16GB RAM (CPU-only), llama3 can be slow, and if Ollama is also still downloading/pulling blobs (that download.go line), requests can time out / fail.

Fixes

Make sure the model is fully downloaded (this matters a lot):

ollama pull llama3:latest

Wait until it finishes without “stalled; retrying”.

Reduce response length so it returns faster:

#

  models: {
    providers: {
      ollama: {
        models: [
          { id: "llama3:latest", name: "llama3", contextWindow: 4096, maxTokens: 256 }
        ]
      }
    }
  }
}

If it’s still “too slow”: that hardware will struggle with big prompts + an agent framework.
The realistic options are:

use a smaller model in Ollama (much faster on CPU), or
use a cloud model for OpenClaw (best UX), or

#

run Ollama on a machine with a real GPU.

If you paste the OpenClaw log lines around the 500 (openclaw logs --follow), I can tell whether it’s a true Ollama crash vs a timeout/cancel.

hoary gulch Feb 14, 2026, 3:20 PM

#

can i limit process like gpu 30% and cpu 50% use only or core warp like

#

i am using llama3.2:1b

#

it fast but still my destop lag in response

vagrant boughBOT Feb 14, 2026, 3:22 PM

#

You can’t really tell OpenClaw/Ollama “use exactly 30% GPU and 50% CPU” in a precise way.

Also on your Ryzen 5600G setup: Ollama is basically CPU-only (your logs show total vram="0 B"), so there’s no meaningful “GPU 30%” to cap.

What you can do is cap CPU usage indirectly:

Option A (best on Windows): set CPU affinity + lower priority for `ollama.exe`

This limits how many cores Ollama is allowed to run on (closest thing to “50% CPU”).

In Task Manager

Task Manager → Details tab → right-click ollama.exe →

Set affinity… (pick e.g. 6 of 12 logical CPUs ≈ ~50%)
Set priority… → Below normal

With PowerShell (temporary; resets after restart)

Example: use first 6 logical CPUs and lower priority:

#

$p = Get-Process -Name ollama
$p.PriorityClass = "BelowNormal"
$p.ProcessorAffinity = [IntPtr]0x3F   # 0x3F = binary 111111 = first 6 logical CPUs

If you want ~50% on a 12-thread CPU, another common mask is first 6 threads like above. (Mask depends on how many logical CPUs you have.)

If you need it to persist across reboots/restarts, use a tool like Process Lasso (it can “always” enforce affinity/priority).

Option B: reduce workload (often better than throttling)

Throttling makes it even slower; better is to make each request cheaper:

Use a smaller model (big speedup on CPU)
Reduce OpenClaw history so prompts don’t blow up (prevents truncation + slows less):

#

  { messages: { groupChat: { historyLimit: 10 } } }

Limit output tokens (maxTokens) in your model entry (shorter responses return faster)

Option C: hard CPU caps (advanced)

Windows doesn’t have a great built-in “cap at 50% CPU” per process. You can do it via:

third-party tools (Process Lasso), or
running Ollama inside WSL2/Docker and using cgroup limits (more setup)

If you tell me whether you want the cap to be temporary (just right now) or permanent (always), I’ll give you the cleanest setup for that.

#

If you’re using llama3.2:1b, make sure OpenClaw is actually pointing at that exact model ID (including the tag), otherwise it might still be calling llama3 / llama3:latest and you’ll keep seeing truncation / timeouts.

1) Verify the exact name Ollama exposes

Run:

ollama list

You should see something like llama3.2:1b (exact spelling matters).

2) Point OpenClaw at the exact model

In chat (quickest):

/model ollama/llama3.2:1b

Or in config (~\.openclaw\openclaw.json), set:

#

{
  agents: {
    defaults: {
      model: { primary: "ollama/llama3.2:1b", fallbacks: [] }
    }
  },

  // important if the 1b model doesn’t support tool-calling:
  tools: { deny: ["*"] },

  // helps avoid prompt truncation + keeps it fast
  messages: { groupChat: { historyLimit: 10 } }
}

Then restart:

#

openclaw gateway restart

3) If you still see “truncating input prompt limit=4096”

That’s Ollama saying your context window is 4k. The easiest way to avoid it is:

do /new to start a fresh session
keep historyLimit low (5–10)

(You can increase context via an Ollama Modelfile PARAMETER num_ctx ..., but on CPU it can get slower and use more RAM.)

One more check: after restart, openclaw models status should show:

Default: ollama/llama3.2:1b

If it still shows ollama/llama3:latest, paste that output and your ollama list line and I’ll point out the mismatch.

#

That’s expected on a Ryzen 5600G: even a 1B model can make the desktop feel laggy because Ollama will happily use all CPU threads + lots of RAM bandwidth, and your iGPU shares system RAM with the CPU. When the model is generating, Windows UI can “stutter”.

Best fixes (in order):

1) Limit Ollama to fewer CPU threads (biggest improvement for desktop smoothness)

Easiest: Task Manager

Task Manager → Details → right‑click ollama.exe →

Set affinity… → select e.g. 8 of 12 logical CPUs (leave some for Windows)
Set priority… → Below normal

This keeps Windows responsive while Ollama runs.

2) Also limit OpenClaw concurrency (so it won’t start multiple runs)

In ~\.openclaw\openclaw.json:

#

{
  agents: {
    defaults: {
      maxConcurrent: 1
    }
  }
}

Restart:

openclaw gateway restart

3) Reduce prompt size (less CPU + less lag)

#

{
  messages: { groupChat: { historyLimit: 10 } }
}

And start fresh once with /new.

4) If you want it “always enforced”

Use Process Lasso (it can permanently pin affinity + priority for ollama.exe).

If you tell me how many logical CPUs Windows shows for you (it should be 12 on 5600G) and how much lag you can tolerate, I can suggest a good affinity setting (like 6/8/10 threads).

hoary gulch Feb 14, 2026, 5:49 PM

#

intead of ollama i did with gemini apikey but i get again same problme

17:42:17 [agent/embedded] embedded run agent start: runId=5a82abb0-d46d-4e66-a2ea-39c129b50f56
17:42:17 [ws] → event agent seq=6 clients=1 run=5a82abb0…0f56 agent=main session=main stream=lifecycle aseq=1 phase=start
17:42:17 [agent/embedded] embedded run agent end: runId=5a82abb0-d46d-4e66-a2ea-39c129b50f56
17:42:17 [ws] → event agent seq=7 clients=1 run=5a82abb0…0f56 agent=main session=main stream=lifecycle aseq=2 phase=end
17:42:17 [ws] → event chat seq=8 clients=1
17:42:17 [agent/embedded] embedded run prompt end: runId=5a82abb0-d46d-4e66-a2ea-39c129b50f56 sessionId=c4d11f6b-d790-4a0d-ac7a-a4adb3cd014f durationMs=580
17:42:17 [diagnostic] session state: sessionId=c4d11f6b-d790-4a0d-ac7a-a4adb3cd014f sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
17:42:17 [diagnostic] run cleared: sessionId=c4d11f6b-d790-4a0d-ac7a-a4adb3cd014f totalActive=0
17:42:17 [ws] ⇄ res ✓ chat.history 17ms id=dc6dd975…f925
17:42:17 [agent/embedded] embedded run done: runId=5a82abb0-d46d-4e66-a2ea-39c129b50f56 sessionId=c4d11f6b-d790-4a0d-ac7a-a4adb3cd014f durationMs=872 aborted=false
17:42:17 [diagnostic] lane task done: lane=main durationMs=875 active=0 queued=0
17:42:17 [diagnostic] lane task done: lane=session:agent:main:main durationMs=881 active=0 queued=0
17:42:20 [ws] ⇄ res ✓ node.list 1ms id=46626719…126f
17:42:22 [ws] → event tick seq=9 clients=1 dropIfSlow=true
17:42:23 [ws] → event health seq=10 clients=1 presenceVersion=2 healthVersion=4
17:42:25 [ws] ⇄ res ✓ node.list 1ms id=2dbf9530…4500
17:42:30 [ws] ⇄ res ✓ node.list 0ms id=26bb3bf0…7e7c
17:42:36 [ws] ⇄ res ✓ node.list 0ms id=ebed89fc…211b
17:42:41 [ws] ⇄ res ✓ node.list 1ms id=1e6edfc6…cbd9
17:42:46 [ws] ⇄ res ✓ node.list 0ms id=8b6ae8ca…280e
17:42:50 [ws] ⇄```

vagrant boughBOT Feb 14, 2026, 5:51 PM

#

Those log lines (embedded run agent start → end in < 1s, no model request logged) usually means OpenClaw didn’t actually call the model — it bailed early (most commonly: key not picked up by the Gateway service, wrong provider/model name, or “model not allowed”).

For Gemini API key the provider is google and the env var is GEMINI_API_KEY.

1) Make sure the Gateway service can actually see your Gemini key (Windows)

If you only set the key in your PowerShell session, the Gateway (running as a service) often won’t inherit it.

Run:

openclaw config set env.GEMINI_API_KEY "YOUR_KEY_HERE"
openclaw gateway restart
openclaw models status

In openclaw models status you should see Google/Gemini as available (some line indicating the google provider has a key). If it still shows no Google creds, the key isn’t being picked up.

#

2) Ensure you’re using a Google model id (not “gemini/…”)

Set the model explicitly (either in chat or config). Example:

openclaw config set agents.defaults.model.primary "google/gemini-3-flash-preview"
openclaw config set agents.defaults.model.fallbacks "[]" --json
openclaw gateway restart

(You can also do this in chat with /model ....)

3) If it still “runs” but no reply: grab the real error line

Turn on debug logs temporarily:

openclaw config set logging.level "debug"

#400 error

Recommended fix (simplest)

If you want to keep explicit config

Next step to pinpoint the exact cause

1) First: confirm Ollama itself accepts a minimal OpenAI request

2) If the minimal request works, but OpenClaw still gets 400

3) Best-practice Ollama setup for OpenClaw

Quick confirmation (fastest)

If you want to confirm directly against Ollama

Best “real” fix (recommended)

One more thing: paste the OpenClaw-side error

Fix 1: Make the configured model unambiguously Ollama (and no fallbacks)

Fix 2: Your Discord thread may still be “pinned” to Anthropic

After this, if you again see 400 in Ollama logs

Your tools.deny is in the wrong place, so OpenClaw is probably still sending tools to Ollama

Fix: move it to top-level

Why you still see 200 sometimes

If you still get 400 after moving tools.deny

1) truncating input prompt limit=4096 … prompt=5616

Fix: reduce how much history OpenClaw sends

2) POST /v1/chat/completions -> 500 after ~50s + “downloading … stalled”

Fixes

Option A (best on Windows): set CPU affinity + lower priority for ollama.exe

In Task Manager

With PowerShell (temporary; resets after restart)

Option B: reduce workload (often better than throttling)

Option C: hard CPU caps (advanced)

1) Verify the exact name Ollama exposes

2) Point OpenClaw at the exact model

3) If you still see “truncating input prompt limit=4096”

1) Limit Ollama to fewer CPU threads (biggest improvement for desktop smoothness)

Easiest: Task Manager

2) Also limit OpenClaw concurrency (so it won’t start multiple runs)

3) Reduce prompt size (less CPU + less lag)

4) If you want it “always enforced”

1) Make sure the Gateway service can actually see your Gemini key (Windows)

2) Ensure you’re using a Google model id (not “gemini/…”)

3) If it still “runs” but no reply: grab the real error line

After this, if you again see `400` in Ollama logs

Your `tools.deny` is in the wrong place, so OpenClaw is probably still sending `tools` to Ollama

If you still get 400 after moving `tools.deny`

1) `truncating input prompt limit=4096 … prompt=5616`

2) `POST /v1/chat/completions -> 500` after ~50s + “downloading … stalled”

Option A (best on Windows): set CPU affinity + lower priority for `ollama.exe`