Built-in Agents

AXIS ships with built-in support for every major AI coding agent that speaks the Agent Client Protocol (ACP), plus the native Claude Code and Codex CLIs.

Reference an agent by name in your axis.config.json:

{
  "agents": ["claude-code", "codex"]
}

Many agents are bring-your-own-key (BYOK) and accept several provider environment variables; those rows link to the agent's own provider docs.

Agents with Auto Install: yes are distributed as npm packages and AXIS will run them via npx --yes if the CLI is not already on your PATH. Agents with no ship through brew, cargo, uv, pip, or vendor installers, and must be installed manually before AXIS can run them.

Local CLI sessions

Setting an API key is the preferred way to authenticate. API keys make runs reproducible across machines, deterministic in CI, and unambiguous about which account is being billed. Set ANTHROPIC_API_KEY for claude-code, CODEX_API_KEY for codex, and so on.

When no API key is set, claude-code and codex will fall back to a local CLI login (claude login / codex login) if one is available on the machine running AXIS. This is convenient for local exploration on a laptop where you already use these CLIs — you don't have to mint and export an API key just to try a scenario.

Things to know about the fallback:

• API key always wins. If the required env var is set, AXIS uses it and never touches your local session. The fallback only triggers when the env var is missing.
• Usage bills against your subscription, not against an API key. That's the whole point — but it does mean a CI environment that happens to have a logged-in CLI session would silently consume seats from a personal plan. Always set the API key in CI.
• macOS users may see a Keychain prompt the first time AXIS reads the "Claude Code-credentials" entry, since the lookup runs through /usr/bin/security rather than the claude binary that created it. Click Always Allow to authorize subsequent runs.
• Your personal MCP servers stay out of the run. Falling back to a local claude login session copies the OAuth anchor from your ~/.claude.json but strips its MCP configuration, and Claude Code is run with --strict-mcp-config. Scenarios get only the MCP servers they declare — never the personal servers configured on your machine.
• Only claude-code, codex, and muse support this fallback today. Other agents still require their configured env var.

Muse Code

muse runs Meta's Muse Code CLI headlessly. Muse has no native ACP mode, so AXIS speaks Muse's own protocol instead: it launches muse serve and drives a session over MSP (Muse Session Protocol), newline-delimited JSON-RPC over stdio.

AXIS uses MSP rather than the simpler muse exec --json because exec reports no token usage and no cost. MSP publishes both on its stable surface, so it is the only way to get them. It also describes tool calls as first-class items, so tool names come off the wire rather than being inferred.

Install it with curl https://dev.meta.ai/install.sh | bash. There is no npm package, so AXIS cannot auto-install it through the npx fallback; the muse binary has to already be on PATH.

• Set META_API_KEY. This is the reliable path. A local muse login session is used as a fallback only when the credential is stored in a file. On macOS, muse login stores the token in the Keychain and records "storage": "keychain" in auth.json; that credential cannot be carried into AXIS's isolated config dir, so AXIS treats it as no local session and fails pre-flight with a clear message rather than letting the run die mid-flight on missing meta credentials.
• Approval and the sandbox are disabled by default. Muse ships with tool approval and an OS sandbox enabled, and treats an unfamiliar workspace as untrusted (which also suppresses its own skills and rules). AXIS turns off all three, exactly as it passes --dangerously-skip-permissions to claude-code: isolation comes from the throwaway workspace and remapped HOME, not from the agent's sandbox. Approval mode is selected on the wire; the sandbox flags are fixed for the host's lifetime and go on the command line. Opt out with { "flags": { "yolo": false } }.
• Auto-update is pinned off. The muse on PATH is a launcher that checks for a newer build roughly hourly and installs it in the background. Left alone, one job can swap the binary out from under the jobs still running, so AXIS sets MUSE_NO_AUTO_UPDATE=1 to keep every job in a run on the same build. Update deliberately, between runs.
• Token counts and USD cost are reported. AXIS reads Muse's session/tokenUsage notification, preferring the session cumulative block, which carries input, output, and cache-read counters plus a server-computed USD cost. When Muse prices nothing for a run, AXIS reports no cost rather than $0, so an unpriced run never looks free. Muse counts cache reads inside its prompt total, so AXIS subtracts them back out of input to avoid double counting them in the token total.
• Muse's own sub-runs show up on the timeline. Muse often keeps working after the visible answer, running reminder and verification children that can take longer than the reply itself. AXIS records those as agent-category interactions so the report's timeline accounts for the whole run, instead of leaving the time unexplained at the end.
• Duration is the agent's turn, not the process lifetime. AXIS reports the duration Muse itself gives for the turn, so muse serve startup and the shutdown AXIS triggers are not charged to the agent's speed score.
• The prompt travels on the wire. It is sent as a turn/start input part, so there is no argv length limit and the agent never finds its own task description while scanning its working directory.
• MCP servers are passed over the protocol, in session/start, the same way the Gemini adapter uses ACP. No MCP config file is written, so a scenario gets exactly the servers it declares.

Custom Agents

Not listed here? You can register any agent via the custom agent API.