OpenClaw explained: the self-hosted assistant & its model-agnostic seam (and how to control cost)

OpenClaw is the open-source personal AI assistant that went from unknown to the most-starred repository on GitHub in under five months. It is self-hosted, single-user, and answers you through the chat apps you already use. The part almost every write-up skips is the one that matters most for your bill and your control: it is genuinely model-agnostic, and that single seam is where you decide what it costs and who you depend on.

What OpenClaw actually is

OpenClaw is an open-source, self-hosted personal AI assistant with a deliberately playful tagline: your own personal AI assistant, any OS, any platform, the lobster way. It was created by Austrian developer Peter Steinberger, who previously founded PSPDFKit (now Nutrient). What made people pay attention was not the mascot but the trajectory: it became the most-starred software repository on GitHub in under five months, passing well over 340,000 stars as of mid-2026. For reference, that pace far outruns how quickly almost any developer tool has ever gained traction.

The key word is single-user. OpenClaw is not a SaaS chatbot you share with a team. It is a program you run for yourself, on your own machine or a VPS, that connects to the messaging apps you already live in and answers you there. There is one sender it trusts (you), and everything is built around that assumption.

One point of confusion worth clearing up: there is an older, unrelated open-source game engine that also carries the name OpenClaw. This article is entirely about the AI assistant. The canonical repository is github.com/openclaw/openclaw, and there are several lookalike forks and mirrors you should not mistake for the original. As reported context, the assistant was renamed on its way to the current name: an early, Claude-punning name drew a trademark complaint from Anthropic, prompting a rename to Moltbot in late January 2026 and, days later, to OpenClaw.

How the Gateway works

At the center of OpenClaw is a local-first daemon usually called the Gateway. It runs continuously on your hardware, listens on your messaging channels, and routes each inbound message to an agent session. It applies allowlist rules, isolates sessions per sender, and acts as the control plane that everything else hangs off of. Think of it as a hub-and-spoke design: the Gateway is the hub, and the channels, skills and model backend are the spokes.

The reach is the selling point. OpenClaw connects to 20+ messaging channels, including WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Microsoft Teams, Matrix, Feishu, LINE and WeChat, plus a built-in WebChat and a live Canvas for richer output. On top of that sits a skills system backed by a community skills hub (ClawHub). A skill teaches OpenClaw how to combine tools to accomplish a task (check the weather, open a GitHub PR, manage a calendar, browse the web) rather than hard-coding each capability. It can also orchestrate coding-agent workers, running managed background coding sessions with plan approval and worktree isolation.

The model-agnostic seam

Here is the part most articles state and then drop. OpenClaw is model-agnostic in a concrete, documented way. It does not assume OpenAI or any other vendor. Any provider that exposes an OpenAI-compatible API works as a drop-in backend, and you additionally allowlist the exact model name it is permitted to call. That is two knobs: the base URL and the model string.

Because those two knobs are all that binds OpenClaw to a model, you can put an LLM gateway in the middle instead of a raw provider. Set the base URL to a gateway endpoint, hand it one key, and now the assistant can reach hundreds of models through a single seam without you re-plumbing anything on the OpenClaw side. If you have used a Claude Code router to redirect a coding agent to different backends, this is the same idea applied to a life-and-ops assistant. It is also why OpenClaw is a natural fit for people already looking at Ollama alternatives who want hosted models without running their own inference server.

Why one gateway controls cost

An always-on, multi-channel assistant does not make one big LLM call per day. It makes many small ones: routing decisions, skill selection, wake loops that keep it responsive, and coding-agent workers that grind through tasks in the background. Most of those calls are cheap, boring, and constant. A few are the real work you actually care about. If every one of them hits the same expensive frontier model, your bill is dominated by the boring traffic.

The single highest-leverage lever is to route through one OpenAI-compatible gateway and split the work by model. Below is an illustrative, modeled split (numbers are for shape, not a quote) showing how the same daily volume looks when you separate chatty background calls from real work.

The gateway row wins on three counts. You swap a cheap model like DeepSeek V4 Flash for routing and wake loops while reserving something like Claude Opus 4.8 or a coding-tuned Qwen3 Coder Next for the tasks that matter. You get one key, one bill, and usage caps across hundreds of models instead of juggling per-provider accounts. And because the assistant is self-hosted, avoiding lock-in on the model layer keeps the whole stack yours. For choosing which model does the heavy lifting, our guide to the best LLM for AI agents in 2026 goes deeper.

OpenClaw vs Claude Code vs ChatGPT

These three get compared constantly, usually unfairly, because they are built for different jobs. OpenClaw is a broad life and ops assistant that lives in your chat apps and calls whatever model you point it at. Claude Code is a purpose-built coding agent tied to Anthropic models. ChatGPT is a hosted, multi-tenant product you do not self-host. The honest read is that OpenClaw and Claude Code are complementary; OpenClaw can even orchestrate Claude Code as one of its coding workers.

The decision rule is simple. If you want a coding-only agent, use Claude Code. If you want a general assistant you do not have to run, use a hosted product. If you want a private, multi-channel assistant you control end to end and can point at any model, OpenClaw is the one that fits, and it plays well with the other two. The difference between calling models directly and giving your assistant structured tools is worth understanding too; see MCP vs API.

The honest security trade-off

This is where the hype pieces go quiet, so let us be direct. An assistant that has broad tool access and reads untrusted inbound content is a structural risk. Prompt injection has no foolproof defense today in systems that process untrusted content. Combine that with the wide tool permissions the agent needs to be useful, and a malicious email, webpage or message can attempt to trigger data exfiltration, fraudulent actions, or file changes. Security researchers and vendor security teams have documented this pattern repeatedly; it is not hypothetical.

The single-user design amplifies it in a specific way. Because you are the only sender, the agent is often given broad access by default, and many people leave a wide allowlist enabled after testing rather than tightening it. Self-hosting also means the host, the plugin surface, and all local state are your responsibility. The mitigations are unglamorous but real: keep allowlists narrow, treat any channel that can receive messages from strangers as hostile, isolate the host, and do not let a background agent hold credentials it does not need. Running the model layer through a gateway helps here too, because usage caps and a single revocable key limit the blast radius if something does go wrong.

One point of record worth stating plainly. In February 2026, OpenAI CEO Sam Altman confirmed that OpenClaw's creator, Peter Steinberger, was joining OpenAI; the move was widely reported by TechCrunch, CNBC and others, so it is established fact rather than rumor. What OpenAI did not do is absorb the software: OpenClaw is moving to an independent, MIT-licensed open-source foundation that OpenAI supports but does not own. So the self-hosted, model-agnostic story in this article still holds. Be skeptical instead of looser write-ups that describe this as a clean acquisition of the project itself.

How to get started

At a high level there are two paths. The self-hosted path is CLI-first: you install the Gateway on macOS, Linux or Windows, run an onboarding flow, connect at least one messaging channel, and set your model backend. (Exact commands and version requirements change over time, so follow the official docs rather than any blog snippet, including this one.) The managed path uses a service like OneClaw, which provisions a dedicated instance, deploys OpenClaw, loads a template, configures API keys and connects a platform for you. Z.AI also publishes an OpenClaw devpack entry for its GLM models, such as GLM-5.2.

Whichever path you take, the one setup decision worth getting right on day one is the model seam. Set the base URL to an OpenAI-compatible gateway and allowlist two models (one cheap, one strong) from the start. A balanced option like Mistral Medium 3.5 can cover the middle. That way, when you later want to change models, cap spend, or move off a provider, you change one line, not your whole assistant.

FAQ