Nanobot review

Nanobot is an open-source, self-hosted personal AI agent framework written in Python. It runs as a local or server-side agent gateway, with a bundled WebUI, terminal interface and connections to chat channels. It is not a hosted model API: you connect a supported model provider or local model server, which you supply.

In a stack, Nanobot sits between users and the model. It routes conversations through browser, terminal or chat interfaces and gives the agent tools for files, web search and fetch, MCP integrations, cron, image generation and multi-agent delegation. Built-in tools read PDF, Word, Excel and PowerPoint files. Dream supports session history and long-term memory; scheduled automations can run over time. The project targets Python 3.11 or newer. This architecture suits developers who want to inspect and modify an agent framework rather than buy a managed assistant. You also take responsibility for deployment, model access and the infrastructure the gateway needs.

The documented integration route is the Python SDK, which the project says can embed the agent. Nanobot itself is written in Python and requires Python 3.11 or newer. For direct use, it offers a terminal interface and a bundled browser UI; the gateway can also connect to chat channels including Telegram, Discord, Slack, WeChat, email, Mattermost and Linear.

The project documentation includes installation, configuration, deployment, architecture, provider extensions and guides for chat apps. The README also points to setup for providers, fallback models, Langfuse, MCP, web tools and security. OpenAI-compatible APIs and local LLMs are listed among its model options. MCP provides an extension surface for integrations, while the Python SDK is the named route for embedding. The homepage does not establish a general external REST API contract, so confirm the supported API surface and compatibility guarantees in the vendor’s docs before building a separate client. Stable releases and current source have different update paths.

The pricing page lists no paid plans, monthly or annual billing terms, or starting price. Nanobot is open-source under the MIT license, so the software itself has no listed license fee. There is no published free-tier quota or request allowance to plan around, and no listed paid add-ons.

That does not make an agent deployment cost-free. Nanobot requires access to a supported model provider or local model server, and its README says model fees or local hardware requirements depend on the service you choose. The project does not publish a per-request rate, usage tier, seat price, overage charge or total-cost estimate. With a hosted model, your provider’s billing will depend on that provider’s terms and your usage; with a local model, account for the hardware and its operation. Those costs are separate from Nanobot. Before production, estimate model usage using the provider’s pricing and your expected workload, then check how the gateway handles provider errors and any provider-side limits. The project’s own published pricing gives no basis for a precise monthly estimate.

Nanobot’s repository lists an MIT license and makes its source available on GitHub. The project describes itself as self-hosted and supports running a long-lived gateway locally or on a server. That gives developers access to the code and control over where they run the agent; it does not remove dependency on the model provider, chat platforms or other services they connect.

The README does not establish a standard data-export format or a migration procedure. Before storing durable memory or relying on saved conversations, inspect where Nanobot stores that data and how to back it up or export it. Moving away from Nanobot may also mean replacing its tool, channel and scheduled-task integrations. The source is available for that work, but the effort depends on which parts of the framework your workflows use. Confirm storage formats and provider configuration before committing long-lived data or building internal tooling around them.

Nanobot is designed to run as a long-lived local or server-side gateway, but production teams should verify the operational details for their deployment. The homepage publishes no rate limits, uptime or scaling guarantees, concurrency figures, or recovery objectives. Check how your selected model provider handles throttling and failures, and test the gateway’s restart, backup and update procedures. The README distinguishes stable releases from current source, with different update paths.

Security deserves particular attention because the advertised capabilities include shell, file, web and chat integrations. Review the security documentation, limit credentials and tool access, and decide what files and services the agent can reach. Confirm data retention, access controls and compliance fit for the systems you connect; the project’s feature list is not a substitute for those checks.

One Reddit thread reports a user running Nanobot in a Linux container with Telegram after a short setup. Other commenters discuss customization and token costs, but these are individual reports, not reliability or cost guarantees. Treat them as anecdotes and validate your own workload.