Best Ollama Models for OpenClaw: Tested for Tool Calling

The best local model for OpenClaw is the one that completes your tool workload reliably within your hardware budget. Chat fluency is not enough: an agent model must emit the right tool, valid parameters, and a clean recovery after failure.

Current publication status

This page was converted from an unsourced recommendation list into a reproducible qualification protocol. We will not label a model “94% successful” until the raw run data, prompts, hardware, quantization, OpenClaw version, and scoring script can be published together.

That means there is no fabricated winner table here. The guidance below is verified; scored model results remain pending a repeatable lab run.

Non-negotiable setup

OpenClaw uses Ollama’s native API:

http://localhost:11434

Do not configure http://localhost:11434/v1. The official OpenClaw integration warns that the OpenAI-compatible endpoint can break tool calling and surface raw tool JSON as ordinary text.

Discover candidates with:

openclaw models list --provider ollama

Guided setup offers an installed model automatically only when Ollama reports tool support and at least a 16K context window. That is a sensible first qualification gate, not a guarantee of good agent behavior.

The test suite

Each candidate should run the same seeded tasks in a clean session.

Tool use

1. Read one known file and report a checksum-like fact.
2. Write a file at an explicitly permitted path.
3. Run a harmless shell command with one parameter.
4. Search a supplied local document set.
5. Chain read → transform → write.
6. Recover from one invalid parameter without looping.

Agent behavior

• Correct tool selection
• Valid parameter schema
• Task completion
• Wrong-tool rate
• Repeated-call or loop rate
• Recovery after tool error
• Unsupported claim rate

Record the environment

Field	Why it matters
Exact model tag	Tags and quantizations can behave differently
Hardware	CPU, GPU, and Apple unified memory affect latency
RAM / VRAM	Determines headroom and context behavior
Ollama version	Provider behavior changes
OpenClaw version	Tool schemas and runtime policy change
Context setting	Large context can alter speed and memory pressure
Runs per task	One lucky run is not a benchmark

Score the result

Use at least 20 runs per task class before drawing a directional conclusion; use more for a publishable comparison. Keep task-completion scoring separate from latency.

tool_success_rate = successful_tool_tasks / attempted_tool_tasks
parameter_error_rate = invalid_parameter_calls / total_tool_calls
loop_rate = runs_exceeding_call_limit / total_runs

A fast model with a high wrong-tool rate is not “best for agents.” A slower model may also be unacceptable for an interactive channel. Publish both dimensions.

A practical starting class

For 8 GB hardware, test compact 3–4B tool-capable models and expect limitations. At 16 GB, current 7–8B tool-capable models are a practical starting point. At 24–32 GB, compare 8–14B candidates. With 32 GB or more, you can evaluate larger 14–32B classes—but the largest model is not automatically the most reliable.

Use the Model Finder to narrow the class, then run the protocol above on exact tags available in your environment.

Expected result

A qualified model appears in the Ollama provider inventory, completes the full task set without raw tool JSON, stays within memory limits, and has an error profile you are willing to operate. Until those results are recorded, call a model a candidate—not a winner.