Nanobot API costs and setup: providers, models and limits

nanobot from HKUDS costs $0: it is MIT-licensed software you install and run yourself, and neither its GitHub repository nor nanobot.wiki publishes a plan, a tier, a seat or a hosted service. What you budget is model tokens, the machine that keeps nanobot gateway running, and any paid channel or tool account you attach. Two things then decide what the tokens cost: which provider key you write in config.json, because that key alone selects the wire protocol, and the background jobs nanobot enables without being asked.

Checked September 21, 2026 against the GitHub and PyPI APIs: release v0.3.5, published September 15, 2026; package nanobot-ai 0.3.5, MIT, Python 3.11 or newer, uploaded the same day; repository MIT, not archived, last pushed on the day of the check. One scope note runs through this page: the documentation quoted below was read on branch main, five days ahead of the v0.3.5 tag, so doc statements and shipped-source defaults are labelled separately and never merged.

First, check which nanobot you are pricing

nanobot.ai is not a nanobot price page. On September 21, 2026 it redirected to obot.ai, titled "Obot | Enterprise AI Control Plane & MCP Gateway" — a different company's enterprise product, which publishes no price of its own either, since its /pricing URL returned 404 that day. Two more collisions: the PyPI package plainly named nanobot is 0.4.1, a robot navigation framework, so pip install nanobot installs the wrong software; and obot-platform/nanobot is an Apache-2.0 Go project whose README opens by declaring maintenance mode, so its config keys do not apply here.

What nanobot costs, line by line

Two honest gaps there. nanobot's CLI reference describes coexistence with a separate "Desktop" runtime, and no public download page, repository or price for it was found — so the supportable claim is narrow: no paid tier is published on the two official surfaces, not that no paid component exists anywhere. And the voice row is a hard stop rather than a price. The constraint is narrower than "no custom endpoint": v0.3.5's transcription adapters do each accept an apiBase, so an OpenAI-shaped transcription endpoint can be substituted, but transcription.provider itself must be a name from that registry — there is no inventing a provider key for it as there is for chat. It is moot here in any case, because Kunavo serves no speech-to-text model.

The nanobot custom provider: two paths, and only one is yours to name

This is what a generic "set your base URL" example gets wrong. In nanobot the protocol is chosen by which provider key you write, not by a field you set, and the two paths are not interchangeable.

Path A — OpenAI-compatible. Invent a key under providers, or use the built-in custom key, and point a preset at it. Per the provider reference, custom keys are treated as direct OpenAI-compatible providers, apiBase is required because nanobot cannot know the endpoint URL, and apiKey is optional for local servers or private proxies. Include the version path in apiBase.

{
  "providers": {
    "kunavo": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com/v1"
    }
  },
  "modelPresets": {
    "primary": {
      "provider": "kunavo",
      "model": "claude-sonnet-5",
      "maxTokens": 8192,
      "contextWindowTokens": 200000
    },
    "cheap": {
      "provider": "kunavo",
      "model": "claude-haiku-4-5",
      "maxTokens": 8192,
      "contextWindowTokens": 200000
    }
  },
  "agents": {
    "defaults": {
      "modelPreset": "primary",
      "dream": {
        "modelOverride": "cheap"
      }
    }
  }
}

Three rules travel with that block, all from the same reference. Do not collide with a built-in name or alias such as openai, openai-codex, github-copilot or lm-studio. Do not set apiType on a custom key — it is only for providers.openai, and the v0.3.5 schema enforces that too. Set thinkingStyle only if your endpoint documents a nonstandard thinking toggle, where the accepted values are thinking_type, enable_thinking and reasoning_split. Model ids need a precise statement rather than the doc line alone: the docs say the model is sent as written under an explicit named custom provider, while the shipped 0.3.5 registry sets a dynamic spec's strip_model_prefixes to the provider key's own name and its snake_case form. Both hold if the doc line is about foreign prefixes — a prefix equal to your provider key is stripped, anything else goes through — and prefix-based provider inference only runs under provider "auto".

Path B — Anthropic Messages. There is no custom-name route to this protocol at all: the reference states that arbitrary custom provider names are OpenAI-compatible only and do not use the Anthropic Messages request format, and that the named custom path is not for Anthropic-compatible endpoints. You override the built-in block instead:

{
  "providers": {
    "anthropic": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com"
    }
  },
  "modelPresets": {
    "primary": {
      "provider": "anthropic",
      "model": "claude-sonnet-5",
      "maxTokens": 8192,
      "contextWindowTokens": 200000
    }
  },
  "agents": {
    "defaults": {
      "modelPreset": "primary"
    }
  }
}

Because that edits providers.anthropic itself, the gateway replaces direct Anthropic for every preset pointing at that provider rather than sitting beside it, and proxy is unavailable here because the native backends reject it. Kunavo's two base-URL conventions map onto the two paths exactly: the base URL reference gives the origin for the Messages route and the /v1 form for the OpenAI-compatible one. nanobot is unusually forgiving on that point — its shipped 0.3.5 anthropic provider strips a trailing /v1 before handing the URL to the SDK — its own comment gives the reason, that the Anthropic SDK appends /v1 to request paths internally. Both spellings therefore work in nanobot. Do not carry that habit to a client that passes your base URL to the Anthropic SDK unchanged, where the appended /v1 would double. Two last notes on the blocks above: contextWindowTokens is nanobot's own preset default in v0.3.5 rather than a property of any model, so take the real figure from the model page; and entries in fallbackModels are preset names, not raw ids, with context sized to the smallest window in the chain.

Prompt caching in nanobot follows the protocol you picked

This is the cost consequence of Path A versus Path B, and it is visible in the shipped source. In v0.3.5 a provider spec carries supports_prompt_caching, defaulting to false, and exactly two specs set it true: anthropic and openrouter. The OpenAI-compatible client injects cache-control markers only when that flag is set and the model id begins with anthropic/ or claude. The built-in custom spec and every dynamically created custom provider leave the flag false, so an OpenAI-compatible custom route sends no cache markers at all, while the native anthropic backend applies them by default.

That is a statement about what the client sends, not about what an endpoint does on its own side — an endpoint may cache server-side regardless. nanobot gives you the means to check, normalising prompt_tokens_details.cached_tokens on one path and reading cache_creation_input_tokens and cache_read_input_tokens on the other. Whether Kunavo returns those fields to nanobot has not been tested here, so verify the returned usage on one real call before budgeting a recurring job as cached; prompt caching and the caching doc show what a working cache looks like.

Best model for nanobot: the vendor publishes no ranking

The honest answer is the one nanobot gives itself: its provider reference states that the docs show concrete provider names so the JSON is copyable, not because nanobot ranks providers. There is no vendor benchmark to cite. What it ships is a default — v0.3.5's agent defaults name anthropic/claude-opus-4-5 with provider auto, 8192 max tokens and a 200,000-token context assumption. That id is not in Kunavo's catalog, so a preset aimed here must name an id the catalog actually lists, and ids change: read the current ones from the catalog rather than from any page, this one included.

Rates are live Kunavo catalog prices, and the job column follows from how nanobot is structured, not from a quality ranking anyone has measured. Claude Sonnet 5 currently sits exactly at its vendor's list price in the catalog, so budget no saving on that one model. Claude Opus 5 and Claude Sonnet 5 also carry the same catalog rate today, so choosing between those two is a capability decision rather than a price one — re-check before assuming it still holds. For a family comparison on capability rather than config, see Opus vs Sonnet vs Haiku.

A worked estimate: typed turns, plus the cadence nanobot turns on for you

These are illustrative token arithmetic, not measured task costs and not a bill ceiling. Assume one assistant handling 20 typed turns a day for 30 days, at an assumed 10,000 uncached input and 600 output tokens per turn — 6.0M input and 0.36M output tokens a month.

The schedule is the sourced part; neither the token size nor the number of runs that actually bill is. nanobot's configuration reference enables a gateway heartbeat by default at intervalS 1800, and v0.3.5's Dream config is enabled by default at intervalH 2, which works out to 1,440 heartbeat ticks and 360 Dream ticks in a 30-day month. A tick is not a model call. In the shipped v0.3.5 gateway the heartbeat job reads HEARTBEAT.md and returns before any model request when the file is missing or has nothing under an ## Active Tasks heading, and the Dream job logs "nothing to process" and returns when no new history has accumulated since its cursor. So an idle install pays nothing for either job, and 1,800 is the ceiling the schedule allows rather than a floor you will hit. nanobot publishes no per-run token figure for either job, so the three sizes above are placeholders to replace with your own measurement, and output tokens on those runs are excluded. Do not import another agent's heartbeat figures here; they belong to a different program.

The two levers are not symmetric. Dream accepts modelOverride naming a cheaper preset — preset names only, raw ids rejected — the one-line change already in the Path A block above. The heartbeat has no documented model override: its options are enabled, intervalS and keepRecentMessages, so it is slowed or switched off, and being a system-managed cron job it cannot be removed with the cron tool; disable it in config and restart the gateway. Where it does have tasks to run, heartbeat evaluation is one of the internal jobs the configuration reference lists as opening a model stream — so the cost follows what you put in HEARTBEAT.md, and an empty file is the cheap case. One refinement against Kunavo's nanobot vs OpenClaw page, which says Dream runs on a cron schedule by default: that matches the memory reference, and v0.3.5 is more precise — every 2 hours as an interval schedule, with cron a legacy override.

Kunavo's catalog amount is a billing floor rather than a cap: when the upstream reports its charge, the bill is the greater of catalog cost and upstream cost times the applicable markup. Cache charges, tools and hosting sit outside these examples. The minimum top-up is $10 in prepaid credit — a funding minimum, not a task fee or a subscription. See billing details, and cost optimization for the measurement method.

Set the loop bounds, then verify with one run

Two of nanobot's three per-turn bounds are not in its configuration reference at all. Read from the shipped v0.3.5 source, agent defaults carry max_tool_iterations 200 and max_tool_result_chars 16,000; only maxConcurrentSubagents, default 4, appears in the documented reference on main. A 200-iteration ceiling is the shape of an expensive runaway turn, so set it deliberately rather than inherit it.

Then verify in the documented order. nanobot status deliberately sends no model request, so it confirms configuration without spending anything, and the CLI reference tells you to follow it with nanobot agent -m "Hello!". Its symptom table maps the four failures a custom endpoint produces: a 401 is a missing, expired, whitespace-padded or wrongly-stored key; model not found is an id that does not exist for that provider; connection refused is a local provider server that is not running, or an apiBase pointing at the wrong port; provider not found is a misspelled provider in the active preset.

Then reconcile against money rather than tokens. In v0.3.5 nanobot records each provider call with a source validated against user, api, cron, dream and system — the split that separates background spend from typed spend — but no cost field appears anywhere in that module. Its WebUI charts input tokens per round with a cache hit rate when reported and states outright that those figures are not a billing statement, and no aggregate spend command appeared in the CLI reference read on September 21, 2026 (an absence in that document, not proof none exists). Read the charge from your provider's ledger.

Which route wins, and what it costs you

Two boundary notes. Image generation accepts custom as a provider value and is off by default, but whether Kunavo's image endpoint matches the request shape nanobot sends is untested here — unverified, not a feature. And one cost you will not have: nanobot's durable memory is plain files under the workspace rather than a vector index, which is convenient because Kunavo serves no embedding model.

Kunavo publishes no nanobot integration page and has not runtime-tested nanobot against its endpoint — every block above is read from nanobot's own documentation and its shipped v0.3.5 source, so treat them as a configuration reference to try rather than a compatibility result. Keep a working route available, run one bounded task, then read what your account recorded for it. The quickstart and base URL reference cover both endpoint conventions, and creating a Kunavo account is the step before funding a key. Still choosing the program? nanobot vs OpenClaw compares the runtimes, and the agent API directory indexes clients by wire protocol and BYOK boundary.

FAQ

Sources checked September 21, 2026: the GitHub and PyPI APIs for HKUDS/nanobot and nanobot-ai, nanobot's providers, configuration, memory and CLI documentation on branch main, and the shipped v0.3.5 source downloaded from PyPI for every numeric default. Doc statements and source defaults are five days apart and are labelled separately throughout. Kunavo has not runtime-tested nanobot; token rates come from the live catalog and every dollar figure is illustrative arithmetic at the stated assumptions.