The Slash Is Load-Bearing

Someone described their setup like this:

There are two different features in that sentence. They are spelled almost identically, they live in different places, and they do not do the same job.

claude agents is a shell command. It opens a full-terminal view of every background session you have running. That is the thing that stops terminal-juggling.

/agents is a slash command inside a session. It deals with subagent definitions, which never appear in that view at all. And as of v2.1.198 it does not even do what the tutorials say it does.

The documentation is blunt about this in a way documentation rarely is:

When the docs stop to tell you two things are not the same thing, it is because everybody keeps assuming they are.

Five surfaces, not one feature

"Multi-agent" has become too vague to be useful. Claude Code now ships five distinct ways to have more than one thing running, and they differ in who coordinates the work and who talks to whom.

These are not five maturity levels of the same idea. Teams are not better subagents. Background sessions are not lighter teams. Picking by agent count is the wrong abstraction entirely.

First, the slash command lost its wizard

Almost every tutorial you will find describes running /agents to open an interactive interface with a Library tab for creating subagents and a Running tab showing live ones.

That interface was removed in v2.1.198. Running /agents now prints a notice pointing at the file locations. Nothing else. The subagent files, the frontmatter fields and the .claude/agents/ and ~/.claude/agents/ directories are unchanged; only the terminal wizard is gone.

You create subagents by asking Claude to write the file, or by writing it yourself. That is now the whole workflow, and it tells you something about the product's direction: configuration is moving from menus into conversation and plain files.

Subagents are context management

A subagent runs inside one session with its own context window, system prompt, tool allowlist and permissions. It does bounded work and hands back a summary. The parent is a hub; subagents are disposable leaves that never talk to each other.

The benefit is primarily context hygiene. Search results, logs and exploratory dead ends stay out of the main conversation, so you do not drag every intermediate token through the rest of the session. Parallel delegation can save wall-clock time as well, but that is a secondary effect, not the reason to reach for one.

Two current details that most playbooks still get wrong.

The first: Explore no longer means Haiku. It used to always run on the cheap model. Since v2.1.198 it inherits the main conversation's model, capped at Opus on the Claude API. If you want exploration forced onto something cheaper, you now have to define your own subagent named Explore with model: haiku — a user or project definition overrides the built-in.

The second: Explore and Plan deliberately skip your CLAUDE.md and the parent's git status to stay fast. Every other subagent loads both. If you have a repository-critical invariant living only in CLAUDE.md, the two agents most likely to go wandering through your codebase have never read it.

Definitions are Markdown with YAML frontmatter:

---
name: refactorer
description: Applies mechanical refactors across many files
tools: Read, Edit, Grep, Glob, Bash
model: sonnet
isolation: worktree
---

Apply the requested refactor across every affected file, then run the tests
and report the results.

Resolution runs highest to lowest: managed settings, the --agents CLI flag, project .claude/agents/, user ~/.claude/agents/, then plugins.

claude agents is the actual terminal-juggling fix

Run claude agents and you get one screen showing every background session grouped by state: working, needs input, idle, completed, failed, stopped.

You dispatch from the shell:

claude --bg "investigate the flaky test in the settings module"
claude --agent code-reviewer --bg "address review comments on PR 1234"
claude --bg --name "flaky-test-fix" "investigate the flaky test"

Or from inside a session. /background (or /bg) moves the current conversation to the background. /fork copies it into a new background session while the original keeps running. That distinction is operationally useful: backgrounding moves your attention, forking creates a second line of work from the same context.

The part that makes it a supervision tool rather than a list is that you can answer a blocked session without attaching to it. Space opens a peek panel showing the latest output or the question it is stuck on; you type a reply and press Enter. Number keys answer multiple-choice prompts. Tab offers suggested replies. Enter attaches fully, left-arrow on an empty prompt detaches.

The whole lifecycle also exists as plain commands, which matters if you want to script any of it:

claude agents --json          # list every session as JSON
claude attach <id>            # open one in the terminal
claude logs <id>              # recent output
claude stop <id>
claude respawn <id>
claude rm <id>
claude daemon status
claude daemon stop --any

You can set defaults for everything you dispatch: claude agents --permission-mode plan --model opus --effort high. Inside the view, /model opus changes the dispatch model and /model default resets it. Those settings persist when sessions are respawned.

Sessions are local. They survive sleep and die on shutdown. This is a local process supervisor, not a durable job system, and it is worth holding that expectation correctly before you put anything important in it.

Worktrees make it safe, and one behaviour will eat your work

Before a background session edits anything, Claude Code moves it into an isolated git worktree under .claude/worktrees/. Parallel sessions read the same checkout and each writes to its own. That is the right default and you should not turn it off, though you can with {"worktree": {"bgIsolation": "none"}}.

The isolation is enforced, not advisory. Claude Code blocks four things while a session is in a worktree: edits targeting the main checkout, commands whose working directory resolves there, git redirected back via -C, --git-dir, GIT_DIR or a cd, and any command whose shape it cannot statically trace — brace expansion, heredocs with unquoted delimiters. That last check cannot be disabled.

You can run your own sessions this way too. claude --worktree feature-auth creates .claude/worktrees/feature-auth/ on a branch named worktree-feature-auth. Omit the name and you get something like bright-running-fox. You can even branch straight from a pull request with claude --worktree "#1234".

Two configuration details worth knowing before you need them. A worktree is a fresh checkout, so your gitignored .env is not in it — put the paths in a .worktreeinclude file and they get copied into every worktree Claude creates. And new worktrees branch from the remote default branch, not your current work; set worktree.baseRef to "head" if you want them to carry your unpushed commits.

Worth being precise about the other cleanup path, because it is gentler: a periodic sweep removes subagent and background-session worktrees older than your cleanupPeriodDays, but it skips any worktree that still holds work — changed files, untracked files or unpushed commits. It also never touches worktrees you created yourself with --worktree. The sweep is careful. The session deletion is not.

And note the asymmetry nobody mentions: agent view moves every dispatched session into its own worktree automatically. Agent teams do not isolate teammates at all. In a team you are responsible for partitioning the work so two teammates never own the same file.

Agent teams buy coordination, not parallelism

Teams are experimental and disabled by default. Without CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 no team is created, no directories are written, and Claude will not spawn or even propose teammates.

One session is the lead. Teammates are full independent sessions that message each other directly and work from a shared task list with dependencies. Locking applies to task claims, so two teammates cannot grab the same item — it does not protect your source files, a distinction worth holding on to. The mailboxes are JSON files at ~/.claude/teams/{team}/inboxes/{agent}.json.

The shape is rigid in ways that matter. One team per session. No nested teams. The lead is fixed for the session's lifetime and cannot be transferred. In-process teammates are not restored by /resume or /rewind. Task status can lag and block dependents. That makes teams a fixed-topology coordination tool, not a general orchestration primitive.

The docs recommend three to five teammates, and are refreshingly direct about the reason: if you have fifteen independent tasks, three teammates is still the right starting point. Their phrasing is that three focused teammates often outperform five scattered ones, because coordination consumes attention that could have been work.

The genuinely interesting use case is adversarial, not parallel. The documented example spawns five agents on competing hypotheses for a bug and tells them to argue: to try to disprove each other's theories rather than confirm their own. Sequential investigation anchors on the first plausible explanation. A theory that survives four peers actively trying to kill it is much more likely to be the real root cause. That is a genuine capability, and it is not something subagents can do, because subagents cannot talk to each other.

One boundary they got right

When one agent messages another, Claude Code tells the receiver the message came from another Claude session — not from you. A teammate cannot approve a permission prompt on your behalf, and a teammate denied an action cannot route it through a peer to get around the check.

In auto mode a classifier treats a relayed approval claim as untrusted input and reviews every inter-agent message before delivery, including structured ones like shutdown requests and plan approvals.

This matters more than it sounds. Teams produce social-looking interactions, and an agent saying "the user approved this" is still just model output. Coordination can distribute information and work. It cannot distribute your authority.

The surface almost nobody mentions

Dynamic workflows are a script that runs many subagents and cross-checks their results. The distinction from everything above is that the plan lives in code rather than in Claude's turn-by-turn judgment. You get deterministic control flow — loops, conditionals, fan-out — over non-deterministic workers.

That is the right tool when a job outgrows a handful of subagents or needs more than one pass: a codebase-wide audit, a 500-file migration, research verified against itself, a design drafted from several angles and scored.

There is also a packaged version. /batch is a skill that splits one large change into five to thirty worktree-isolated subagents that each open a pull request. Not a separate coordination style — just subagents and worktrees with the wiring already done.

And for checking on things, the commands split the same way the surfaces do: claude agents for background sessions, /tasks for anything running in the background of the current session, /workflows for workflow runs.

Concurrency has a linear bill

Nobody states this plainly enough, so here it is with the numbers the docs actually publish.

For scale: across enterprise deployments the documented average is around $13 per developer per active day, and $150 to $250 per developer per month. A ten-session dashboard is not a rounding error on that.

Agent view improves observability. It does not create free concurrency. The question is never whether another worker could do something — it is whether the expected reduction in wall-clock time, or the improvement in decision quality, justifies another session's worth of tokens.

A clean dashboard disguises waste beautifully. Ten neatly labelled sessions in tidy rows are still ten sessions.

How to actually choose

Not by how parallel the work looks. By three questions, in this order.

Most work belongs in the first row. A repository search, a dependency investigation, a log analysis, a test-failure diagnosis — none of that needs a society of agents. It needs one narrow worker that eats noisy context and returns a compact answer.

Which leads somewhere slightly uncomfortable: for most engineers, getting good at subagents is the whole return, and teams never become necessary. Context isolation pays on nearly every substantial task. Peer-to-peer coordination pays on a narrow band of genuinely adversarial work, and it is an expensive way to discover your work was not in that band.

Organising with one vendor, coding with another

Back to the quote that started this. Using Claude's agent view to organise work while delegating the actual code generation to Codex is not a contradiction or a hedge. It is a reasonable architecture, and it is worth naming why.

To be precise about what this is and is not: agent view supervises Claude sessions, not Codex ones. They do not appear on the same screen. What is shared is the repository and the work itself — one system holds the plan and the state of play, the other produces the diffs. The organiser needs visibility into work state, blocking questions, task boundaries and handoffs. The implementer needs repository context, editing discipline and test feedback. Different jobs, different failure modes, and nothing requires them to come from the same vendor.

I wrote about the inverse arrangement in Two Models, One Branch — Claude writing code, Codex reviewing it with fresh eyes. What is notable is that the division of labour is not fixed, and for some setups it has now flipped.

The real risk in a mixed setup is not heterogeneity. It is pretending the two systems share implicit state. Name what crosses the boundary — a task specification, a branch, a patch, test output, a review verdict. If you cannot name the handoff artifact, the architecture is running on context that does not exist.

The skill moved

Using a coding agent used to mean writing a good prompt and judging the answer. That is no longer the interesting part of the job.

The work now is designing a distribution topology. What context stays isolated. Which workers need to hear from each other. Where human approval has to stay visible. Which tasks deserve a full session and which deserve a leaf. What artifact marks a safe handoff. When work becomes committed and recoverable. How much quota the whole shape is allowed to burn.

The product changes are at least consistent with that reading, though I am reading intent into them. The /agents wizard got deleted because configuration belongs in conversation and files, not menus. Agent view turned session management into an operational surface with states and a peek panel. Teams exposed coordination as an explicit, experimental, off-by-default system, which is the honest way to ship something that expensive.

And when someone tells you they want agents so they can stop juggling terminals, send them to claude agents — without the slash.