nanobot
A self-hosted Python runtime that brings personal AI assistants, tools, chat channels, and automation into one lightweight gateway.
Per-dimension scores and reasoning
Evidence shows: SECURITY.md details API key management, channel access control (allowFrom), shell execution sandbox (bwrap), filesystem restrictions, and explicitly requires users to configure allowFrom and enable sandbox, reflecting least privilege. User confirmation: README mentions first-run WebUI requires confirmation to enable local WebSocket channel, but not comprehensive for all sensitive operations. Data flow transparency: WebUI allows viewing reasoning, tool calls, file edits, etc., but no complete data flow diagram. Sensitive data handling: SECURITY.md recommends env var references for keys and restricts config file permissions, but not enforced. Dependency security: SECURITY.md recommends pip-audit and keeping dependencies updated, but no automated scanning. External effects: tools like exec can run shell commands, but sandbox and dangerous pattern detection provided. Rollback: no explicit rollback mechanism for config or operations. Source attribution: README and LICENSE clearly list authors and contributors, but publisher unverified. Deductions: user confirmation not comprehensive, dependency security lacks automation, rollback missing.
Evidence shows: README and docs structure consistent, pyproject.toml has clear dependency version ranges, CI workflow covers multiple platforms and Python versions, test files exist. Dependency availability: dependency list complete, but no lock file (uv.lock not seen in source). Failure messages: SECURITY.md and docs provide troubleshooting guides, but no specific error message examples. Deductions: dependency locking unclear, failure message examples insufficient.
Evidence shows: README provides multiple installation methods (one-liner, uv, pip, source) and guides for different users (non-technical, developers). Capability boundaries: docs list supported tools and channels, but no explicit limitations. Trigger precision: automation (cron) documented, but trigger conditions not detailed. Environment fit: supports multiple OS and deployment methods (Docker, Render), but not all environments detailed. Deductions: capability boundaries and trigger precision not detailed enough.
Evidence shows: README provides clear information architecture, docs directory complete. Install notes detailed with multiple methods and troubleshooting. Naming stability: project name and CLI command consistent. Examples and FAQ: quick start and docs links provided, but no FAQ page. Known limitations: SECURITY.md lists security limitations, but no functional limitations. License MIT, version and changelog mentioned in README. Maintenance responsibility: README lists contact and contributors, but no explicit maintenance policy. Deductions: missing FAQ and functional limitations, maintenance responsibility unclear.
Evidence shows: Output usability: WebUI and CLI provide clear output, but no detailed output format specification. Marginal value: project offers multiple integrations and automation, but no comparison with similar tools. Cost-benefit: open-source, but no performance or resource consumption data. Deductions: lack of comparison and performance data.
Evidence shows: README claims (e.g., feature list) consistent with docs and code, but no specific verification methods. Cross-source corroboration: docs and code corroborate each other, but no external verification. Fact-inference separation: README clearly distinguishes feature descriptions and installation steps, but no explicit inference labeling. Deductions: lack of external verification and explicit inference labeling.
- Publisher identity unverified; exercise caution regarding supply chain risks.
- Dependency security only recommends manual scanning; no automated mechanism provided.
- User confirmation mechanism not comprehensive; sensitive operations may not be fully prompted.
- Rollback mechanism missing; configuration or operation errors may be difficult to recover.
What does this agent do, and when should you use it?
nanobot is a self-hosted personal AI agent runtime written in Python. It accepts work through a WebUI, terminal, and chat applications, using a small agent loop to drive model and tool execution. The runtime includes session history, Dream long-term memory, MCP integrations, model routing, subagent delegation, and scheduled automation. It can use files, shell commands, web search, web fetch, image generation, cron, and subagents, while exposing a Python SDK and an OpenAI-compatible API. It can run persistently on a local machine or server and documents Docker, Docker Compose, Linux service, macOS LaunchAgent, and Render Blueprint deployment paths.
Run nanobot webui for a local browser workbench or nanobot agent for an interactive terminal session; nanobot agent -m "Hello!" sends one request and exits. nanobot gateway runs the full persistent gateway for chat channels and automations. Messages arrive from the WebUI, terminal, or connected Telegram, Discord, Slack, WeChat, Email, Mattermost, and other chat apps; the model decides whether to call files, shell, web search, web fetch, MCP, cron, image generation, or subagents. The runtime retains session history and uses Dream for long-term memory, while the WebUI can show reasoning, tool calls, file edits, diffs, command output, and generated artifacts. It also exposes a Python SDK and an OpenAI-compatible API for integrations.
- A personal user who wants an assistant running on their own machine or server can manage separate topics, workspaces, and models in the WebUI.
- A team already working in Telegram, Discord, Slack, WeChat, Email, or Mattermost can route those conversations through one agent gateway.
- A developer needing a single model request from a shell script can use
nanobot agent -mfor a one-shot invocation. - A user who needs work to run on a schedule can use cron and scheduled automations with a persistent background gateway.
- An integration developer connecting local tools, MCP services, or an OpenAI-compatible interface to an existing workflow can use the runtime, Python SDK, and API.
What are this agent's strengths and limitations?
- Combines a WebUI, terminal, chat channels, and a persistent gateway in one lightweight Python core.
- Includes Dream long-term memory, MCP, model routing, subagents, cron, and scheduled automation rather than only one-off chat.
- Provides both a Python SDK and an OpenAI-compatible API for local-tool and automation integrations.
- The published package includes the WebUI, avoiding a separate frontend build.
- A usable reply requires selecting a provider, supplying credentials, and choosing a model; these are not preconfigured.
- Source installation adds Git plus bun or npm requirements, and Windows may require a manual WebUI build.
- Chat channels, automations, and background operation depend on a continuously running gateway, adding operational overhead compared with a one-shot
nanobot agentcall. - Render persistent disks require a paid service, and the README does not specify the costs of model providers, search, or image-generation services.
How do you install or deploy this agent?
Python 3.11 or later is required. Install the published package with uv tool install nanobot-ai or python -m pip install nanobot-ai, then verify it with nanobot --version. For first use, run nanobot webui, open Settings → Models, choose a provider, enter its credential, and select a model; a provider credential is required for a working reply. Source installation requires Git and bun or npm: clone the repository and run python -m pip install . from an activated virtual environment.
How do you use this agent?
For first use, run nanobot webui; it creates configuration and a workspace when needed and opens http://127.0.0.1:8765. The first-run WebUI binds to localhost by default. Configure Settings → Models, create a topic, and send Hello! to verify the model, workspace, and gateway. For persistent operation, use nanobot webui --background and manage it with nanobot gateway status, nanobot gateway logs, nanobot gateway restart, or nanobot gateway stop; use nanobot gateway directly when you want the full gateway without the browser setup flow.
How does this agent compare with similar options?
The README presents nanobot gateway as a gateway-first entry point familiar to people coming from OpenClaw or already operating agents as long-lived services; it does not provide a feature-by-feature comparison.
FAQ
Can it run locally?
127.0.0.1 by default, but the selected model provider still requires credentials.Is the browser required?
nanobot agent provides interactive terminal chat, and nanobot agent -m "Hello!" performs a one-shot request. nanobot gateway can run the full gateway directly.What local resources can it access?
Can it stay running and connect to chat applications?
nanobot gateway or nanobot webui --background can keep channels and automations running after the launcher exits. Documented channels include Telegram, Discord, Slack, WeChat, Email, and Mattermost.What is needed for Render deployment?
ANTHROPIC_API_KEY and a private NANOBOT_WEB_TOKEN, and provisions persistent storage for sessions, memory, and WebUI history. Persistent disks require a paid Render service.