RoloClaw
Guide Blog Get the starter system
← Back to blog
Models14 min readUpdated March 2026

Best models for OpenClaw (2026): an opinionated stack that stays useful

The best model stack for OpenClaw is not the smartest demo you can build. It is the one you can afford to keep using every day without turning the system into an expensive habit you eventually abandon. That means routing, not just picking.

Quick answer

The minimum viable stack for most operators: phi4-mini or llama3.2 (local, via Ollama) for background work, Claude Haiku 3.5 for standard day-to-day tasks, and Claude Sonnet 4 for reasoning and important outputs. Three models, clear routing rule, 95% of real operator work covered.

Why the question matters more than the answer

Most people approach the model question wrong. They look for "the best model" as if there is one right answer, when the actual question is: "which model is right for which job in my specific setup?"

The reason this matters: OpenClaw runs many different types of tasks daily. A morning brief. A document summary. A complex research synthesis. A quick message draft. A strategic planning session. These jobs have wildly different quality requirements and very different cost profiles.

Using a $1.00-per-thousand-token model for a morning brief that could run on a $0.01 model produces identical output at 100x the cost. Do that for every recurring task and OpenClaw becomes an expensive habit that feels hard to justify. The setup eventually gets abandoned not because it stopped being useful but because the bill kept climbing.

The goal is a routing system, not a single best model. Expensive intelligence for expensive jobs. Cheap intelligence for cheap jobs.

The four-tier model framework

Every OpenClaw operator should think about models in four tiers:

Tier 1 — Background

Heartbeats, summaries, brief generation, formatting, classification. Fast, cheap or free. Should handle 40–50% of daily activity.

Tier 2 — Standard

Day-to-day Q&A, message drafts, research summaries, routine writing. Good quality, low cost. Should handle another 30–40%.

Tier 3 — Reasoning

Strategy, complex drafts, synthesis, planning, code review. Medium cost, noticeably better reasoning. Use selectively.

Tier 4 — Critical

High-stakes decisions, deep research, multi-step planning where quality changes outcomes. Expensive — use sparingly.

The target distribution: Tiers 1 and 2 handle 80% of daily activity. Tier 3 handles most of the rest. Tier 4 is occasional. If your usage pattern looks different — if Tier 3 or 4 is handling most of your daily load — you have a routing problem, not a model problem.

The full model routing table (2026)

Job Best model Tier
Morning brief generationphi4-mini or llama3.2:3b (local)1
Heartbeat checksphi4-mini (local) or Claude Haiku 3.51
Document summaryllama3.2 (local) or Claude Haiku 3.51–2
Classification and routingphi4-mini or llama3.2 (local)1
Message draftingClaude Haiku 3.5 or llama3.22
Research synthesisClaude Haiku 3.5 or GPT-4o-mini2
Weekly review / recurring reportsClaude Haiku 3.52
Coding tasksqwen2.5-coder:14b (local) or Claude Sonnet 42–3
Content drafts (important)Claude Sonnet 43
Strategy and planningClaude Sonnet 43
Complex multi-step reasoningClaude Sonnet 4 or Claude Opus 43–4
High-stakes decisionsClaude Opus 44

The minimum viable 3-model stack

You do not need to implement all four tiers immediately. Most operators start with three models and expand from there:

Local — phi4-mini

Fast, free (via Ollama), private. Best for: heartbeats, brief generation, summaries, and classification. Runs well on Mac mini M2/M4. No API cost.

Cloud cheap — Claude Haiku 3.5

Low cost, strong instruction following. Best for: day-to-day Q&A, message drafts, research summaries, recurring reviews. The workhorse of most setups.

Cloud smart — Claude Sonnet 4

Strong reasoning, good writing. Best for: strategy, planning, complex synthesis, important drafts. Use when quality clearly matters for the output.

This three-model stack covers 95% of real operator workflows. Add Tier 4 (Claude Opus 4 or similar) only when you regularly encounter tasks where Sonnet is clearly insufficient.

Local models: when they belong in the stack

Local models (run on-device via Ollama) have become genuinely practical in 2026 for OpenClaw operators with Apple Silicon hardware. The key advantages:

Zero cost per token: once the model is downloaded, inference is free. This is the most cost-efficient path for high-frequency background jobs.
Privacy: memory files, system prompts, and sensitive business context never leave the machine. No inference provider sees your data.
Speed on Apple Silicon: a 14B model on an M4 Mac mini runs at 40–60 tokens per second — fast enough for real-time interactive use, not just batch jobs.
Offline capability: local models work without internet. Cloud API access issues do not bring down background workflows.

The best local models for OpenClaw in 2026:

phi4-mini: best for background work — heartbeats, brief generation, summaries, formatting. Extremely fast and light. Requires very little RAM.
llama3.2 (3B or 8B): good general-purpose tier. Stronger than phi4-mini for Q&A and light drafting. Runs well on 16GB.
qwen2.5-coder:14b: best local model for coding tasks in 2026. Competes with cloud models at the Haiku/GPT-4o-mini tier for many coding jobs.
llama3.3:70b: best local model for reasoning (requires 24GB+ RAM). Suitable for overnight batch jobs or memory consolidation. Slow for interactive use.
gemma3:12b: solid general-purpose option for operators who want a different model family. Good balance of speed and quality.

Practical rule for local model use: if a job runs more than 2–3 times per day, it is a candidate for a local model. If it runs occasionally and quality matters, use a cloud model.

For a deeper comparison, read the hosted vs local models guide.

The cost control rule

Once the routing table is set, cost control mostly takes care of itself. But there is one additional rule worth having:

Set a hard monthly spending cap on every AI provider account. Not a soft guideline — an actual hard limit in the provider's billing settings. This prevents runaway costs from automations behaving unexpectedly.

Suggested caps by usage level:

Light use (briefs, summaries, occasional research): $50/mo cap
Moderate use (research agents, content pipelines): $150/mo cap
Heavy use (multiple agents, frequent reasoning tasks): $300/mo cap

Set the cap at 30–50% above your typical monthly spend so you have headroom for legitimate spikes without hitting a hard wall on a busy week.

The other common cost drain: automations nobody reads. A workflow that runs every 30 minutes and produces output you skim or ignore is costing money with no return. Review your automations monthly and kill anything that isn't changing what you do.

Common model stack mistakes

Using the most expensive model as the default: this is the single most common mistake. The expensive model becomes the default and every routine task — briefs, summaries, heartbeats — runs at premium cost. Route explicitly.
Adding too many models too fast: five or six configured models with unclear routing rules creates confusion. Start with three. Expand only when a specific job demonstrates need.
Rebuilding the stack every time a new model drops: new models appear constantly in 2026. Chasing every new release is expensive and destabilizing. Set a quarterly review schedule and change only when there is a clear job-specific reason.
Using Tier 4 as a crutch for unclear prompts: if a cheaper model keeps failing a task, the first fix to try is improving the prompt or context, not escalating to a more expensive model. Often the problem is vague instructions, not insufficient intelligence.
Not setting spending caps: an automation with a bug can loop and generate significant API cost before you notice. Caps are not just budgeting — they are an important safety net.

How to evaluate a new model for a specific job

When a new model is announced and you want to know if it belongs in your stack, test it against four things in order:

Format compliance: does it follow output structure instructions consistently? A model that keeps breaking your briefing format is not worth using for briefs regardless of raw intelligence.
Instruction following: does it do what you asked without drifting, embellishing, or adding unrequested content? Instruction-following matters more than raw reasoning for most recurring workflows.
Quality at the specific task: is the output actually good enough for this job? Not "impressive in a demo" — good enough that you would use it in real work.
Cost/quality ratio: could a cheaper model do the same job acceptably? If you cannot tell the difference in output quality between a $0.01 model and a $1.00 model for a given task, use the $0.01 model.

Read this next

Hosted vs local modelsThe full comparison — when local models are worth the setup complexity and when they are not. Full setup guideMachine choice, model stack, memory, and channels — the complete practical path. Mac mini vs VPSWhich machine to run local models on, and when a VPS makes more sense. Best use casesWhich jobs benefit from the smart model and which are fine with local or cheap cloud.

Want the complete model routing system in one place?

The RoloClaw starter system includes the full model routing defaults, cost control rules, and practical stack guidance so you do not have to figure it out from scattered sources.

Best for: operators who want clear routing rules and cost discipline from day one instead of discovering expensive habits three months later.
You get: opinionated model defaults, a routing table shaped for OpenClaw workflows, and the memory + workflow context that makes model choices easier to trust.
Why buy: the real cost is not the guide. It is the API bill from routing everything to expensive models before figuring out the routing rule on your own.
Hosted vs local models → Full setup guide → OpenClaw use cases →

FAQ

What is the best model for OpenClaw in 2026? The best setup is a 3-model stack: phi4-mini or llama3.2 (local, via Ollama) for background jobs, Claude Haiku 3.5 for standard day-to-day work, and Claude Sonnet 4 for reasoning and important outputs. Most operators do not need more.
Should I use Claude Opus or GPT-4o for OpenClaw? Only for high-stakes outputs where quality clearly changes the outcome — strategy, complex synthesis, important long-form writing. Using them for routine work makes OpenClaw expensive and fragile.
Can I use local models with OpenClaw? Yes. Ollama runs local models on a Mac mini or capable desktop. phi4-mini is best for fast background work, qwen2.5-coder:14b for coding, llama3.2 for general-purpose standard tasks. All are free per-token and private.
How many models should an OpenClaw setup use? Start with three: one local model for background work, one cheap cloud model for standard tasks, and one smart cloud model for reasoning. That covers 95% of real operator workflows.
How do I keep OpenClaw model costs under control? Route background jobs to local or cheap models. Reserve the smart model for decisions where quality matters. Set a hard monthly spending cap on every AI provider account.
What is the best Claude model for OpenClaw? Claude Haiku 3.5 for standard day-to-day tasks. Claude Sonnet 4 for reasoning, strategy, and complex writing. Claude Opus 4 for genuinely high-stakes decisions only.
What local model is best for OpenClaw? phi4-mini for heartbeats, summaries, and brief generation. qwen2.5-coder:14b for coding. llama3.2 for general-purpose standard-tier tasks. All run via Ollama on Apple Silicon Mac mini.