nanobot

You will like this if the word lightweight means something to you: uv tool install nanobot-ai, one config, and it is answering in Telegram or Slack with tools, memory and a cron job by the evening. The daily trait is that the core is small enough to read, so when it does something odd you open the file rather than the issue tracker.

You will not like it if you want an ecosystem of plugins and a community answering questions at 2am. Pick it for a personal assistant you intend to understand. Pick OpenClaw if you want breadth and do not mind the size.

The risk is the shell. The README lists terminal execution among the tools and describes no sandbox setting for it, while the same README connects the agent to Telegram, Discord, Slack, WeChat and Feishu among others. Every one of those is an inbound text channel, and text is how prompt injection arrives. The host that runs nanobot is the host the command runs on.

The consequence: run it in a container you built, on an account that owns nothing you care about. What it does right is the default bind: the web UI listens on 127.0.0.1, so at least the console is not on the network by accident.

The documentation is a feature list, and the reviewer can only grade what is written. 1. Context: a memory system called Dream, said to handle session history and long-term memory; the README does not describe how memories are selected or when they are written. 2. Planning: none described. 3. Actions: tools plus inline subagents that the main agent consults without leaving its task, which is a sensible way to keep the primary context short. 4. Verification: nothing documented.

No benchmark is published. The row on this board is unverified because the docs live in repository files the README merely links. Thin is the accurate word; it may also be honest, since the project claims little.

This is not a company and I will not grade it as one. HKUDS is a university lab, the README names two maintainers, and there is no pricing page because there is nothing to price. Adoption is strong for a lab project, but adoption without a revenue line is a cost centre for whoever pays the maintainers' stipends.

The pivot is predictable: a paper, a graduation, and a repository that goes quiet or gets adopted by a company that wants the users. Likely acquirer in the loose sense: whichever agent vendor hires the maintainers. Moat: none. Position: free option, enjoy it, and keep a fork.

The demo is an assistant that answers in a chat app and runs a scheduled job overnight. Procurement finds nothing to procure: it installs per person, has no single sign-on, no audit trail and no admin console, and the deployment recipes, Docker Compose or Render, stand up one assistant for one person. Sixty of them is sixty snowflakes with sixty keys.

The cost is model tokens only, which finance will like until someone asks who is watching the spend. It fits nowhere in CI. It has a Teams connector, which is the one enterprise-shaped thing about it. Not yet, and not the kind of thing that becomes yet.

MIT, Python, pip or uv, and my local models are first-class: Ollama and vLLM are listed providers, and there is fallback routing so the cheap model answers first and the expensive one only when the cheap one fails. The provider cookbook in docs saves me reading the source, though I read it anyway.

Two things I did not expect. It exposes an OpenAI-compatible API, so anything that speaks that protocol can use nanobot as a backend, and the MCP side references the MCP Registry, so adding a server is a lookup rather than a hand-typed config. Small, forkable, entirely mine. Respect, and not the grudging kind.