Nanobot vs OpenClaw: runtime, providers and operating cost

Choose nanobot if you want one small self-hosted Python process with a single JSON config file; choose OpenClaw if you need a foundation-backed gateway with more chat channels, selectable agent runtimes and first-party spend reporting. Both are MIT-licensed, self-hosted and free to download, so the real decision is the runtime you will operate, the provider block you will hand-write, and the background cadence you will pay tokens for.

Versions checked on September 21, 2026: nanobot v0.3.5, published September 15, 2026, and OpenClaw v2026.9.5, published September 19, 2026. OpenClaw's npm record carried four publishes in the ten days before this check, across its stable and extended-stable lines, so read the release feed and the npm record rather than a version quoted on any comparison page, this one included.

First, check which nanobot you are installing

This page is about HKUDS/nanobot, a Python personal-assistant framework from the Data Intelligence Lab at the University of Hong Kong, with its documentation at nanobot.wiki. Two near-namesakes send buyers to the wrong software:

• obot-platform/nanobot, on nanobot.ai, is a separate Go project under Apache-2.0 for building MCP agents. Its feature claims do not describe the HKUDS assistant.
• The PyPI package named nanobot is an unrelated robotics navigation library. The correct install is pip install nanobot-ai, version 0.3.5, MIT, Python 3.11 or newer per the PyPI record. The quick-start also offers an install script that installs or upgrades the same package.

Forks copying the description and homepage verbatim exist too, and nanobot's deployment guide warns that Docker Hub images under third-party namespaces are not maintained or verified by the project, so do not mount API keys or bot tokens into them unless you trust the publisher. For OpenClaw, the official surfaces are docs.openclaw.ai, openclaw.ai, openclaw.org and the GitHub repository; if you read the config keys below anywhere else, check them against those, because a copy can be stale on exactly those keys.

Who should pick which

Pick nanobot when the workflow is one person, one machine, one config file. Its entire configuration is ~/.nanobot/config.json, with camelCase keys, and its durable state lives in an agent workspace — ~/.nanobot/workspace/ by default — as SOUL.md, USER.md and memory/MEMORY.md, per its memory reference. If you want to understand every moving part before you trust it with a messaging account, a smaller surface is a real advantage. Its own OpenAI-compatible server also makes it a useful backend for other tools, bound to 127.0.0.1 by default and refusing to start on 0.0.0.0 without an API key.

Pick OpenClaw when the workflow is an operated deployment. Its channel catalog lists 32 channels, a few bundled with the core install and most installed as official or external plugins; it separates the agent workspace from the state directory so you can relocate either, and ships usage tracking with /status, /usage cost and openclaw status --usage. It also separates the model reference from the agent runtime, so one deployment can drive an API-key route and a vendor CLI seat side by side.

On the execution and permission model, expect the same work in both. Each keeps a long-running gateway that owns background delivery, and each makes a custom endpoint an explicit trust decision: OpenClaw treats a custom baseUrl as a network-trust grant scoped to that exact scheme, host and port, while metadata, link-local and local-use NAT64 origins stay blocked without an explicit opt-in and other private or CGNAT ranges need request.allowPrivateNetwork: true, which defaults to false.

On cost path, the difference is visibility, not price. Both programs are free. OpenClaw reports session tokens and an estimated cost for API-key sessions and hides per-token dollar estimates for plan-billed sessions. nanobot's WebUI shows a per-round token and cache chart and states plainly that those figures are not a billing statement; there is no aggregated spend command in its CLI reference. Open requests for cost tracking in HKUDS/nanobot, issues #1193 (last updated February 25, 2026) and #2020 (last updated March 16, 2026), are both still open — but do not read those titles as today's feature set, because the per-round display does exist. What is missing is the aggregate.

On migration cost, plan for a rewrite rather than an import. OpenClaw's memory importer covers Codex, Claude Code and Hermes, and neither project documents an importer for the other in either direction. Provider blocks, presets, channel credentials, schedules and memory files are all re-created by hand.

One thing neither choice can rest on: there is no shared benchmark, and neither project publishes task-quality numbers. nanobot's README claims a "small, readable core" but publishes no line count at all, so any specific line-count figure quoted for it elsewhere is not a vendor claim. Code size does not predict task quality in either direction.

nanobot vs OpenClaw at a glance

Star counts measure attention on one day, not maturity or support, and both move daily — read them from the two repositories rather than from a secondary page. On the license row there is a documented disagreement: GitHub's API metadata reports no license assertion for openclaw/openclaw while the LICENSE file carries the MIT text with no trademark or naming clause, followed only by a pointer to THIRD_PARTY_NOTICES.md. Read the file, and confirm it yourself before shipping anything built on it.

The provider config is the real difference

Both clients can call an OpenAI-compatible or an Anthropic-compatible endpoint. They decide which one differently, and that single fact is why a working config cannot be translated between them.

nanobot decides by which provider key you write. Per its provider reference, any key you invent under providers is treated as a direct OpenAI-compatible provider, apiBase is required because nanobot cannot know the endpoint URL, and apiKey is optional. For an Anthropic-compatible gateway you must instead keep the provider as anthropic and override its apiBase: the docs state that arbitrary custom provider names are OpenAI-compatible only and do not use the Anthropic Messages request format. That is the single biggest configuration trap on this comparison.

{
  "providers": {
    "kunavo": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com/v1"
    },
    "anthropic": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com"
    }
  },
  "modelPresets": {
    "openaiShaped": {
      "provider": "kunavo",
      "model": "claude-sonnet-5",
      "maxTokens": 1024
    },
    "anthropicShaped": {
      "provider": "anthropic",
      "model": "claude-sonnet-5",
      "maxTokens": 1024
    }
  },
  "agents": {
    "defaults": {
      "modelPreset": "openaiShaped"
    }
  }
}

Names matter twice here. Avoid colliding with a built-in name such as openai, openai-codex, github-copilot or lm-studio, and do not set apiType on a custom key — that field is only for providers.openai. With an explicitly named custom provider the model id is sent as written, so model must be exactly the id the endpoint expects; only under provider: "auto" is a matching prefix stripped. That override edits the anthropic provider block itself, so the gateway takes the place of direct Anthropic in every preset pointing at that provider rather than sitting beside it. Note also that snake_case keys are accepted for compatibility, but nanobot writes camelCase back to disk.

OpenClaw decides with a field. Its custom-provider reference puts everything in one uniform block under models.providers, where api selects the request adapter from eleven values including openai-completions, openai-responses, anthropic-messages, google-generative-ai, ollama and bedrock-converse-stream. A baseUrl with no api defaults to openai-completions.

{
  "models": {
    "mode": "merge",
    "providers": {
      "kunavo": {
        "baseUrl": "https://api.kunavo.com",
        "apiKey": "${KUNAVO_API_KEY}",
        "api": "anthropic-messages",
        "authHeader": true,
        "models": [
          {
            "id": "claude-sonnet-5",
            "name": "Claude Sonnet 5",
            "input": [
              "text"
            ],
            "contextWindow": 1000000,
            "maxTokens": 1024
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "kunavo/claude-sonnet-5"
      }
    }
  }
}

Adding a model reference under agents.defaults alone does not register it: a matching entry with the same id must exist in models.providers.<id>.models[]. The 1024 above is a deliberately small output cap for a first trial, not the model's maximum; take contextWindow and maxTokens from the model page for whatever model you route. Kunavo has not run either client against its endpoint — these blocks are read from the two projects' own configuration references on September 21, 2026 and need your own bounded trial before you move scheduled work onto them.

What a third-party endpoint cannot reach

Both projects document specific things a custom endpoint loses. These are the parts a price comparison usually skips, and they change what a cheap route actually costs you. The nanobot rows come from its provider reference linked above; the OpenClaw rows come from that same configuration reference plus its custom-provider concepts page, which is where the dropped-header behaviour is written down.

Two consequences are worth planning around. First, on an OpenAI-compatible OpenClaw route to a non-native host the client-side prompt-cache hints are dropped by design, along with service_tier, store and attribution headers; the anthropic-messages route instead loses the implicit beta headers. What that changes is what the client asks for, not by itself whether the endpoint caches — an endpoint that caches on its own side can still cache, and OpenClaw's documentation does not say otherwise. So do not assume either result: verify the returned usage before budgeting a recurring job as cached. Our prompt-caching guide explains what the usage fields should look like when caching is working.

Second, in OpenClaw the runtime matters as much as the provider. The runtime reference resolves the runtime after provider and model resolution and lets you pin one per provider with models.providers.<provider>.agentRuntime: the built-in openclaw runtime runs the prepared turn itself, while codex, claude-cli and copilot execute through vendor backends carrying their own subscription credentials. Whether those backends honour a custom baseUrl is not documented either way, so treat a Kunavo-style key as belonging on the openclaw runtime rather than assuming a CLI backend can be redirected. In nanobot the equivalent boundary is that subscription accounts are their own OAuth providers, signed in with nanobot provider login, and its provider reference notes that OAuth providers are not valid automatic fallbacks; a gateway key inherits none of that. OpenClaw's README states it has no paid tier, hosted service or token, and nanobot's documentation describes no paid tier either, so neither documents a software plan gate.

Operating cost: the software is $0, the cadence is not

nanobot is MIT under its repository license, and OpenClaw's README states it has no paid tier, hosted service or token. Neither publishes a usage benchmark, so anything below is arithmetic from stated assumptions, not a measured result or a bill ceiling.

Take a single assistant handling 30 turns a day for 30 days, assumed at 6,000 uncached input and 400 output tokens per turn — 5.4M input and 360,000 output tokens a month. At current Kunavo catalog rates, Claude Sonnet 5 lists $2.00 per million input and $10.00 per million output tokens, and Claude Haiku 4.5 lists $0.40 and $2.00.

The heartbeat rows use OpenClaw's own figures: its heartbeat reference says heartbeats run full agent turns, that the cadence default is 30 minutes for API-key auth or one hour for OAuth, and that isolatedSession reduces per-heartbeat token cost from roughly 100K to roughly 2 to 5K tokens. That is the largest controllable line in the whole comparison, and it has nothing to do with which client you chose. These are token-arithmetic estimates at the assumptions stated, excluding cache charges, output on the heartbeat turns, external tools and hosting.

Two honest gaps. It is not verified that OpenClaw runs a heartbeat at all when no agents.defaults.heartbeat block exists — the documentation gives the cadence default without stating that the feature is on out of the box — so read the rows above as the cost of a heartbeat you configure. And nanobot's configuration reference does enable a gateway heartbeat by default every 1800 seconds, with routine results "skipped silently", and that same reference lists heartbeat evaluation among the internal tasks that open a model stream, so a skipped heartbeat is not necessarily a free one. It publishes no per-heartbeat token figure, so nanobot's idle cost cannot be stated from its own documentation. Measure both with one quiet day before committing to a schedule.

What OpenClaw does enable by default is memory consolidation, on a daily 03:00 cron, using the agent's default model unless you set dreaming.model — pointing that at a cheaper model is a one-line change. nanobot has the same shape of job: its memory reference says Dream runs on a cron schedule by default and takes a modelOverride naming a cheaper preset, so budget for it on both sides. Its separate idleCompactAfterMinutes, default 15, is a compaction timer rather than a scheduled model call; the docs tie that default to a typical KV cache expiry window. Neither project publishes a per-run token figure for its consolidation pass, and the two systems are unrelated — do not read one project's numbers onto the other.

Beyond tokens, budget the machine that keeps the gateway running plus any paid channel or tool account: OpenClaw's SMS channel is a Twilio setup and its Signal channel runs through signal-cli, as a local daemon or a container, with its own number, while nanobot's transcription options and any image or search tools are separate accounts.

If you want to fund the model side with prepaid credit instead of a subscription, Kunavo's minimum top-up is $10 in prepaid credit, and the balance does not expire. Read the billing guide first: a catalog estimate is not a ceiling, because the charge can be higher when upstream-cost billing exceeds it. Create a Kunavo account when you are ready to run that bounded trial in whichever client you chose.

Moving between them, in either direction

Assume nothing transfers automatically. The provider block is rewritten by hand in the other shape; a nanobot modelPresets entry has no direct equivalent to OpenClaw's models.providers.<id>.models[] and vice versa. Channel credentials are re-issued per channel. Schedules move as definitions, not as state: nanobot keeps cron state at <workspace>/cron/jobs.json, and both products require the gateway process to keep running for anything scheduled to fire.

Memory is the part worth exporting deliberately. nanobot's durable knowledge lives in SOUL.md, USER.md and memory/MEMORY.md inside a workspace that defaults to ~/.nanobot/workspace/. OpenClaw keeps its workspace at ~/.openclaw/workspace by default, separate from ~/.openclaw/, which holds config, credentials and sessions, with OPENCLAW_WORKSPACE_DIR overriding the default workspace path per its agent-workspace reference. Copy the files, then read them in the destination — carrying a file over is not proof the next session retrieves the right fact.

Move one recurring task first, and keep the old installation until the replacement completes it and survives a restart. If the shortlist is really OpenClaw against something other than nanobot, compare alternatives by workflow; if you have already chosen OpenClaw and only need the model route, the provider comparison and operating-cost breakdown go deeper than this page.

FAQ

Source documents checked September 21, 2026: both repositories, their published documentation, the PyPI record for nanobot-ai and the npm record for openclaw. Kunavo has not runtime-tested either client; configuration blocks are read from vendor documentation. Kunavo rates come from the live catalog and the totals are token arithmetic at the stated assumptions, not measured task cost.