takopi registers its four engines as entry points, and asks for a bot token before anything else

The four built-in engines are installed the same way a plugin would be

The most revealing part of the packaging is the entry point table. There is a group for engine backends and a group for transport backends, and the four engines the documentation names are each declared in that first group, pointing at a module and a symbol inside the source tree. The single transport is declared the same way. So the plugin mechanism is not an add-on layer bolted on top of a hard-coded list, it is the only way the program finds an engine at all, and the four that ship are simply the four that ship with a declaration. The documentation says as much in one line, that plugins exist for engines, transports and commands, and it points at a how-to and a reference for writing one. Adding a fifth agent is therefore a Python package with a declared entry point, not a line in a settings file.

One provider has a runtime dependency and the other has a command on the path

The dependency list contains a client library for one model provider as a hard requirement, and nothing corresponding to the other. That asymmetry is not an oversight, it follows from how each engine is driven. One engine is spoken to through its own command line tool, which the requirements section demands be on the path along with the other three names, and a command line tool needs no client library. The other is reached over its network interface, which does. It is worth separating that from the claim in the feature list, which is that existing subscriptions with both providers are honoured. That is a statement about billing and authentication rather than about code, and it is the kind of claim that means you keep paying the provider you already pay rather than adding an API bill.

The Python floor is 3.14 and the coverage floor is 81

The project states its floors numerically, which makes it easy to tell whether you are in scope. The interpreter requirement is 3.14 or newer, and the classifier list names one interpreter version rather than a range, so anything older is out of support by declaration rather than by accident. Installation itself is a single tool install, and it expects the package manager that manages the interpreter:

uv tool install -U takopi

That installer needs the manager present on the machine first, and the requirements section spells out the two commands for getting it: one that pipes an install script into a shell, and one that asks the manager to fetch the required interpreter. The rest of the setup assumes both are already done. The test configuration is equally specific: coverage is collected for the package with branch coverage enabled, missing lines are reported in the terminal rather than hidden, and the run fails below 81 percent. The development group also includes a mutation testing tool, which checks the tests by breaking the code on purpose. A project with a bot token, a filesystem watcher and four process integrations that holds itself to a numeric bar is doing something different from most chat bridges, and that is worth knowing before you file a bug about a restart loop.

Setup begins with a bot token, then a workflow, then a chat

The first run is a wizard with four steps in a fixed order, and the order is a design statement. First you create a bot token with the messaging platform's own bot account helper, because without a token the program has no way to be reached at all. Then you pick one of three workflows, and this is the choice that actually determines how the thing behaves afterwards, because the three workflows configure conversation mode, topics and resume lines automatically. The assistant workflow is an ongoing chat with automatic resume and is the one marked recommended. The workspace workflow binds forum topics to repositories and branches. The handoff workflow turns every turn into a reply that ends with a line you can paste into a terminal. Only after that do you connect your chat and choose a default engine.

Resume is the feature the whole thing is built around

One line in the feature list carries the design: resume is stateless, meaning you can either continue in the chat or copy a resume line and pick the same thread up in a terminal. That is a small promise with large consequences, because an agent session normally lives in one process on one machine, and this program has to be able to hand a live thread to a different front end. The handoff workflow is the explicit version of it, built around reply-to-continue and terminal resume lines, while the assistant workflow does it automatically. Project registration is the other half: once a directory is registered, any chat can name it and run against it, with the example showing a project name followed by a request to reset a timeline, which reads like an instruction to an agent rather than a command to the bridge.

A branch mention becomes a worktree

Working on several things at once is handled with git worktrees rather than with branches and a single checkout, and the trigger is a mention in the message. You register a project once, and after that a message beginning with the project name and an at-sign followed by a branch name runs an agent in a dedicated worktree for that branch. So the branch in your message is not a label applied to a shared working tree, it is the thing that decides which directory the agent gets, and the work exists in isolation. This is also the part of the design that most affects a repository you care about, because worktrees multiply inside it and the copies outlive the conversation, and none of the documentation in the file mentions how they are cleaned up.

The homepage in the packaging points at the code host, not the site

Small inconsistencies, worth listing because they tell you which artefact to trust. The project metadata has a documentation link pointing at the project site and a homepage link pointing at the code repository, while the repository's own homepage field points at the site. The readme file in the tree is lower case, and so is the changelog. The task runner is a justfile rather than a makefile, and the documentation site has its own configuration file at the root, matching a documentation tool in the docs dependency group. The code itself lives in a source directory with tests and helper scripts beside it, and there is a directory named after one of the supported agents at the root, which suggests the project is developed partly through the tool it bridges. The repository is not archived and its last commit is dated 2026-05-25, with three patch releases in the eleven days before that.

Editorial conclusion

Use takopi if you want your agent reachable from a phone and you already live in one of the four supported command line agents, because the engine has to be on the path before the program can do anything. Three things to check first. Setup starts by creating a bot token, so have your messaging account ready and expect to grant a third party access to your chat. The Python floor is 3.14, which is recent enough to matter on a work machine. And the extension model is packaging, not configuration: a new engine or transport is a package that declares an entry point, so if you were expecting a config file listing of engines, that is not how it works here.

Frequently asked questions

Official sources

1. banteg/takopi on GitHub
2. License: MIT
3. Project website
4. README
5. Releases