OpenClaw (previously known as Moltbot and Clawdbot) is one of the hottest open-source projects of early 2026. It’s a personal AI agent that lives on your computer and can actually do things for you such as browse the web, manage files, send messages, check your calendar, and more.
Soon after the initial setup, a practical question arises for most of the users: what does it actually cost to run, and how isolated is my data? The software itself is free, but that’s not the whole story. You still have to account for the API fees that can accumulate pretty quickly.
This guide breaks down OpenClaw’s real-world LLM costs and shows you how to reduce them using SaladCloud. We’ll cover why API costs get out of control, the economics of different deployment models, and practical strategies to cut your bills. With self-hosting your models, you also gain stronger data privacy, if you grant OpenClaw elevated permissions, it may pull sensitive information from third-party services or your local machine that you wouldn’t want sent to an external API provider.
What Is OpenClaw?
At its core, OpenClaw is a self-hosted, open-source personal AI agent. You run it on your own machine: Mac, Windows (with WSL2), or Linux. You can also run it inside a Docker container, which adds an important security boundary by isolating execution, reducing exposure of local credentials, and creating a controlled environment where experiments don’t affect your main system.
What makes OpenClaw different from a regular chatbot is that it can act, not just chat. It’s built to be an agent with access to your system. According to the official documentation, its main capabilities include:
Full system access. It can read and write files on your computer and run terminal commands.
Browser control. It can go online, browse websites, and fill out forms autonomously.
Chat integration. It connects directly to WhatsApp, Telegram, Slack, Discord, Signal, iMessage, and more, letting you interact with it from the platforms you already use.
Persistent memory. It learns from your conversations, building a personalized understanding of your needs and preferences over time.
Proactive heartbeat. You can configure it to perform tasks on a schedule such as sending morning briefings, checking your calendar, monitoring your inbox, or surfacing anything that needs your attention.
The key concept to understand is that OpenClaw isn’t the “brain.” It’s the framework that connects to a powerful AI model of your choice. You can plug it into models like Anthropic’s Claude 4.5, OpenAI’s GPT-5, or run self-hosted open-source models on local or remote machines. This decision shapes the agent’s intelligence and, more importantly, its operational cost.
The Cost Problem: OpenClaw Is Free, But LLMs Are Not
Here’s the catch that surprises most new OpenClaw users: the software is completely free and open-source, but the AI models it relies on are not. When you use OpenClaw with cloud API providers like Anthropic or OpenAI, you’re paying per token – every input you send and every response you get back.
What Is a Token?
Tokens are the basic units that language models process. Think of them as the chunks the AI uses to understand and generate text. They’re not exactly words – a token might be a complete word like “hello,” a word fragment like “un”, a punctuation mark, a space, or a special character. For English, a rough rule of thumb is that one token equals about four characters, or roughly three-quarters of a word. This varies across languages and content types.
The Main Reasons OpenClaw Burns Through Tokens
The model you will see in most of the OpenClaw tutorials is Claude Opus 4.5 which represents the premium tier at $5 per million input tokens and $25 per million output tokens. But raw pricing is only part of the story. OpenClaw’s architecture amplifies token usage in several specific ways:
1. Context accumulation. Every time you chat with OpenClaw, the entire conversation history is saved in JSON files within .~/.openclaw/agents/<agentId>/sessions/sessions.json. With every new request, OpenClaw sends the full session transcript to the model. In that case tens of thousands of tokens can be consumed with every request sent. The same accumulation happens during multi-round reasoning for complex tasks, where each round carries an increasingly large context.
2. Tool output storage. When OpenClaw runs commands or reads files, the entire output gets stored in the session transcript. A single directory listing or config schema dump can inject tens of thousands of tokens into your context that get resent with every subsequent message.
3. System prompt overhead. OpenClaw assembles a complex system prompt on every API call that includes workspace files, tool definitions, and skill metadata.
4. Heartbeat overhead. OpenClaw’s Heartbeat feature wakes the agent every 30 minutes by default. Each heartbeat is a full API call carrying the complete session context. At 48 heartbeats per day with a moderate context window, that’s millions of tokens daily for checking whether anything needs attention.
5. Sub-agent spawning. When your main agent delegates work to sub-agents for parallel processing, each sub-agent also consumes tokens using your primary model unless you configure it otherwise.
6. Poor model selection for simple tasks. Using Opus for a heartbeat check is, as one guide put it, “like hiring a lawyer to check your mailbox.”
In practice, many users report their first month’s bill exceeding $200-500 with Claude Opus 4.5, with heavy users hitting $1,000 or more as their workflows mature. Misconfigured heartbeats alone can burn through $50 in a single day. One user reported 5.7 million tokens consumed overnight – most of it from heartbeats and scheduled tasks they’d forgotten were running. These aren’t edge cases, they’re the natural result of an always-on agent architecture where every interaction, every background check, and every sub-agent task multiplies your per-token spend. So how to can you avoid this?
Strategy 1: Run OpenClaw’s Brain on SaladCloud
The most impactful cost reduction comes from switching from pay-per-token API calls to a flat hourly rate for GPU compute.
Why SaladCloud?
SaladCloud is the world’s largest distributed GPU cloud, powered by thousands of individual nodes across 190+ countries. SaladClouds model allows to offer pricing that dramatically undercuts traditional cloud providers:
| GPU | SaladCloud (Batch) | Closest Competitor |
|---|---|---|
| RTX 4090 (24GB VRAM) | $0.16/hr | over $0.20 |
| RTX 3090 (24GB VRAM) | $0.09/hr | over $0.20 |
| RTX 5090 (32GB VRAM) | $0.25/hr | over $0.69 |
Additional cost advantages include no data ingress or egress fees, no cold start billing (you only pay once your container reaches a running state), pay-as-you-go with no prepaid contracts, and the ability to start and stop deployments on demand or on schedule.
The Key Difference: Hourly Compute vs. Per-Token Billing
When you deploy an LLM on SaladCloud, you pay for compute time not for tokens. That means you can generate as many tokens as you want and only pay for how long your machine is running. Every cost amplifier described above – context growth, heartbeats, sub-agents, system prompts stop affecting your bill. Your cost is fixed and predictable. When you’re not using OpenClaw, simply stop the deployment or let scheduled autoscaling scale it down to zero.
How to Deploy an LLM on SaladCloud
SaladCloud provides ready-to-deploy recipes for the three most popular LLM inference servers: Ollama, vLLM, and TGI (Text Generation Inference). Each serves models via an OpenAI-compatible /v1/chat/completions endpoint, so they all work with OpenClaw’s openai-completions API mode. The choice between them depends on your model and performance needs.
To deploy any recipe, go to the SaladCloud Portal, click Deploy a Container Group, and choose from the available recipes. Every recipe asks you to configure similar core parameters:
- Model name: Which model to serve (e.g.,
llama3.1,qwen3:14b,meta-llama/Llama-3.1-8B-Instruct,Qwen/Qwen2.5-7B-Instruct). - Hugging Face Token: Optional but required for gated or private models on Hugging Face (like Llama).
- Replicas: How many instances to run. Recipes default to 3 replicas. For single-user OpenClaw setups with fallbacks configured, one replica can be enough. Larger replica counts are recommended for better reliablility, shared and production workloads.
- Authentication: For easier OpenClaw configuration disable authentication on the container gateway.
When you deploy, SaladCloud will find qualified nodes and begin downloading the container image and model weights. Once nodes show a green checkmark in the “Ready” column, your endpoint is live. Your API endpoint URL will appear on the deployment page, looking something like https://vegetable-words-3e487ysdyhfkvjah.salad.cloud.
Choosing Between Ollama, vLLM, and TGI
Ollama is the easiest starting point for OpenClaw. You pick any model from the Ollama library by name, and the recipe handles the rest. The trade-off is that Ollama is designed for simplicity over maximum throughput. Ollama is not optimized for high-concurrency per server, but it’s still great for agent use.
vLLM provides higher throughput through continuous batching, PagedAttention for optimized memory management, and quantization support (FP8, AWQ, GPTQ). TGI (Text Generation Inference by Hugging Face) provides optimized inference for text generation models with features like continuous batching, tensor parallelism, and efficient memory management. Both of those servers might be faster than Ollama, but also need larger GPU’s to handle bigger models.
For more details, see the recipe guides:
Connecting OpenClaw to Your SaladCloud Endpoint
Once your LLM server is running on SaladCloud, you need to tell OpenClaw to use it. Open your config file at ~/.openclaw/openclaw.json and update the models configuration.
Here’s a complete example using Ollama on SaladCloud with GLM-4.7-Flash:
{
"models": {
"providers": {
"ollama": {
"baseUrl": "<https://your-salad-deployment-url.salad.cloud/v1>",
"apiKey": "ollama-local",
"api": "openai-completions",
"models": [
{
"id": "glm-4.7-flash",
"name": "GLM 4.7 Flash",
"reasoning": false,
"input": ["text"],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 128000,
"maxTokens": 8192
}
]
}
}
},
"agents": {
"defaults": {
"model": {
"primary": "ollama/glm-4.7-flash"
}
}
}
}
A few notes on this configuration:
baseUrlshould be the domain name from your SaladCloud deployment page with/v1appended (for the OpenAI-compatible API).apiKeycan be any placeholder value since Ollama doesn’t require a real key.costis set to zero across the board because you’re paying for compute time, not tokens. This also means OpenClaw’s built-in cost tracking won’t inflate your reported spend.reasoningshould be set tofalsefor most models unless they specifically support reasoning/thinking output (like DeepSeek R1). Setting it totrueincorrectly can cause tool-call errors.contextWindowshould match the actual context length of your model. OpenClaw uses this to determine when to trigger compaction.
After saving the config, restart the OpenClaw gateway for changes to take effect:
openclaw gateway restart
Ollama supports running multiple models on a single server. This is useful if you want different models for specific tasks. Simply list additional models in the models array and reference them in your agent configuration. For example, you could run glm-4.7-flash for general conversation and qwen2.5-coder for coding tasks on the same deployment if hardware permits. Keep in mind that running multiple large models concurrently requires enough VRAM to hold them all. For better experience it is recommended to use a separate deployment for each model.
Strategy 2: Smart Multi-Model Routing
Most OpenClaw tutorials only show how to set up the agent with one model. That’s the easy path, but it’s the most expensive one. The fundamental idea is simple: not every task deserves your most expensive model.
The Problem with the Default Configuration
Most configs look like this:
{
"agents": {
"defaults": {
"model": "anthropic/claude-opus-4-5"
}
}
}
There is only one model and everything is sent to it. Heartbeats, sub-agents, simple lookups all of it uses the most expensive model. For a heartbeat that just checks whether your inbox has anything urgent, there’s no need to use the biggest model.
The key is understanding and making the correct model decision for your particular use case. For example, you can use your self-hosted SaladCloud model as the default, and only route to expensive cloud APIs when you actually need them. You can also do it in an opposite way – pass the main flow through a big model and let the smaller self-hosted models do the smaller tasks. Here’s a deployment-ready configuration that shows how to define multiple custom providers each pointing to a different SaladCloud deployment with API fallbacks:
{
"models": {
"providers": {
"ollama": {
"baseUrl": "<https://prune-egg-stp8tels3izgcb61.salad.cloud/v1>",
"apiKey": "ollama-local",
"api": "openai-completions",
"models": [
{
"id": "glm-4.7-flash",
"name": "glm-4.7-flash",
"reasoning": false,
"input": ["text"],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 128000,
"maxTokens": 8192
}
]
},
"ollama-2": {
"baseUrl": "<https://guava-thyme-3rjbiukd7h54hj0z.salad.cloud/v1>",
"apiKey": "ollama-local",
"api": "openai-completions",
"models": [
{
"id": "gpt-oss:20b",
"name": "gpt-oss:20b",
"reasoning": false,
"input": ["text"],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 128000,
"maxTokens": 8192
}
]
}
}
},
"agents": {
"defaults": {
"model": {
"primary": "ollama/glm-4.7-flash",
"fallbacks": [
"ollama-2/gpt-oss:20b"
]
},
"models": {
"ollama/glm-4.7-flash": { "alias": "ollama-glm" },
"ollama-2/gpt-oss:20b": { "alias": "ollama-gpt-oss" },
"google/gemini-3-flash": { "alias": "gemini-flash" },
"deepseek/deepseek-chat": { "alias": "deepseek" }
},
"heartbeat": {
"every": "30m",
"model": "ollama/glm-4.7-flash",
"target": "last",
"activeHours": { "start": "08:00", "end": "23:00" }
},
"subagents": {
"model": "ollama/glm-4.7-flash",
"maxConcurrent": 4,
"archiveAfterMinutes": 60
},
"contextTokens": 100000,
"contextPruning": {
"mode": "cache-ttl",
"ttl": "5m"
},
"compaction": {
"mode": "safeguard",
"memoryFlush": {
"enabled": true,
"softThresholdTokens": 40000
}
}
}
}
}
Here’s what each part of this configuration achieves:
Primary model on SaladCloud. All default interactions use your self-hosted GLM-4.7-Flash model running on SaladCloud with zero per-token cost.
Multiple SaladCloud providers. Notice the two separate providers- ollama and ollama-2, each pointing to a different SaladCloud deployment URL. This is how you run different models on separate container groups (servers) and reference them independently. Each provider gets its own name, and you reference models as provider-name/model-id.
Heartbeats on SaladCloud with active hours. Instead of burning cloud credits every 30 minutes around the clock, heartbeats hit your flat-rate SaladCloud instance spending nothing on top of compute usage. For hours when you do not use your agents, set SaladCloud autoscaler to scale down to 0 and set activeHours in OpenClaw config to only the hours your model runs.
Cloud fallbacks for resilience. If all your SaladCloud deployments are temporarily unavailable (node reallocation, for example), the agent gracefully falls back to Gemini, then DeepSeek.
Config file goes in your home directory: ~/.openclaw/openclaw.json. Save it and restart the gateway.
You can also switch models on the fly without editing your config:
/models #Shows a picker with all your models
/model <model-name> # Switch to your desired model
This gives you real-time cost control. If you are working on something complex that needs deep reasoning, or need to perform a coding task you can just switch to a different model.
Managing Your SaladCloud Deployment
A few practical tips for running your LLM for OpenClaw
Shut Down When Not in Use
Since you pay by compute time, stop the deployment when you’re sleeping or away. You can do this manually from the portal, or automate it by using scheduled scaling.
Right-Size Your GPU
Don’t pay for an RTX 4090 if you’re running a 7B model will Ollama that fits comfortably on a cheaper GPU. Match the GPU to the model’s VRAM requirements.
Choose the Right Model
Not all models are equally suited for OpenClaw’s agent workload. The key requirement is reliable tool calling – OpenClaw relies heavily on function/tool calls to interact with your system, and models that hallucinate tool calls or produce malformed JSON will cause agent errors.
Based on community experience, here are models that work well with OpenClaw on SaladCloud:
For general conversation and agent tasks: GLM-4.7-Flash offers strong tool-calling performance with relatively modest VRAM requirements. Community members have reported excellent results. GLM models also support thinking/reasoning when configured with the appropriate parameters.
For coding tasks: Qwen 2.5 Coder (14B or 32B) and the Qwen 3 Coder series are well-regarded for tool calling and code generation. The 32B variant fits on a single RTX 4090.
For reasoning-heavy tasks: DeepSeek R1 (32B) is another open-source model that provides solid reasoning capabilities.
Minimum size recommendation: For the main model use at least a 14B+ parameter model. Models at 8B parameters and below may hallucinate tool calls, lose context in multi-step tasks, or produce corrupted responses during tool-use sequences. The OpenClaw community has converged on 14B as the minimum for reliable agent behavior.
Important: Use models with a minimum context window of 16K tokens. For comfortable agent operation with tool outputs and conversation history, aim for 32K+ context.
Security Benefits of Self-Hosting
Beyond cost savings, running your LLM on SaladCloud provides meaningful data privacy advantages. When OpenClaw has elevated permissions such as access to your file system, email, calendar, messaging apps it processes a lot of sensitive data. With cloud APIs, every piece of that context gets sent to Anthropic’s or OpenAI’s servers.
By self-hosting your model, the data flows only between your OpenClaw instance and your SaladCloud deployment. Your prompts and responses don’t touch third-party API providers. This is especially relevant for users who connect OpenClaw to services like email, Slack, or financial tools – scenarios where the agent might process information you’d rather not share externally.
Self-hosting also eliminates a prompt injection risk: when OpenClaw processes external content (emails, web pages, documents) through a cloud API, that content is sent to the API provider. With a self-hosted model, external content stays within your infrastructure.
Getting Started
Here’s the quickest path to cutting your OpenClaw costs with SaladCloud:
- Create a SaladCloud account at portal.salad.com.
- Deploy an Ollama recipe – pick a model like GLM-4.7-Flash or Qwen 3.
- Wait for nodes to be ready – look for green checkmarks in the “Ready” column.
- Copy your endpoint URL from the deployment page.
- Update your OpenClaw config at
~/.openclaw/openclaw.jsonusing the configuration examples above. - Validate and restart. Run “
openclaw doctor --fix” to adjust your config if needed, then"openclaw gateway restart“. - Test with a simple message to verify your agent is using the SaladCloud-hosted model. Use
/statusto confirm the active model or /models to see all models available. - Set up the multi-model routing so expensive APIs are only called when you explicitly switch or when SaladCloud is unavailable.
Once it’s working, configure active hours on your heartbeat, enable context pruning, and set up automated start/stop schedules for your SaladCloud deployment. Your wallet will thank you.
