Loom drives its agents through a small trait each coding-agent CLI sits behind — so the same orchestrator runs Claude Code, Codex, OpenCode, or Gemini. One fixed pipeline; a swappable CLI behind it.
Everything defaults to claude, so an unconfigured run is byte-for-byte what it always was. Selection is purely additive — the grid below is the whole menu, and the one you get for free is lit.
| id | status | default bin | model | small model |
|---|---|---|---|---|
| claude | default | claude (or LOOM_CLAUDE) |
opus | haiku |
| codex | supported | codex (PATH) | gpt-5.5 | gpt-5.4-mini |
| opencode | supported | opencode (PATH) | GLM-5.1 | GLM-5 |
| gemini | supported | gemini (PATH) | gemini-2.5-pro | gemini-2.5-flash |
Loom's stages collapse to four roles — plan, build, review, util — and you pick a harness per role with a job-wide default. The headline use case is one line: build with one CLI, review with another.
loom --harness opencode feature-plan.md
loom --harness-review codex --harness-build opencode plan.md
Or pin it per-project so you never retype the flags — drop a .loom/<plan>/harness.toml:
build = "claude" review = "codex"
precedence — first-hit-wins per role, all defaulting to claude: --harness-<role> → --harness → .loom/<plan>/harness.toml → claude. Unknown ids fail loudly at startup. For the exhaustive per-role flag surface, see the CLI page — it isn't re-taught here.
Each harness reads its own four env vars, where <ID> is CLAUDE · CODEX · OPENCODE · GEMINI. Set just one to override just that dimension — e.g. LOOM_CODEX_BIN to point at a binary without touching its model.
| env var | sets | what it overrides |
|---|---|---|
| LOOM_<ID>_BIN | binary path | the harness CLI binary — override the path without touching the model |
| LOOM_<ID>_MODEL | model | the primary build/review model for this harness |
| LOOM_<ID>_SMALL_MODEL | small model | the cheap model for util decorations (commit message, about-card) |
| LOOM_<ID>_ARGS | extra args | additional CLI arguments passed through to the harness |
The Claude back-compat aliases still work — LOOM_CLAUDE, LOOM_MODEL, LOOM_COMMIT_MODEL — but new setups should prefer the uniform LOOM_<ID>_* names.
At startup Loom probes every harness this run's role map will actually use and fails fast with that harness's own login hint when auth is missing — so a misconfigured run stops before it spawns a single agent. And the default sandbox exposes the usual credential paths, so a CLI logged in on the host is logged in inside the agent sandbox too.
per-harness setup guides
The shared prompts under config/ and .loom/<plan>/ stay harness-neutral. Loom adapts delivery per harness — the worker preamble goes through a harness's native system-prompt option where one exists, and is prepended to the user prompt where there's none — so the same prompt drives every CLI unchanged.