Agent orchestration, designed for Rex.
Threads and named agents, back in the terminal.
Install · Quick start · Docs · axel.md
# Two agents: one builds, one reviews with another model
axel agent new terra codex
axel agent new opus claude/opus
# A thread: terra does the work, then hands the diff to opus
axel thread new --agent terra "add retries to the webhook sender, then ask @opus for a review"Or run axel in Rex and type the same thing into the launcher that floats over your window.
The thread keeps going when you close the laptop, and you can pick it up from any machine.
A thread is an intent and everything done about it. It outlives the agent's process, the pane and the machine: run several at once, resume tomorrow, settle it when it's done. Every change is a signed event, so copies on other machines merge.
A team of specialists instead of one assistant that knows everything. terra builds with a
few skills for your stack; opus reviews with another model. Each has its own Ed25519 key,
permissions, budget and inbox, and loads only its own skills.
axel agent new opus claude/opus --skills review
axel send "@opus please review the diff"Agent apps rebuilt the terminal because it couldn't keep work alive, show who's waiting on you, reach your other machines, or even scroll. Rex fixes all of that, so Axel is just a program in a pane: threads stream as plain output and scroll like anything else, and status shows up in Rex's tabs. Why Rex →
Bring the harness you already use, and pick its model in the same word: claude/opus,
codex, goose, cursor/sonnet. Axel drives Claude Code and Codex over the Agent Client
Protocol with built-in adapters (no Node), and OpenCode, Goose, Cursor, Pi, Oh My Pi, Devin,
Grok Build, Kimi Code, Amp, Hermes Agent and OpenClaw through their own ACP modes. Any other
harness runs in its own pane. Status comes
from hooks and the protocol, never from scraping a screen.
Your Mac mini on the tailnet is a host. Agents run there, and their keys never leave home: the host gets a short-lived grant per thread. Remote hosts →
axel host add miniThe project's context and the skills its agents use, in one file that CLAUDE.md and
AGENTS.md point at. Skills can be local folders or links from skills.sh and GitHub, pinned
in AXEL.lock. The AXEL.md file →
skills:
- ./skills
- https://skills.sh/vercel-labs/skills/find-skillsAgents work without asking by default. Axel's guard still refuses irreversible commands, and a budget caps what each agent spends. Want a say? Give an agent a stricter mode. Permissions and budgets →
curl -fsSL https://axel.md/install | shor with Homebrew:
brew install scarce/taps/axelThen run axel in a Rex terminal. The first run checks your machine and helps you create
your first agent. Every commit on main that passes CI is a release, so run the script
again or brew upgrade to update.
You'll need Rex and a harness: Claude Code, Codex, OpenCode, Goose, Cursor or another. Details in the installation guide.
- Quick start: your first agent and thread
- Threads and agents
- Agents working together
- Keyboard and command line
- For agents and LLMs: llms.txt, every page in
llms-full.txt, and an Agent Skill that installs and runs
Axel for you:
npx skills add https://axel.md
just install # release build, linked into ~/.local/bin
cargo test --workspaceThe design lives in docs/DESIGN.md, the wire formats in
docs/CONTRACTS.md, and the website in web/.
An agent runs on a harness: a coding agent's own CLI, which Axel drives over ACP. Install the
CLI (and its ACP adapter, for Pi and Amp), log it in once, then name it when you create the
agent, optionally with a model after a /. axel setup lists the harnesses it finds.
axel agent new atlas claude/opus # Claude Code, on Opus
axel agent new nova codex/gpt-5.5 # Codex
axel agent new vega pi # Pi: npm i -g @earendil-works/pi-coding-agent pi-acp,
# then pi auth login anthropic (or an API key)
axel agent new lyra opencode # OpenCode, Goose, Cursor, Amp… work the same way
axel agent edit vega cursor # move an agent to another harness; key and history stay