#OpenClaw Install / Setup

1 messages · Page 1 of 1 (latest)

frosty gulchBOT
#

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

last tapirBOT
#

You’re very close — but right now you’ve got 3 different problems mixed together (install/runtime health, model/tool-calling, and channel policy). The fastest way to get unstuck is to stop reinstalling and run the standard “triage ladder” so we can see exactly what’s failing.

1) Paste this ladder output (redact tokens)

Run these on the Mac mini and paste the full output in a code block:

openclaw --version
node -v
which openclaw

openclaw status --all
openclaw gateway status
openclaw doctor
openclaw channels status --probe
openclaw logs --follow
#

Docs for this exact ladder: https://docs.openclaw.ai/help/troubleshooting

While openclaw logs --follow is running, try one failing thing (send a Telegram DM, or try a tool call in TUI) so the log captures the error.


2) Why “local = unlimited chat but no tools” happens a lot

If you’re using a local model (Ollama/LM Studio/llama.cpp), many are fine for casual chat but unreliable at tool calling (they fail to emit the strict JSON tool calls, or they choke on tool schemas). Result: it “talks” but won’t actually use browser/web/exec tools.

So one key question: Are you trying to use a local model as the main model, or a cloud model?
(If you want, paste openclaw models status too.)

Models overview: https://docs.openclaw.ai/concepts/models
If you want real-time “which model actually calls tools well this week”, ask in #models (it changes constantly).


#

3) Tool calling can be blocked by config (even if the install is fine)

If you (or onboarding) set a tool allowlist, you can accidentally block everything and the assistant will “act dumb”.

Run:

openclaw sandbox explain --json

And paste it. This shows the effective tool policy (allow/deny), sandbox mode, etc.

Tool policy doc (super relevant): https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

Common footgun: tools.allow is non-empty → anything not in it is blocked.


#

4) Telegram failures: usually pairing / allowFrom / privacy mode

Telegram setup is deterministic; it either probes “ready” or tells you why.

Quick references:

Also: if you’re testing in a group, Telegram bots often need privacy mode/admin tweaks (doc covers it).


5) The “200k context burned in 10 min” thing

#

That’s usually one of:

  • a pricey model selected as default, and/or
  • browser/screenshot-heavy tool use (screenshots cost tokens), and/or
  • the agent going “autonomous” on a broad prompt.

We can fix that once we see your openclaw models status + what tools were used in logs. (There’s also a knob for downscaling tool screenshots: agents.defaults.imageMaxDimensionPx in config.)


If you paste the ladder outputs + answer (local model or cloud model?) + (TUI only or Telegram primary?), we can get you to a clean working baseline without another uninstall loop.

granite ibex
#

openclaw: 26.2.26
node:26.14.0
/opt/homebrew/bin/openclaw
openclaw status --all "none"
gateway: loaded and running
doctor --fix, api keys, setting local
channels probe: reachable
openclaw logs: no red errors,

pairing approve for telegram bot, message and "api error 400" does not support tools

ollama launch openclaw: response below

Ollama API error 400: {"error":"registry.ollama.ai/library/qwen:7b-chat-q5_K_M does not support tools"}
gateway connected | idle
agent main | session main (openclaw-tui) | ollama/qwen:7b-chat-q5_K_M | tokens ?/33k

last tapirBOT
#

That error is the smoking gun: your install is basically fine — your current Ollama model flat-out refuses tool/function-calling, so OpenClaw can’t even offer tools to the model.

You’re running:

  • ollama/qwen:7b-chat-q5_K_M
  • Ollama returns: ... does not support tools

OpenClaw sends a tools schema with the request (so the model can call web_fetch, browser, etc.). Ollama rejects that request for models that don’t support tool calling → Telegram + TUI will look “broken” anytime tools are enabled, even if you’re just trying to chat.

Pick one path

Path A (recommended): use a tool-capable model for “agent stuff”

If you want browser/search/files/etc, you need a model/provider that supports tool calling.

Do this to see what OpenClaw thinks you have configured:

#
openclaw models status
openclaw models list

Then in the TUI you can use /model to switch to a tool-capable model that’s actually configured on your machine.

Models docs: https://docs.openclaw.ai/concepts/models

Path B: keep that Ollama model, but accept “chat-only” (no tools)

If you just want unlimited local chat with that Qwen build, disable tools so OpenClaw stops sending any tool schema.

Add this to ~/.openclaw/openclaw.json:

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

That should stop the “does not support tools” 400s — but it also means: no browser, no web_search/web_fetch, no exec, etc.

Tools doc (disabling tools): https://docs.openclaw.ai/tools/index

Path C: local and tools (but not via that Ollama model)

The docs’ “best current local stack” is LM Studio + Responses API (tool-friendly), see:
https://docs.openclaw.ai/gateway/local-models

(Heads up: on a 16GB Mac mini, truly good local agent performance is tough; hybrid “hosted primary + local fallback” tends to be the sane route.)

About the “200k tokens burned in 10 minutes”

That’s usually browser/screenshot-heavy runs. Once you’re on a tool-capable model, you can prevent runaway spend while testing by temporarily denying the expensive UI tools: