Octop: a self-hosted multi-agent assistant that routes every surface through one process
A smarter, self-hosted AI assistant — multi-user, multi-agent.
At a glance
- What is it?
- Octop is a Python 3.12+ self-hosted AI assistant from TencentCloud that runs a web dashboard, CLI, IM channels and cron in a single process backed by SQLite. The interesting part is the in-process HarnessProcessor; the part to check before adopting is how much of the README's surface area is actually documented.
- Who is it for?
- Adopt Octop if you want one Python process on your own hardware serving a dashboard, CLI, IM channels and cron from a single SQLite file, and you are willing to read the source when the README stops. Do not adopt it if you need a stable API surface, a documented upgrade path, or a project whose release notes you can plan around: the version is 0.9.32, and the README does not describe a migration procedure.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Octop picks: one machine, several people, several agents
Most self-hosted assistant projects assume a single operator. You run a container, you point it at a model endpoint, and you talk to it. The moment a second person wants their own conversation history, their own credentials, and their own scheduled jobs, the design breaks down. Octop targets that gap directly. The README describes it as a platform for households and small teams, with multi-user JWT authentication and an admin role, and with multiple agents per user where each agent carries its own workspace, providers, channels and cron entries. The intended user is someone who wants the dashboard, the chat channels and the automation to live on hardware they control, with all state under ~/.octop/. That is a narrower audience than the phrase self-hosted AI assistant usually implies. It is not aimed at a company running a shared inference cluster for hundreds of employees, and nothing in the material suggests horizontal scaling.
One process, one database, no external broker
The architecture claim worth examining is the absence of a message queue. According to the README, Octop routes every surface (Web UI, IM and cron) through one in-process HarnessProcessor, and the entire state is rebuilt from ~/.octop/octop.db on boot. The control plane database is SQLite in WAL mode, accessed through aiosqlite. That is a deliberate trade. You get a restart-safe process with no Redis, no RabbitMQ and no separate worker pool to operate, which is a real reduction in moving parts for a household deployment. You also get a ceiling: a single writer database behind a single process is not a design that fans out across machines, and the README does not describe any clustering mode. The agent runtime itself is not written from scratch. Octop composes four packages: harness-agent for model routing, tools, skills and conversation checkpointing; harness-gateway as the IM channel bridge that normalizes incoming messages into one pipeline; harness-memory for hierarchical recall with full-text search; and harness-browser for CDP-based automation with persistent profiles. The web layer is FastAPI plus uvicorn, the frontend is React 18 with TypeScript, Vite and Ant Design, and scheduling uses APScheduler. This is a composition project: the value is in how the pieces are wired, not in a novel runtime.
Getting it running: init, run, and the config keys that matter
The README points to a first-run setup wizard invoked as octop init, followed by octop run, which the documentation says starts the dashboard, CLI, IM channels and cron together. A separate interactive chat entry point exists as octop chat. For IDE integration there is octop acp --agent main, described as a stdio ACP server for clients such as Zed and OpenCode, and there is an outbound direction configured from the dashboard at /acp where you register runners so Octop can delegate to external coding agents with permission gates. Two config details are stated explicitly and both are worth noting. The interactive API docs at /api/docs are off by default, and you turn them on by setting "enable_api_docs": true in config.json. The expert library is scanned at boot from infra/agents/experts/library/, which means the contents of that directory in your checkout determine what specialists appear in the UI. Python 3.12 or newer is required. The README also lists workspace backends beyond local disk: COS, S3 and other remote stores, plus Docker containers and PostgreSQL as pluggable backends. The material does not give the exact keys for configuring those backends, so treat the dashboard settings pages as the place to discover them rather than expecting a complete config reference in the README.
Where the documentation stops short
The README is a feature inventory, and it reads like one. It tells you that shell command guardrails, tool approval and PII redaction exist, but it does not specify what the guardrails match on, whether the rules are configurable, or what happens when a command is blocked. It states that memory is powered by harness-memory and that memory migrates with the workspace, without describing the storage format or what migration between backends involves. The remote desktop feature is listed for Linux, Windows and macOS with a one-click isolated desktop on headless Linux, with no indication of which display server or protocol is used. None of this is unusual for a project at version 0.9.32, and the repository is the fallback. But a reader deciding whether to install this should understand that the README answers what exists, not how to operate it under load or how to recover when a component misbehaves. The single-process claim is the most load-bearing statement in the document, and it is also the one with the least supporting detail about failure behaviour.
A genuine limitation: the release cadence and the missing upgrade path
Three releases appear in the supplied material, v0.9.28 on 26 August 2026, v0.9.31 on 1 September 2026 and v0.9.32 on 6 September 2026. That is a patch roughly every five days, and the version numbers are still in the 0.9 range. Fast iteration on a project that owns your credentials, your conversation history and your scheduled jobs is a different proposition than fast iteration on a library. The README does not describe a database migration procedure, a schema version, or a downgrade path, and because all state lives in one SQLite file under ~/.octop/, an upgrade that changes the schema touches the only copy of your data. Nothing in the material says upgrades are unsafe. It also says nothing that would let you plan one. If you deploy Octop, the practical consequence is that you should treat ~/.octop/octop.db as something to back up on your own schedule, because the project has not told you what it does with it between versions.
How it differs from generic agent frameworks
The obvious comparison is to agent frameworks such as LangChain, which give you libraries for building an agent and leave the serving, authentication, persistence and channel handling to you. Octop makes the opposite choice. It ships the whole stack as an application: FastAPI serving a React dashboard, JWT auth with an admin role, IM channel adapters through harness-gateway, cron through APScheduler, and a SQLite control plane, all started by one command. You give up the ability to embed the agent in your own service and shape its API, and you gain a running product with a UI on first boot. The ACP support sharpens the contrast. Inbound, external tools connect to your Octop agent over stdio; outbound, Octop connects to external coding agents as a client. A framework does not usually take a position on either direction. Octop's position is that it wants to sit in the middle of your tooling rather than underneath it, which is coherent for the household and small-team audience but a poor fit if you need the agent as a component inside a larger system.
Licence and what maintenance actually costs
Octop is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the permissive end of the spectrum and it removes the licensing question from most adoption decisions. The maintenance cost sits elsewhere. Octop depends on four harness packages plus FastAPI, uvicorn, APScheduler, aiosqlite and a React toolchain, and the README does not state how those dependencies are versioned relative to the octop wheel. A patch release every few days means you are tracking a moving target, and the cost of that tracking falls on whoever operates the deployment. For a single household machine the cost is low: you run octop run, you check the dashboard, you back up the database file. For anyone who needs change control, the absence of release notes in the supplied material and the absence of a documented migration step mean you are reading commit history to decide whether a given patch is safe. That is the real price of MIT here. The licence is free; the operational discipline is not.
Editorial conclusion
Adopt Octop if you want one Python process on your own hardware serving a dashboard, CLI, IM channels and cron from a single SQLite file, and you are willing to read the source when the README stops. Do not adopt it if you need a stable API surface, a documented upgrade path, or a project whose release notes you can plan around: the version is 0.9.32, and the README does not describe a migration procedure. Before installing, verify two things in the repository: whether the expert library under infra/agents/experts/library/ is populated in the release you pull, and whether the harness-agent, harness-gateway, harness-memory and harness-browser packages are published on PyPI at versions compatible with the octop wheel you install.
Community notes