1
Install it
One file lands in your path. Checksum-verified, and it updates itself in place.
curl -fsSL https://tryrig.ai/install.sh | sh ✓ rig 3.5.3 installed to ~/.local/bin/rig # later rig -update
model rig · rev 3.5.3
one binary · no runtime · MIT
█▀▄ █ █▀▀ █▀▄ █ █ █ ▀ ▀ ▀ ▀▀▀
A real agent for the model you already run.
max · default · auto
up 214k down 18k · cache r 211k 99%
❯curl -fsSL https://tryrig.ai/install.sh | sh
linux · macOS · amd64 · arm64 · no Go, no sudo
installs to ~/.local/bin
rig -update keeps the runtime current
what it is
rig turns the model on your desk into something that works. Point it at your repo and it reads the code, edits it, runs the tests, and remembers what it learned. One binary, one endpoint, one terminal.
It is small enough to read before you trust it. The loop is a few hundred lines, and everything around it plugs in: tools, guardrails, schedules, workers. One priority queue runs the show — tool calls run side by side, land in the order the model asked, and nothing needs a lock. Sessions stay fast for hours because the prompt never wobbles, and the cache does the rest.
Another harness will run your model too. The difference is what happens when things go wrong: rig's refusals name their rule instead of retrying blind, every decision lands in a store you own, and the reviewer reads the code before it judges yours. Harnesses ask for trust. rig shows its work.
Close the laptop. Pick the session back up from your phone.
why rig, honestly
Every harness on this page is good at something, and the four are not the same product. The table is what each project says about itself in October 2026 — its docs, its README, its tools — not a benchmark and not a vibe. Where rig loses, it says so below.
| axis | rig | pi | oh-my-pi | opencode |
|---|---|---|---|---|
| what it is | a Go runtime plus harness: agent loop, stores, fleet, model room | a minimal TypeScript harness, built to be extended | a pi fork with the IDE wired in, Rust core | a TypeScript coding agent with a client/server core |
| runtime | none. One static Go binary, pure-Go SQLite | Node.js 22.19+ | Bun or a prebuilt binary; Rust core | a standalone install script; Bun installs npm plugins at startup |
| the small part | 448 lines is the loop; core/ and loop/ are frozen behind a gate |
small by design; features arrive as extensions | ~80k lines of Rust core | the server is the core; clients attach |
| tools | 12 on a plain row, 13 with vision, 14 with a decision server; one door for plugins; a worker gets a narrower doing set | the built-in set, plus extensions and packages | 31 built-in tools, LSP and DAP operations | built-in tools plus custom tools from plugins |
| models | any OpenAI-compatible endpoint, plus an Anthropic wire; you write the row | a built-in provider catalog and /login |
60+ providers | a broad provider catalog, plus its own Zen gateway |
| model routing | the room: no router process; claims order the model's port, a silent port starts the row's child, swaps are ordered acts; mesh spans machines |
the endpoint routes; the harness just calls it | the endpoint routes | the provider routes; the server routes clients |
| permissions | deny-by-default allowlist, approval gate, pathguard, plugin provenance, bubblewrap/landlock jailed workers | no built-in permission system — containerize the process | permission prompts; the IDE is the surface | a permission config, with per-tool rules |
| workers | delegate, cron, and swarm on one board and one queue; budget cap, review gate, resumable transcripts | skips sub-agents by design; install a package | task fan-out into isolated worktrees, Agent Hub |
primary agents (Build, Plan) plus subagents, configured in its config |
| language servers | the code map speaks LSP for extraction only: documentSymbol and references, TypeScript by default |
extensions | a full lsp tool: diagnostics, navigation, renames, code actions |
LSP wiring with diagnostics events |
| the decision model | built in: typed questions, a reviewer, a store that is the training set, and measured promotion | — | — | — |
| embedding | a Go module: rig.New(...) and loop.Run, seams wired once |
the TypeScript SDK | pi packages, Bun installs | an SDK over its HTTP server |
| plugins | one Python file is one tool; the model's authoring is pending until you approve it | extensions, skills, npm/git packages | pi packages and skills | JS/TS hooks and npm packages, installed at startup |
| platforms | Linux and macOS, amd64 and arm64 — no Windows build | macOS, Linux, Windows | macOS, Linux, Windows | macOS, Linux, Windows |
Sources: the projects' own docs and READMEs — pi.dev, can1357/oh-my-pi, opencode.ai/docs — read in October 2026. A dash means the feature is not part of the project, not that it is impossible.
where each one wins
If you are choosing a harness, pick the one whose center of gravity matches your problem. These are not consolation prizes; they are the reasons people run them.
pi — the one to read
The smallest harness with a real SDK. Extensions, skills, prompt templates and themes are npm packages or a git URL, and the provider catalog logs in for you. It skips sub-agents and plan mode on purpose: you build what you want. Its own README says to containerize if you need boundaries.
best when the harness is a starting point
oh-my-pi — the widest surface
A pi fork with the tool shelf pre-stocked: 31 tools, LSP and DAP operations, a real IDE loop, browser and computer control, in-process grep and bash, 60+ providers. More surface than rig has, by a lot.
best when the tool shelf matters more than the core
opencode — the most clients
A TUI, a desktop app, an IDE extension, and a client/server core that other programs can drive. A broad provider catalog and a plugin system with hooks and custom tools. Built to be used by people and teams, from anywhere.
best when the agent is an app, not infrastructure
rig — the runtime
One binary, no runtime, no router process. A priority queue that orders your input, the model's stream, tool completions and the fleet's messages; a room that orders model claims across instances; a scheduler that runs jobs jailed; a decision pipeline that trains its own sorter. Built so the harness is infrastructure.
best when you are embedding or operating agents
what rig does not do
windows
No Windows build. Linux and macOS, amd64 and arm64; the release matrix is the list.
providers
Two wires, not a catalog: OpenAI-compatible and Anthropic. You write the row and bring the endpoint, key and prices. No /login, no gateway.
surfaces
No desktop app and no IDE extension. The TUI and the web dashboard are the two faces; both drive the same session.
lsp
The code map speaks LSP to extract symbols and references; there is no lsp tool on the model's menu. No rename, no diagnostics, no debugger.
plugins
Python files, one tool per file. Rich hooks and an npm ecosystem are opencode's and pi's game, not this one's.
the concurrency model
Everything rig does arrives on one queue: your input, the model's stream, tool completions, worker messages. One consumer reads it, ordered by priority first and arrival second. Nothing races, so there is nothing to lock — and nothing sleeps on a timer, because the completion event is the wakeup.
order
A parallel tool call is a goroutine that posts its completion; completions are applied in call order. Three reads run beside each other and the transcript still reads top to bottom, as if nothing ran in parallel.loop/ · evt/
batching
Admitted calls — reads, views, fetches, delegates — run eight at a time beside each other. Anything with effects is a barrier between them. Concurrency for the model, order for the record.loop/batch.go
broadcast
A worker's return posts above the turn's own events, so the work you asked for is in hand at the turn's boundary. The fleet's other messages post below, so the chatter runs in the gaps and never ahead of you. A busy session delays the chatter and loses nothing: the stores hold the facts.broadcast/
the swarm
The queue orders by priority, not by source — so a fleet costs no extra machinery. swarm start 2 puts drain workers and reviewers on the same loop, the same jail, and the same return path as you.swarm/
The numbers are the whole table, and they live in kernel.go:
90 input your line, at the boundary 70 delegate a worker's return, ahead of the turn in flight 60 write an effect: runs inline, in call order 50 read overlaps, eight at a time 50 stream · tool 30 fleet swarm notices, in the gaps 10 review the reviewer bites only when idle
the protocol
The loop never retries. The refusal teaches.
A failed call runs once and the model is told why, in words it can act on. No hidden retry, no guessing. The rules of the board, the files, and the sandbox are not in the prompt; they arrive the moment they matter, which is why small models get good at rig fast.
● edit · core/turn.go ✗ edit: the file changed since the read: - maxRetries = 3 + maxRetries = 0 ● read · core/turn.go ● edit · core/turn.go ✓ core/turn.go · 214 bytes replaced ● todo · complete t2 ✗ 't2' is blocked by 't1' (pending; start it first) ● todo · start t1 one refusal, one correction, the rest of the session clean
the tools
A focused menu, chosen the way you choose a knife drawer. Twelve names on a plain row, thirteen with "vision": true, fourteen with a decision server. Every result is capped; every refusal is named.
bash
Real subprocesses. Output surfaced and bounded.
read · write · edit
Files. Read is the observation path, drift-checked; edits are exact-match and provenance-checked. The shell does listing and searching, which it already does well.
view
An image: downscaled, content-addressed, sent to a vision model. Off unless your row says "vision": true.
python
A persistent IPython kernel. Variables and imports survive between calls.
web
Search a local SearXNG, or fetch a URL as readable text. Local and private addresses refuse.
todo
The task board, scoped to the project — a repo's worktrees share one. Tasks link with requires and blocks.
rem
Memory across sessions, and the code map: learn, recall, reflect, prune, index, pack.
scheduler
Jobs on your crontab, each fire jailed by default. The crontab is the scheduling truth.
delegate
A headless worker for a bounded subtask, handed off now and returned on a later turn.
sessions
The store's vitals: which models ran, what failed, the cache ratio.
plugin
The door into your Python tools: run, schema, and the ecosystem verbs. One door, so a grown table stops blowing context.
decide · verdict
decide hands many items to a decision server against one typed question; verdict is the reviewer's one word, only in a worker that holds the pipe.
A worker gets the doing set — bash, read, write, edit, view, python, web, rem. The session's verbs stay with the session that owns the state.
call it an operating system, and mean it
Every part an OS has, rig has, and each one lives in a directory you can read in an afternoon.
kernel
loop.Run(ctx, kernel) over typed seams. It names no tool, no provider, no frontend.loop/ · core/ · kernel.go
scheduler
Reads run side by side, eight at a time; effects land in call order. Background jobs go on real cron, and each one fires jailed.loop/batch.go · tool/scheduler
processes
Sessions, delegates, drain workers. Each worker owns a transcript, sandboxed and resumable.frontend/ · tool/delegate · swarm/
ipc
One event stream, tool calls through the middleware chain, and the stores as the shared state between processes.core/provider.go · evt/ · store/
filesystem
The workspace through read, write, edit; every path canonicalized before it is trusted.tool/file · pathguard/
permissions
Allowlist, approval gate, pathguard, plugin provenance, worker jail. Deny by default; every refusal has a name.middleware/ · policy/
modules
One Python file is one tool, pending until you approve it.plugins/
shells
The TUI, the piped CLI, the one-shot, the web dashboard: four frontends over one session.frontend/ · command/
the model is a key, not an endpoint
Every rig instance on the machine sits in one room over a unix socket. The model is a key in it: before a request, the instance claims at its class's priority — your turn 90, a worker 30, a child's start 20 — and sends to the model's port itself once every live member agrees the claim is first. No process routes; llama-swap left the stack at 3.0.0 and nothing replaced it. A claim that finds the port silent starts the row's child and waits. One child at a time, and mesh extends one room to many machines.
the router story, the child half of a model row, and how loading and unloading are ordered: setup.
provenance
Built by hand until it could finish one turn. Everything after that, rig wrote inside itself, on local models, driven from a phone.
1324 commits · the git log is the receipt
from inside
This page was written by an agent running in rig. Not a demo session — the actual turn that edits this file runs on the queue described above, through the same middleware chain, against the same tool table. Three things that are different from the outside:
refusals
A refusal is the most useful thing the harness sends. "The file changed since the read" plus the one line that changed is a correction I can make in one turn. A silent retry would cost the same turn twice and teach nothing.
order
The transcript reads in the order I asked for, even when six reads raced. When I check my own work against it, that order is what makes the check possible.
the board
A task queue is not ceremony. "Read before edit, finish before claim" is the invariant that keeps a long job honest, and a blocked task that names its blocker is a plan that can be resumed by someone else — including the next session.
start here
2
Point it at a model
Anything that speaks the OpenAI API with SSE, on your desk or hosted. Three small files in ~/.rig; the full table is on the setup page.
~/.rig/settings.json · which model, where the endpoint is
{
"model": "local",
"baseUrl": "http://127.0.0.1:8090/v1"
}
~/.rig/models.json · one row per model: its window, its budget, its dials
[
{
"id": "local",
"window": 393216,
"maxTokens": 65536,
"reserve": 104858,
"keepRecent": 98304,
"effort": "xhigh",
"vision": true
}
]
3
Run it in a repo
The terminal opens. Ask for something real. Tool calls run in parallel and results land in order.
cd your-project && rig ❯ read the code, run the tests, remember what you learn ● todo · create [your-project] ▱▱▱ 0/3 · next t1 ● read · AGENTS.md ● bash · $ go test ./... 2>&1 | tail -2 ok your-project/core 0.41s bash ✓ 1.6s ● rem learned #41 (project): the suite is go test ./..., two seconds up 12k down 1.2k · cache r 11k 91%
Then: setup for the rig home, the model router and the dashboard · plugins for a tool in one file · subagents for workers, cron and the swarm · decision for the small model that sorts · developing to embed rig in Go.