OpenClaw: What It Is and What It Costs

Part of the reduce AI coding agent token usage pillar. This page is the explainer, with the cost angle that most write-ups skip.

What is OpenClaw?

OpenClaw is a personal AI assistant you self-host on your own devices and talk to through the messaging apps you already use — WhatsApp, Telegram, Discord, iMessage — rather than a terminal or an IDE. It's MIT-licensed, written in TypeScript, and one of the most-starred repositories on GitHub. The framing matters because it determines everything about the cost. A coding agent runs when you open it and stops when you close it. OpenClaw is designed to be present: it has persistent memory, a skills and plugin system, and cron/heartbeat scheduling that lets it act without being prompted. You can absolutely drive coding agents with it — people run Claude Code and Codex through it, and that's one of its main uses — but you're doing so inside something that's always running. Short history, because the naming confuses people: the project started in November 2025 as Clawd, was renamed Moltbot after Anthropic made legal contact over the name, and became OpenClaw on 29 January 2026. It was created by Peter Steinberger, who joined OpenAI in February 2026; stewardship passed to the non-profit OpenClaw Foundation in June 2026.

How do you install and run it?

One command, then an onboarding wizard. There's also a shell installer (curl -fsSL https://openclaw.ai/install.sh | bash), a git source install, and Companion apps for macOS (universal binary) and Windows (x64/ARM64). Onboarding connects a model provider and at least one messaging channel. From there you message it like a contact.

Which models can it use?

Over 60 providers, including local ones — and it accepts subscription sign-in as well as API keys. The provider list spans OpenAI, Anthropic, Google, Azure, Groq, Perplexity, DeepSeek, Qwen and Moonshot, plus local runtimes: Ollama, vLLM and LM Studio. That last group matters for anyone nervous about an always-on assistant metering against a paid API. The subscription option is the more interesting one. OpenClaw can sign in with a ChatGPT or Claude Max account rather than a metered key, which converts a per-token cost into a fixed monthly one with usage limits. For a tool that's designed to run continuously, that's a materially different risk profile — and it's the first thing I'd configure.

Can you use OpenClaw as a coding agent?

Yes, and it's a common way to run it — you message it and it drives a coding agent on your machine. That's where the multi-agent routing matters. Inbound channels, accounts and peers are routed to isolated agents with separate workspaces and per-agent sessions, so a coding task in one workspace doesn't contaminate the context of another conversation. It's a genuinely sensible design for something juggling several jobs at once. Sandboxing is available and worth turning on: agents.defaults.sandbox.mode: "non-main" runs non-main sessions sandboxed, with Docker as the default backend (SSH and OpenShell are also supported). For an assistant that can act on a schedule without you watching, that isn't optional hygiene — it's the difference between a proactive assistant and an unattended process with shell access.

What does OpenClaw cost to run?

The software is free. The tokens are not, and the always-on design is what makes the bill behave differently. There's no product pricing — it's MIT-licensed and self-hosted, so you pay whatever your model provider charges, or nothing at all if you point it at a local runtime. The structural difference from a coding agent is this: with Claude Code or Cursor, you generate cost only while you're working. OpenClaw has heartbeat and cron scheduling, meaning it can wake up, check things and act on its own. Every one of those wake-ups carries context — memory, skills descriptions, conversation history — through a model. A session-based tool bills in bursts you initiate; an always-on assistant bills on a schedule you configured once and probably forgot. That's not a criticism of the design, which is the entire point of the product. It's a warning about the default mental model. If you're used to reasoning about agent cost as "cost per session", that framing doesn't transfer. OpenClaw gives you visibility through a chat command — /usage off|tokens|full — which is genuinely useful for seeing what a conversation consumed. What I could not find in the documentation is a hard spend cap or budget enforcement primitive. Visibility is not the same as a limit, and on a tool that acts unprompted, that gap is worth knowing about before you leave it running.

What do skills and memory add to the standing cost?

They're the part you pay for on every single interaction, whether or not you use them — and unlike a coding session, there's no natural end to that. OpenClaw has a skills and plugin system, with a community catalogue (ClawHub) to install from. The mechanism is the same one Claude Code uses: for the assistant to choose a skill, it has to know the skill exists, so each installed skill's description sits in context from the first message. The full skill content loads only when it's actually invoked — sensible design, and the standing cost per skill is small. Small times a schedule is not small, though. On a coding agent you pay that description cost once per session you initiate. On an assistant with heartbeat scheduling, you pay it on every wake-up, indefinitely. Install thirty skills from ClawHub because they looked interesting and you've quietly added a recurring line item to something that runs whether you're at your desk or asleep. Persistent memory compounds it. Memory is the feature that makes the assistant feel like it knows you, and it works by carrying accumulated context forward. That's the product working correctly — it's also, mechanically, a context payload that grows. The practical version: prune ClawHub installs the way you'd prune browser extensions, and treat "how often does it wake up" as the multiplier on everything above.

The $1.3 million receipt, accurately

The famous number is real but routinely misdescribed, and the details matter if you're drawing lessons from it. In May 2026 Steinberger posted a screenshot of a 30-day API bill: $1,305,088.81, 603 billion tokens across 7.6 million requests. What actually produced it was roughly 100 Codex instances running in the cloud, operated by his team, working on the OpenClaw project — reviewing pull requests, scanning commits, and so on. Three corrections to the version that circulates. It wasn't one person; it was a team. It wasn't OpenClaw agents burning the tokens; it was Codex instances doing development work. And the exact figures come from that screenshot rather than a published statement — press reporting says OpenAI covered the spend, though his own post doesn't say so. His stated rationale is the genuinely interesting part: he was deliberately exploring how you'd build software if tokens didn't matter. That's a legitimate experiment. It is not a benchmark for what normal use costs, and it gets cited as though it were.

How does this fit with token optimisation?

The levers are the same ones that apply to any agent, because the underlying mechanism is identical. The model is stateless. Every turn resends the prior conversation plus whatever was read — files, command output, tool definitions. OpenClaw adds memory and skill descriptions to that standing load, and a schedule that triggers it without you. So the levers stay what they always were: retrieve instead of reading whole files, filter noisy output, read structure before bodies, and don't carry tool manifests you never call. Tokenade works with OpenClaw, alongside Claude Code, Cursor, Codex, Copilot, Windsurf, opencode, Cline, Roo Code, Aider and Hermes — it sits between the agent and its tools and applies those levers automatically. On the open token optimizer benchmark it cuts session cost by 39% on long sessions against running no tool at all. For an always-on assistant, though, I'd do two things before reaching for any tool: sign in with a subscription rather than a metered key, and check what your heartbeat schedule is actually doing. Those two decisions will dominate anything else you tune.

Practical setup checklist

1. Prefer subscription sign-in (ChatGPT or Claude Max) over an API key if you plan to leave it running. Fixed cost beats an open meter on a tool that acts by itself.
2. Turn on sandboxing — sandbox.mode: "non-main" with the Docker backend. An assistant with shell access and a schedule needs a boundary.
3. Audit the cron and heartbeat config. This is the single biggest lever on standing cost, and it's the one people configure once and never revisit.
4. Use /usage full periodically to see what conversations actually consume. There's no spend cap, so the check has to be yours.
5. Consider a local runtime (Ollama, vLLM, LM Studio) for routine, low-stakes tasks. The provider list supports it and it takes the meter out entirely.

---

See also:

• Best AI coding tools — the wider field
• Claude Code alternatives — if you're picking a coding agent to drive
• Peter Steinberger's $1.3M one-month token bill — the full case study
• How to reduce AI coding agent token usage — the tool-agnostic levers