OpenClaw tutorial: getting started with your first assistant

Quick answer: what it actually takes to get OpenClaw running.

OpenClaw is a runtime that lets one AI assistant answer across WhatsApp, Telegram, Discord, and several other messaging platforms from a single process on hardware you control. Getting a first assistant live takes four moves: install the CLI on a machine that already has a recent Node.js runtime, run the built-in onboarding wizard, point the model provider slot at an OpenAI-compatible endpoint with a base URL and a key, and start the gateway process. From there you connect one channel, usually by scanning a QR code or registering a bot token, and the same assistant replies wherever that channel sends a message. Everything past that first hour is tuning: which model answers by default, how much conversation history the gateway keeps in view, and how many channels stay active at once. The runtime itself doesn't carry a license fee. The recurring cost comes entirely from whichever model API answers the messages, billed per token the same way it would be if you called that API directly.

How OpenClaw's runtime actually works.

None of this is tied to one AI vendor. OpenClaw's provider slot speaks the same request format that most model APIs already use, so any endpoint implementing that format, whether it's a model vendor's own API or a gateway sitting in front of several vendors, drops in by changing two values: the base URL and the key. Nothing else about the install changes when the provider does.

• Gateway process: a single service holds the active sessions and forwards each inbound message to whichever model provider is configured, then routes the reply back to the originating channel.
• Channel adapters: dedicated connectors log in to WhatsApp, Telegram, Discord, and other platforms as a bot or a linked device, and translate each platform's message format into one internal shape.
• Memory: a notes file stores what the assistant should carry between sessions, and that file gets read back into context on later turns rather than being summarized away automatically.
• Tool execution: web search, file reads, and similar actions run as extra round trips to the same model, and each one is billed as its own request, not folded into the original reply.
• Model routing: agents.defaults.model declares a primary model ref plus an ordered fallbacks list, and additional allowlisted models can be switched per session with the /model command, so different situations can hit different models without touching anything else in the setup.

Worked example: what a month of OpenClaw traffic costs.

Token volume, not the OpenClaw runtime itself, is what shows up on a bill. Every exchange resends recent conversation history, the active memory notes, and any tool schemas in play, so message count and context size move together rather than independently. The table below estimates a typical exchange at three usage levels and prices a full month of that traffic at three model tiers, from a budget model through a flagship one. Treat the token estimates as planning numbers: memory length, channel count, and how often tools fire will shift your real total up or down. The gap between tiers is the whole point of splitting the routing instead of picking one model for everything. A heavy month on a budget model costs less than a light month on a flagship one, which is why most working installs put a low-priced model in the primary slot and keep the expensive one on the /model allowlist for genuinely hard turns.

Why the install and the bill surprise people.

Two kinds of surprise show up once OpenClaw is running for real: the bill lands bigger than the light demo suggested, or something that worked in testing quietly stops working once nobody is watching the terminal. Both usually trace back to a short list of causes.

• Every active channel resends the same context. Connecting a second or third platform is not free reach; each one is its own live session paying for the same history and memory notes on its own turns.
• Tool calls multiply requests. A question that triggers a web search or a file read becomes two or more model calls instead of one, and the system prompt and tool schemas ride along on each of them.
• The memory file only grows by default. Notes the assistant writes to remember things across sessions get read back into every later turn unless something prunes or summarizes them on a schedule.
• A fresh install can leave the primary model on the flagship id the onboarding wizard suggested, so early testing can run flagship-priced calls for messages a lower-priced model would have handled just as well.
• The gateway is a 24/7 process, not a script that runs once. WhatsApp and Telegram sessions need the host to stay reachable; a laptop that sleeps or a container that restarts quietly drops incoming messages until someone notices.
• A gateway token stops being optional the moment anything is remote. Binding to localhost only is safe by itself, but opening the port without a token or device pairing enabled hands session access to whoever finds it.

OpenClaw next to other assistant runtimes.

OpenClaw is not the only way to wire a model into a chat platform, and the honest comparison is architecture, not a single winner. A self-hosted, single-process runtime trades a bit of setup for full control over data and cost; the alternatives below sit at different points on that same tradeoff.

Fixes that keep an OpenClaw install reliable and affordable.

None of the surprises above require redesigning the install. Each one has a specific, small fix, and most of them take less time than the original setup.

• Set the primary and fallback refs under agents.defaults.model explicitly instead of leaving the wizard's picks in place, so routine replies never land on a flagship-priced model by accident.
• Trim or summarize the memory file on a schedule. Keep only notes that actually change how the assistant behaves, not a running transcript of everything it has ever been told.
• Disable channels you are not actively monitoring. A connected but idle platform still counts as a live session the next time someone messages it.
• Cap how many tool calls one turn can trigger, so a single ambiguous question does not fan out into a handful of billed round trips.
• Keep the gateway bound to localhost and reach it over an SSH tunnel or a real device-pairing token for anything remote, instead of exposing the port directly.
• Size the host to the channel count you actually run, not to OpenClaw's documented minimum; treat that minimum as a demo box, not a 24/7 production one.
• Point the primary model at a lower per-token id through an OpenAI-compatible endpoint, such as APIsRouter, and keep a premium model on the /model allowlist for harder escalations.

Install OpenClaw and wire it to a model provider.

Bring the runtime up in four steps: install the CLI on a machine running a recent Node.js version, run the onboarding wizard to create a workspace and a gateway token, declare a provider pointing at an OpenAI-compatible endpoint, and start the gateway. OpenClaw keeps its configuration at ~/.openclaw/openclaw.json (JSON5, so comments and trailing commas are fine): custom endpoints go under models.providers, and the default agent model references them as provider/model-id. The model ids below come straight from the current catalog, so you can copy the block, export your own key, and swap any id for a different one without touching anything else in the file. The gateway hot-applies model and provider edits on save; run openclaw doctor if a hand edit is rejected.

# Install the OpenClaw CLI (recent Node.js required)
npm install -g openclaw

# Confirm it installed
openclaw --version

# Run the onboarding wizard: creates a workspace, asks for a
# model provider, and generates a gateway token
openclaw onboard --install-daemon

# Start the gateway in the foreground first to watch the logs
openclaw gateway

# Once it comes up clean, run it as a background daemon
openclaw gateway --daemon

FAQ