Nanobot v0.3.0 runs a full personal-agent gateway
Nanobot v0.3.0 is built for an assistant that stays around. One gateway serves a browser workbench, terminal client, OpenAI-compatible API, and chat channels. The agent can use files, shell commands, web search, MCP servers, scheduled automations, memory, and helper agents. That range makes sense for a technical user who wants the same sessions and tools available at a desk and inside messaging apps. It also gives the process meaningful access to the host, so workspace and execution controls deserve setup time.
The word lightweight describes the agent core better than the whole checkout. We measured 1,314 files and about 366,963 lines of source at commit 3852956, with a 16.8 MB checkout. The repository includes the Python runtime, bundled WebUI, native terminal client integration, numerous channels, deployment files, and extensive documentation. There is plenty here to inspect, yet this is no pocket script. A team adopting it becomes responsible for a broad application with several user interfaces and many external connections.
What happened when we ran it
Our sandbox installed Nanobot in 45 seconds. The process pulled 113 packages and occupied 174 MB on disk, then the build completed in 9 seconds. Those results support the README's claim that a developer can get the code installed without assembling a large cluster or a GPU stack. The measured environment was a fresh Debian container with 3 CPUs and 8 GB of RAM, running Python 3.12 without secrets or privileged container access.
The test result changes the recommendation. Pytest reported 316 passed, 195 failed, 16 skipped, and 5 collection or setup errors before stopping after 200 failures. The log tail names errors in QQ reconnect backoff, API attachments, API streaming, the OpenAI API, and the NapCat channel; it does not establish why they failed. We will not guess. Pip-audit also reported 42 known vulnerabilities, which calls for dependency triage before this snapshot handles credentials, files, or shell access.
Python 3.11 gets the UI open, then provider setup begins
Python 3.11 or newer is the published baseline. The stable routes are an installer, uv, or pip, and the README sends a new desktop user directly to nanobot webui. The browser opens on localhost and walks through choosing a model provider, credential, and model. Source users add Git and Bun because the checkout runs matching frontend and terminal code. The packaged route includes the WebUI and downloads a checksummed terminal archive on its first use.
Installation therefore covers only the local program. Our 113-package, 174 MB result did not include a model account, chat tokens, search credentials, or production persistence. A useful first reply requires a provider configuration, even if the endpoint is a local Ollama or vLLM server. Telegram, Discord, Slack, email, Mattermost, WeChat, and other channel choices each bring their own setup. Keeping any of them online after the terminal closes means running the gateway in background mode or under a service manager.
Chat integration is Nanobot's clearest reason to choose it
Release v0.3.0 treats the WebUI as the front door, while the same gateway carries conversations into chat services and terminal sessions. Saved topics, temporary chats, model switching, workspace selection, tool activity, diffs, and generated artifacts are visible in the browser. Long-running work is explicit through goals, and scheduled automations can keep operating through a persistent gateway. This is a coherent product shape for one technical user who moves between devices and does not want separate assistants in every interface.
That surface area is still moving. The 195 failed tests in our run included channel and API areas, and an open Telegram report dated 2026-08-25 says rich messages do not render when default streaming is enabled. Another report against v0.3.0 shows auto-compaction raising a NameError for a missing import. Neither report proves the whole feature is broken, but both identify paths that matter during long conversations. Test the exact model, channel, and background mode you intend to use.
The 2026-08-25 activity shows speed and churn
GitHub showed 739 open issues and PRs combined, split into 206 issues and 533 pull requests when we checked. The repository's last push was 2026-08-25, and several pull requests were merged or updated that same day. The latest release, v0.3.0, arrived on 2026-07-25. This is active maintenance rather than an abandoned tag, though the queue and daily changes make version pinning sensible for an always-on service. Read release upgrade notes before moving production channels forward.
The repository also has 2 CI workflow files, a Dockerfile, a Compose file, and a tests directory. That is useful operational evidence, but our 195 failures show that having test infrastructure does not guarantee a clean result in a fresh container. The documentation is unusually thorough: separate guides cover providers, configuration, architecture, security, troubleshooting, chat apps, automations, the API, SDK, and deployments. Docs score well because they expose the work, even when the measured snapshot raises hard questions.
The 174 MB install suits a careful self-hoster
Nanobot is easiest to recommend as a controlled trial for an experienced self-hoster. The WebUI and package installer reduce initial friction, while the shared gateway solves a real problem for people who want one assistant across local tools and chat accounts. Use the stable package path, bind the first setup to localhost, give it a narrow workspace, and enable channels one at a time. A remote WebUI or API should have its required token before it leaves loopback.
Our 3-CPU, 8 GB sandbox proved that installation and build can finish quickly, then exposed 195 failed tests and 42 known vulnerabilities at commit 3852956. That combination is the buying decision. Nanobot has enough product depth and documentation to merit evaluation, but this measured snapshot does not earn unattended access to a production host. Pin a version, audit the reported dependencies, rerun the relevant tests in your target environment, and verify recovery behavior before trusting persistent goals or scheduled work.