Quick start
Install Otōto, give it a small model if you have one, and ask your agent a question about your code.
1. Install
curl -fsSL https://ototo.sh | sh
On macOS with Apple silicon, or Linux on x86_64 or arm64. It fetches the newest release, checks it against
Otōto’s release key (which is written into the script), puts ototo in ~/.local/bin with its plugins, and runs
ototo init, the next step. To read the script first: ototo.dev/installer. To
check and download and then stop: curl -fsSL https://ototo.sh | sh -s -- --dry-run.
You need a coding agent. ototo init sets up Claude Code (2.1 or later) and
OpenCode; Pi and any other MCP client take one command by hand.
2. A small model, or none yet
ototo init looks for a model server on this machine, on the usual ports of vLLM, llama.cpp, MLX, Ollama and LM
Studio. It sends the model one request with a tool, to check it can call tools, then lists what it will change and
asks before it writes.
| You have | Do |
|---|---|
| A model server on this machine | nothing: ototo init finds it |
| One elsewhere (a team’s GPU server) | ototo init --base-url http://<host>:<port>/v1 |
| None yet | carry on: Otōto sets up the tools that need no model (search, read, outline, changes, history, replace_all). Run ototo init again once a server runs, and ask, locate, callers and edit join them |
A model server: quick starts has one for each server we have run, and the models worth using: one for a team’s GPU server, and one a laptop holds.
3. Check
ototo doctor
checks each part and says what to do about anything wrong: the settings, each model server (reachable, serving the model, calling tools), your agent’s setup, and whether the plugins load.
4. Ask
Start a new session of your agent in a repository (one that is already running keeps the tools it started with), and ask about the code as you would anyway:
How are cached tiles evicted, and what decides the limit?
The agent hands the question to ask and answers from what comes back: a short explanation, with path:line
citations that Otōto has checked against the files. For what it already knows it wants, it calls read, outline
and search in place of opening whole files.
Every tool also runs from a shell, which is the quickest way to see what your agent sees:
ototo ask "which class validates a new pet?"
ototo outline src
ototo read src/cache/Store.kt#evict
5. Watch it work
ototo tail
follows each delegated call as it runs: the question, every turn of the small model with the tool it called, the
claim check, and how it ended. ototo ui shows the same as a dashboard, at http://127.0.0.1:7777.
Later
- Updating.
ototo updatefetches the newest release, checks it against the release key and installs it;ototo plugins updatedoes the same for the plugins. Neither runs by itself. - Switching models.
ototo init --base-url <url>again; your other settings are kept. - Removing it. The installer ends by printing the command that undoes everything it did
(
sh …/uninstall.sh). Each file it changed was backed up first, as<file>.before-ototo-<time>.
Where next
- How it works: what happens inside an
ask, with diagrams, and what leaves the machine. - The tools and the plugins: what your agent now has.
- For organisations: one settings file for many machines.