Settings

Otōto’s settings are one file, ~/.config/ototo/config.toml, which ototo init writes for you. Most people set the model server and nothing else.

• A variable wins over the file. Every setting is also an environment variable: its name in capitals with OTOTO_ in front (verify is OTOTO_VERIFY). OTOTO_CONFIG points at another file.
• A session reads the file when it starts. A change reaches the sessions of your agent started after it. ototo serve says on stderr which file it read, and names any key it does not know.
• An organisation’s file sits under yours, and can enforce some settings over it: For organisations.
• ototo doctor checks the file and each model server; the dashboard shows what the file says now.

dist/config.toml.example is a file to start from.

The model server

base_url = "http://<host>:<port>/v1"
model = "<the name the server gives the model>"

The server needs OpenAI-style tool calls, 32,000 tokens of context and 4,000 of output; thinking is switched off in each request. A model server: quick starts has the flags for each server we have run.

Several servers

List several and each request goes to the first that answers. A spot GPU that has been reclaimed, a workstation that is switched off, or a gateway’s error page hands over in seconds, and a server that failed waits at the back of the queue for a minute, so that the next requests do not wait on it. A hosted model makes a last resort: paid for by the token, but always there.

[[endpoints]]
name = "gpu"
base_url = "http://<gpu host>/v1"
model = "Qwen/Qwen3.8-27B-FP8"

[[endpoints]]
name = "workstation"
base_url = "http://<workstation>:8080/v1"
model = "RedHatAI/Qwen3.8-27B-INT4"

[[endpoints]]
provider = "anthropic"          # https://api.anthropic.com unless base_url says otherwise
model = "claude-haiku-4-5"      # key from ANTHROPIC_API_KEY, or api_key / api_key_env

The other settings stay at the top of the file and apply to every server. A reply that another server answered says so in its footer (via haiku (gpu, workstation down) · $0.031), and the run log records which answered, why the others failed and what a paid model cost: list prices for the Claude models, or price_input and price_output on the endpoint, in US dollars per million tokens. OTOTO_BASE_URL in the environment still pins one server.

How far a question may go

An answer that ran out of turns or tokens says so, and is the small model’s best by then. A long question in several parts reaches the budget most often, and does better asked apart.

tool_choice. With auto, no tool_choice is sent: the model may answer in prose, and is nudged back to its tools. required is for servers with constrained decoding (vLLM): every turn must call a tool, with arguments held to the tool’s schema. That rules out mangled parameter names, but with Qwen3.8 on vLLM it also made the model repeat its last call in place of changing course, a search it could not narrow five turns running, where auto answered the same question in eight. Leave it on auto, and try required only if a model keeps mangling its arguments. A server that refuses tool_choice (llama.cpp) has it dropped after the first refusal.

Checking the answers

The checks that need no model, of every name and value a claim states against the code it cites, are always on: How it works.

What your agent is offered

hide_model_tools. Without it, the tools that need a model stay listed while none answers, and fail at once, saying what works meanwhile. With it, the session that finds every server gone tells your agent its list has changed, asks once a minute (a request of a few tokens) whether a server is back, and leaves a note for the prompt hook. Two things to know first. Run ototo init after setting it, since the prompt hook must then ask Otōto what to say (ototo doctor says when that is still to do), and a process of Otōto’s starts with each prompt. And a list that changes in the middle of a session costs Claude Code its prompt cache, once each way. Tried with Claude Code; not yet with OpenCode.

How much a read returns

A longer range is cut, with a note saying where to continue. The small model’s own reads stay at 250 lines a call, whatever these say: its context is the one that fills.

Edits

With a check_cmd, the small model gets a check tool. Its pending edits are written, the command runs in the repository, and every file is put back afterwards; one that someone else changed meanwhile is left alone, and reported. The verdict is in the reply’s footer. It is the one thing Otōto runs, and Otōto takes it only from its settings and its environment, never from the files of a repository it reads. (A project’s .mcp.json, which Claude Code asks you to approve, can set OTOTO_CHECK_CMD in the registration’s environment.)

Outside the repository

Both are off because each widens what Otōto reads. dependency_caches is the one case where it reads outside the directories a session was given; a cache that is a home directory or a whole disk is ignored.

Plugins

The plugins has the commands; ototo plugins help gitlab the forge plugin’s settings.

The run log and the dashboard

The log holds questions, the small model’s steps and replies, and stays on your machine.

Reporting

otlp_endpoint, otlp_headers, otlp_attributes and otlp_interval send counts, never questions, code or answers, to an OpenTelemetry collector of yours: Metrics.

Updates

ototo update installs a newer release from the channel, or, when the channel does not answer, the newest package for this machine in ~/Downloads. Either way it checks the release’s checksums against their signature by Otōto’s release key, which is built into the binary, and the package against its checksum, then runs the package’s install.sh, which keeps your settings. Only a newer release is installed, so a channel cannot move anyone back. --check only says whether there is one; --dry-run downloads and checks.

For an organisation

enforced and min_version belong in the organisation’s file, with the settings it wants everyone to have: For organisations.