# AgentSwitch: FAQ

## Questions

### Why should I use AgentSwitch?

ax is for people who run more than one CLI coding agent, run tasks long enough to lose track of, or repeat the same agent workflow. It gives you one place to launch, watch, detach, reattach, and coordinate agent sessions across projects, and its [shell verbs](manual.html#verbs) let you compose automations out of plain shell. If you run a single agent interactively and never lose track of it, you may not need ax.

### Can I run all my agents through ax?

Yes, that is how it is meant to be used. You bootstrap ax once by pasting [a prompt](index.html#hero) into an agent you already run, and after that ax is the single place your agent work flows through. It coordinates every harness the same way, so one coordinator you talk to can launch, watch, steer, and verify sessions across all of your projects, and every session stays in one searchable picker. Instead of juggling a separate agent per project, you drive them all from one place.

### How is ax different from an agent harness?

A harness (Claude Code, Codex, pi, opencode) is the agent. It holds the model, the tools, and the context, and it does the work. ax does none of that. ax is the control plane around harnesses: it launches them, keeps them alive when you detach, lists and searches every session, and composes and coordinates many at once. It reads the transcripts harnesses already write. It is mechanism around the harness, not a replacement for it.

### Why not just use my harness's built-in subagents?

You can, and for a quick one-off they are simpler. But that orchestration lives inside the harness and is opaque. You cannot see how a subagent was spawned, watch it, steer it, read its transcript, or change the coordination logic.

ax moves the control structure out of the harness into a separate program. Any harness drives it the same way, every session is a transcript you can read, attach to, and resume, and the [recipes](recipes.html) and the [coordinator behavior](manual.html#coordinator) are plain files you edit. Harness makers keep folding orchestration into one tool. ax keeps that layer separate, visible, and yours, so the harness stays a good agent and the control plane stays something you own.

### Why does ax not have an MCP server?

Because ax is already a CLI, and coding agents already run CLIs through their shell. An MCP server would wrap the same verbs in a protocol layer that costs more than it returns. MCP tool schemas sit in the model context on every turn, thousands of tokens whether the tools are used or not, while `ax help` is about a thousand tokens read once on demand. CLI output pipes and chains through the shell, while MCP results have to round-trip through the model. And the shell is the one boundary ax already fences, so a second protocol would mean a second permission model.

The one case MCP would help is driving ax from a client with no shell at all, which no coding agent needs today. If that changes, an MCP server is easy to add, because the verbs are already the interface.

### Is ax free or a subscription?

ax is free and open source under the MIT License. It runs on your machine. There is no service, no account, and no ax subscription. Sessions use your harness's own auth: your existing subscription by default at no extra per-token cost, or pay-as-you-go API billing when you launch with `--api`. ax adds no cost of its own.

### What is composition?

Building a workflow by combining ax's small verbs (launch, read, wait, result, and the rest) with ordinary shell tools: pipes, loops, cron, `jq`, exit codes. Every verb prints ids and JSON on stdout and returns a meaningful exit code, so agent sessions plug into tools you already have. You assemble a workflow from parts instead of using one monolithic platform feature. The [recipes page](recipes.html) shows this in practice.

### Is ax more or less efficient than using a harness directly?

For a single interactive task, ax adds almost no overhead, and it does not make the model faster or cheaper per token. It makes you more efficient in three cases: when you run many sessions in parallel, when you must not lose long-running work (the session holder survives detach), and when you automate a repeat workflow (compose it once, run it on cron) instead of babysitting an agent by hand. On cost, the [cost-tiered routing recipe](recipes.html#cost-routing) can reduce spend by escalating to a stronger model only when a cheaper one fails.

### Why does the separation of concerns between ax and the harness matter?

The harness owns the agent: model, tools, context, permissions. ax owns the control plane: launch, persist, list, compose, coordinate. This split keeps ax thin and harness-agnostic. It works with any harness, and a new one takes one [`[[harness]]` config block](manual.html#configuration-file). It never reimplements agent internals, so your auth and permissions stay in the harness where you configured them. And the stable mechanism outlives the evolving agents. If ax tried to be the agent too, it would lock to one vendor and rot as harnesses change.

### Do I need tmux or zellij?

No. The no-mux session holder is the default, with zero external dependencies. Launch, detach, monitor, and reattach all work on a plain terminal. A multiplexer is optional: set `mux = "tmux"` or `mux = "zellij"` and ax drives it natively, with a real window or tab per session. See the manual's [multiplexer backends](manual.html#multiplexer-backends) chapter.

### Which harnesses does ax support?

Claude Code, Codex, pi, and opencode are built in and work with no config file at all. Any other CLI agent can be wired in with one `[[harness]]` config block that tells ax where its transcripts live and how to launch and resume it. See [supported harnesses](manual.html#supported-harnesses) in the manual.

### Does ax send my code anywhere?

No. ax is daemonless and runs locally. There is no ax service and no account. Your code and transcripts go only where your harness sends them. Remote sessions travel over your own transport command, usually ssh, and that command carries its own auth. The one network call ax itself makes is `ax models update`, which fetches model price and context data from models.dev when you run it. Even that can be disabled: set `offline = true` in the config (or `AX_OFFLINE=1`) and ax makes zero outbound connections, running on cached or bundled model data.

### What is the difference between a recipe and a behavior?

A recipe is a shell workflow that composes ax verbs from the outside: a script, a loop, a cron job. The [recipes page](recipes.html) collects them. A behavior is a prompt file passed with `--behavior` that shapes how one session acts from the inside, like the [coordinator behavior](manual.html#coordinator) that tells a session to split work and launch workers. Behaviors live in the repository's `behaviors/` directory.

### Are the recipes a fixed set?

No. A recipe is just a shell script plus a behavior file, so the ones shipped are examples, not a closed list. The [verbs](manual.html#verbs) are a small language you compose your own workflows in. Write recipes for your own work, share them, and build on other people's. The workflows worth having are the ones people write, not the handful we ship.