OpenManus pricing and API setup: the free program, the token bill, and the config that ships dead

OpenManus costs $0. It is MIT-licensed open source with no plan, no paid tier, no licence key and no hosted edition, so "OpenManus pricing" resolves entirely to the model API bill behind it — plus two cloud services that are optional and off by default. The number worth budgeting is what one agent run sends, and the setting most likely to distort it is the config file OpenManus itself ships: it still defaults to a Claude model ID that was retired on February 19, 2026, and it loads anyway if you skip the copy step.

One disambiguation first, because the search results for this query are mostly about something else. Manus is a separate, paid, credit-metered commercial product from a different company, and its commercial API at api.manus.ai is a third thing again. No Manus price appears on this page: manus.im/pricing is client-rendered and could not be read from the official source on September 21, 2026, and the figures circulating on third-party blogs are not official. Check manus.im directly if that is the product you want.

Five things called Manus or OpenManus

The move matters more than it sounds. The project's own homepage, openmanus.github.io — the homepage field set on the live repository — still links readers to the old mannaandpoem path, as do most 2025 tutorials. The current repository was checked through the GitHub API on September 21, 2026: archived: false, MIT, 58,367 stars, 455 open issues, last push August 22, 2026, with the last commit on main dated August 16, 2026. Two separate projects share the name on GitHub as well — OpenManus/OpenManus-RL is a different reinforcement-learning project, and henryalps/OpenManus is a same-name repository that appears in results and was not inspected beyond confirming it resolves.

What is free, and what actually bills you

Install is source-only: conda create -n open_manus python=3.12 or uv venv --python 3.12, then a git clone of the current repository. There is no one-line package install, and setup.py declares python_requires=">=3.12".

Where the OpenManus API key goes

There is no environment variable and no command-line flag for the key. Bring-your-own-key in OpenManus is a TOML file: copy config/config.example.toml to config/config.toml, then set model, base_url and api_key under [llm].

# config/config.toml — copy config.example.toml here first, then edit.
# If this file does not exist, OpenManus loads the example file instead.
[llm]
model = "claude-sonnet-4-6"
base_url = "https://api.kunavo.com/v1"
api_key = "sk-kn-..."
max_tokens = 8192
temperature = 0.0

# Sub-tables of [llm] are profiles, selected by the AGENT's name lower-cased,
# and they inherit every key you leave out. "manus" is the agent main.py runs;
# "mcp_agent" is the one run_mcp.py runs.
[llm.mcp_agent]
model = "claude-haiku-4-5"

The client is picked in LLM.__init__ in app/llm.py, and only two values of api_type change anything: "azure" builds an AsyncAzureOpenAI client and "aws" builds a Bedrock client. Everything else — including the ollama, jiekou and ppio values in OpenManus's own example files — falls through to a plain AsyncOpenAI(api_key, base_url). Those labels are documentation, not code paths. So reaching an OpenAI-style POST /chat/completions endpoint needs base_url and api_key and no api_type value at all; what that endpoint then has to support is a separate question, and the list below is short but real. Kunavo's endpoint has that shape — https://api.kunavo.com/v1, Bearer auth, sk-kn- keys, and an unauthenticated GET /v1/models answers 401 — and it accepts OpenAI-style tools and tool_choice, which is what OpenManus's agent loop sends. That is a statement about protocol shape, checked September 21, 2026. No OpenManus run has been performed against Kunavo, so nothing on this page is a compatibility test.

Three requirements your endpoint has to meet, read from current main, and one thing OpenManus will not do for you. ask_tool hardcodes stream = False and always sends tools plus tool_choice (default auto), so an endpoint that only streams tool calls breaks the loop. max_tokens and temperature go on every request unless the model ID is literally o1 or o3-mini, the two entries in REASONING_MODELS. The code reads usage.prompt_tokens and usage.completion_tokens straight off the response. And there is no cross-provider retry: failures go through tenacity with exponential backoff against the same endpoint.

The two official starter configs disagree

This is the trap worth arriving prepared for. OpenManus ships two official starter configurations that contradict each other, and neither file mentions the other.

Anthropic's deprecation page lists claude-3-7-sonnet-20250219 as Retired with a retirement date of February 19, 2026, and states that requests to retired models will fail; the recommended replacement is claude-sonnet-4-6. Those dates apply to Anthropic-operated platforms — Amazon Bedrock and Google Cloud run their own schedules. The README is the fresher of the two files, which inverts the usual assumption that the shipped example is canonical.

And the dead config is also the default. Config._get_config_path() in app/config.py returns config/config.toml if it exists, otherwise config/config.example.toml, and only raises if neither is present. So a first run that skips the copy step does not produce a helpful "no config" error — it authenticates with the literal string YOUR_API_KEY against a model ID that no longer answers. The README does not mention that fallback; it says only to copy the example file. Other shipped examples point at Claude 3.7 Sonnet too — the Daytona example carries the same dated retired ID, and the Anthropic example sets claude-3-7-sonnet-latest for the main model with the dated ID in its vision block — while the Google example sets gemini-2.0-flash, which Google lists under previous models with the note that those are deprecated and "will be shut down soon". Treat the config/ directory as example files the project ships, not as a list of supported providers: nothing in the repository tests them, and app/llm.py has not been modified since April 26, 2025.

The [llm.vision] block is not read by anything

Every shipped example includes an [llm.vision] section, and on current main no agent reads it. Profiles are selected by the agent's own name, lower-cased — app/agent/base.py does LLM(config_name=self.name.lower()) — and the agent names present are Manus, browser, swe, toolcall, Data_Analysis, SandboxManus and mcp_agent. None is "vision", an unknown profile name falls back silently to [llm], and ask_with_images() is defined but has no call sites anywhere in the repository. The sub-tables a shipped entry point can actually select are [llm.manus] (the agent both python main.py and run_flow.py run), [llm.mcp_agent] (run_mcp.py), [llm.sandboxmanus] (sandbox_main.py) and [llm.data_analysis] (run_flow.py, once use_data_analysis_agent is switched on). BrowserAgent does set name = "browser", but no shipped entry point instantiates it, so [llm.browser] is inert unless you write your own runner. Any sub-table inherits every key you leave out of it, so an override only needs the keys that differ.

Vision itself is gated a second time, and this one decides whether a gateway can serve it at all. app/llm.py declares a hardcoded allowlist:

Neither survivor is OpenAI's current flagship — the same pricing page lists gpt-6-astra and the gpt-5.6 family above them — so the only way to get OpenManus vision without editing code is to run a 2024 model. The comparison is exact string equality, so a namespaced slug such as openai/gpt-4o does not match either. When the configured model is not on that list, format_messages deletes the base64_image field and sends the text alone — no error, no warning, the screenshot simply never reaches the model. Kunavo publishes neither gpt-4o nor gpt-4o-mini, so a Kunavo-configured OpenManus is text-and-tools only unless you edit MULTIMODAL_MODELS in app/llm.py yourself. Text generation and tool calling are unaffected; the allowlist gates images only. Nor is a model listing proof of the rest: an endpoint advertising the exact string gpt-4o satisfies OpenManus's comparison, but whether it forwards an inline data: image URL through to the model is a separate question that was not tested for any endpoint here.

What one OpenManus run costs

No OpenManus task was executed for this page, so there is no measured cost to report. What the code does give is an honest structure. The default agent in app/agent/manus.py sets max_steps = 20 and max_observe = 10000. Each step is one non-streaming tool-calling request that carries the whole conversation so far, so input tokens grow with the square of the step count, not linearly.

The figures below are token arithmetic on stated assumptions, not a measured task cost and not a bill ceiling. Assume a base prompt of 4,000 tokens (system prompt plus tool schemas), 1,200 tokens appended to the history per step, and 400 output tokens per step. A run that finishes in 6 steps then sends about 42,000 input and 2,400 output tokens; a run that goes to the 20-step cap sends about 308,000 input and 8,000 output. Rates are live Kunavo catalog prices per million tokens.

Read the two columns against each other rather than the rows. Under these assumptions 20 steps is 7.3 times the input of 6 steps for 3.3 times the steps, which is why "how many steps does it take" dominates "what does the model charge per token" in an agent loop. That also makes prompt caching a large lever on this shape of bill, and it is worth knowing where it is unavailable: Anthropic's OpenAI SDK compatibility documentation — describing the exact base URL OpenManus's shipped example points at — states that prompt caching is not supported there, that strict, response_format and reasoning_effort are ignored, that n must be exactly 1, and that system messages are hoisted to the front. The same page calls that layer "primarily intended to test and compare model capabilities, and is not considered a long-term or production-ready solution for most use cases." OpenManus never sends a cache directive of its own, so any caching has to come from the endpoint.

One parameter to check before you point OpenManus at a recent Claude model: the examples ship temperature = 0.0 and the code sends temperature on every request outside the two reasoning IDs, while Anthropic's deprecation page marks temperature, top_p and top_k deprecated on Claude Opus 4.7 and later and says a non-default value returns a 400. The compatibility page separately describes temperature as supported between 0 and 1. Whether the compatibility layer strips, clamps or forwards it was not tested here — treat it as something to verify on your own route, not as a confirmed failure.

Scale these by your own runs per day before calling them a budget. 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 and external tools sit outside this example. The minimum Kunavo top-up is $10 in prepaid credit, which is a funding minimum rather than a task fee or a subscription — see billing details.

Best API for OpenManus: which route wins when

Note what is not on that list: there is no plan gate anywhere in OpenManus. No licence key, no paid tier, no telemetry check — every capability above is available to anyone who clones the repository, and the gates are all in the code rather than in a subscription. Compare routes in OpenAI-compatible API and LLM gateway, or OpenRouter alternatives if you are already on one. For the method behind "cheapest listed rate" versus "cheapest to finish", see AI cost optimization; for a single-family decision, cheapest Claude API.

Set it up and check the first run

Kunavo publishes no OpenManus-specific setup page, and OpenManus has not been runtime tested here against Kunavo's endpoint — everything above was read from the project's source and its own documentation. The generic path is the one in the config block above: base_url of https://api.kunavo.com/v1, an sk-kn- key, and a model ID from the catalog. Keep a working route available while you try it, run one bounded task with max_steps left at its default, then read the charge your account recorded for it rather than OpenManus's own logged totals, which are tiktoken estimates with a cl100k_base fallback for any ID tiktoken does not recognise. Start at the quickstart, check the request shape in chat completions, and create a Kunavo account when you are ready to fund a key.

Choosing between agents rather than providers? Best API for OpenClaw and the AI agent API directory cover clients with the same split between free software and a metered token bill.

FAQ

Checked September 21, 2026 and not more widely: the GitHub API record for FoundationAgents/OpenManus; config/config.example.toml, the README configuration and install sections, app/llm.py, app/config.py and app/agent/manus.py on current main; the six per-provider example configs in config/; the tag list; the stub README at the old repository path; the PyPI record for openmanus; Anthropic's model-deprecation and OpenAI-SDK-compatibility pages; OpenAI's pricing and deprecations pages; and Google's Gemini model list. Browser Use Cloud and Daytona are named as optional vendors and linked, not priced here. Manus, manus.im and the Manus API were not priced at all: their pricing page could not be read from the official source. Nothing was executed — no install, no request through OpenManus, and no Kunavo-plus-OpenManus run — so every behavioural claim is a source read, and every dollar figure is illustrative token arithmetic rather than a measured task cost. Kunavo token rates come from the live catalog.