Arbiter CLI

Arbiter is a single binary with three operating modes — interactive, one-shot, and server — plus a handful of admin commands. Which mode you pick depends on whether you want a terminal session, a scripted invocation, or a long-running HTTP service.

The interactive mode is documented separately under docs/tui. Everything else is here.

Full flag reference

arbiter                                    Interactive REPL (the TUI)
arbiter --init                             Create ~/.arbiter/ + example agents
arbiter --send <agent> <message>           One-shot — print agent reply to stdout
arbiter --api [--port N] [--bind ADDR]     HTTP+SSE orchestration server
              [--verbose]
arbiter --add-tenant <name>                Provision a tenant + API key
arbiter --list-tenants                     Print active and disabled tenants
arbiter --disable-tenant <id|name>         Revoke a tenant's access
arbiter --enable-tenant <id|name>          Restore access
arbiter --help                             Print built-in help

Pages

• Getting started — pick a path:
  • Hosted preview — managed endpoint, limited-preview waitlist.
  • Local install — install + first run on your own machine.
• --init — what gets created, the ~/.arbiter/ layout.
• --send — the one-shot mode for scripts, pipes, and CI hooks.
• --api — the HTTP server mode: flags, behaviour, links to the endpoint docs.
• Tenant admin — managing --api bearer tokens.
• A2A agents — outbound remote-agent registry + the /a2a slash command.
• Environment — every env var arbiter reads, what overrides what.

Choosing a mode

Interactive. The default. Multi-pane TUI, persistent session per cwd, all slash commands available. Built for humans typing into a terminal. Reach for it when exploring, iterating with an agent, or running long sessions.

One-shot (--send). No TTY, no panes, no streaming. Sends one message to one agent, prints the reply on stdout, exits non-zero on error. Built for scripts and pipelines:

echo "$DIFF" | arbiter --send reviewer "$(cat)"
arbiter --send research "summarise the top 3 issues" > /tmp/summary.md

The agent runs the full orchestration loop internally (tool calls, sub-agent delegation) — you just don't see the intermediate steps; you see the final synthesised reply.

API (--api). A long-running HTTP+SSE server. Real applications (web UIs, automations, mobile clients) call it instead of forking the binary per request. Multi-tenant: every request authenticates with a bearer token from --add-tenant, all conversations / artifacts / memory / scratchpads are tenant-scoped. See docs/api for the endpoint catalogue.

The three modes share the same on-disk state — agents under ~/.arbiter/agents/*.json, API keys read from ~/.arbiter/api_key (or env), provider keys at the same precedence everywhere. A change made in one mode is visible to the others on next launch.

Exit codes