When to Reach for Claude Code's /batch (and When claude-squad, Agent Teams, or Superpowers Wins)

Every walkthrough of Claude Code's /batch frames it as a productivity multiplier: 30 pull requests in a morning, a sprint compressed into a few hours of agent time, a Solid-to-React migration the docs themselves use as the canonical example. The framing buries the question that decides whether the command will help you, which is whether your work is the work /batch is good at.

This post is the reference. What /batch does, when to reach for it, when to leave it alone, how it compares to claude-squad, Anthropic's Agent Teams and Agent SDK, and Superpowers v5, and the failure modes that did not make the release notes.

What /batch does

/batch shipped in Claude Code v2.1.63 on February 28, 2026 alongside /simplify. The official commands reference defines it as a single sentence of intent followed by a fan-out:

Orchestrate large-scale changes across a codebase in parallel. Researches the codebase, decomposes the work into 5 to 30 independent units, and presents a plan. Once approved, spawns one background agent per unit in an isolated git worktree. Each agent implements its unit, runs tests, and opens a pull request.

Three details determine how the command behaves on your codebase. First, /batch is a bundled skill, not hardcoded CLI logic. Anthropic's own skills documentation describes bundled skills as "prompt-based: they give Claude detailed instructions and let it orchestrate the work using its tools." That means the orchestration logic lives in a prompt, and the prompt's behavior tracks the current model's quality, not a deterministic specification.

Second, the worktree isolation is filesystem-only. Each unit runs in .claude/worktrees/<name>/ on its own branch, branched from origin/HEAD. .worktreeinclude copies gitignored files like .env into each worktree. Cleanup is handled automatically when no changes are present. What worktrees do not isolate: the database your agents are connecting to, the Redis instance they share, the queue topology they all speak to.

Third, the command requires a git repository and uses /batch migrate src/ from Solid to React as its canonical example. Both the example and the underlying mechanics work as documented. The question is what they cover.

When to reach for it

/batch earns its 5-30 worktree fan-out on a narrow band of work. The two practitioners who covered the command in its first weeks named the band the same way. Sean McLellan at BaristaLabs, writing on launch day, described it as appropriate for "straightforward, parallelizable" work and warned against using it on "core business logic." Bozhidar Batsov, RuboCop's author, wrote two weeks later that /batch is best for "repetitive, pattern-based changes: apply this specific change to every place that matches this pattern." Anything else risks the command flattening a coherent design into 30 disconnected PRs.

The work that fits:

• Pattern-based migrations across many call sites: lodash to native, class components to functional with hooks, error response shapes, logging utility swaps
• Mass naming or convention unification, where the transform is mechanical and the test suite catches violations
• Adding the same boilerplate to many files: type annotations on untyped exports, JSDoc on an interface, telemetry instrumentation that follows a fixed shape
• Anything that already passes a "would I write a codemod for this if I had two free days" test

Simon Willison's parallel coding agents observation from October 2025 still applies: the bottleneck for parallel agent work isn't the agents, it's the human reviewing what comes back. The criterion that holds across all four bullets above is review effort. When the review per unit is mechanical and bounded, fan-out helps. When it isn't, fan-out makes the reviewer the new bottleneck.

When to leave it alone

/batch is the wrong tool when any one of the following is true.

The sharper version of the rule is the inverse: /batch works when the changes are independent, mechanical, and bounded. As soon as one of those words breaks, reach for something else.

How /batch compares to alternatives

/batch is one answer to the larger category of sub-agent orchestration, and understanding how it solves that problem relative to other approaches will help you pick the right tool. There are three useful contrasts. Each one calibrates the decision.

Same primitive, different supervision. claude-squad (v1.0.17, March 2026, 7,300 stars) uses git worktrees the way /batch does, but runs its sessions in tmux rather than /batch's background subagents, and flips the supervision style. Where /batch decomposes a plan and lets you walk away while agents open PRs, claude-squad puts a TUI in front of you with approval-before-apply on every change. Conductor is the Mac GUI version of the same posture; parallel-code is the cross-platform Electron version with optional Docker sandboxing. Pick /batch when the work is mechanical enough to walk away from. Pick claude-squad or Conductor when you want per-step human judgment.

Same vendor, different abstraction. Anthropic ships two other native parallel options. Agent Teams (experimental, requires Claude Code v2.1.32+ and an env flag) gives a lead session a shared task list and a SendMessage mailbox; teammates can self-claim work and message each other directly. The Claude Agent SDK gives you a query() primitive you can dispatch concurrently from your own code. Agent Teams fits when teammates need to coordinate during the work. The Agent SDK fits when you need fan-out inside CI or your own automation rather than from an interactive Claude Code session. Both are covered in more depth in The Four Sub-Agent Orchestration Patterns That Cover 90% of Production Claude Workloads.

Opposite philosophy. Superpowers v5 (178,000 GitHub stars, 476,245 Anthropic Marketplace installs as of May 2026) considered the same problem /batch solves and went the other way. The plugin ships exactly one parallel-orchestration skill, dispatching-parallel-agents, and scopes it to debugging triage. Its mandatory execution skill, subagent-driven-development, lists "Dispatch multiple implementation subagents in parallel (conflicts)" under its Never: red flags. Issue #469, proposing agent-teams-style parallel plan execution, was closed as "duplicate, not planned." Pulumi's April 13, 2026 framework comparison describes Superpowers as a "single mega-orchestrator" that runs sequential per-task subagents through two-stage review. /batch is the opposite shape: fan-out automation. The two cultures pick opposite trade-offs on the same problem.

Three lenses for that table. If mechanical fan-out throughput on well-understood work is your bottleneck, /batch. When verification quality is the constraint, reach for the Superpowers path. And if the harder problem is supervising parallel work in flight rather than reviewing what came back, claude-squad or Agent Teams.

Failure modes the docs do not lead with

Three failure modes are in the public record but not in the launch announcement.

Start with the architectural one. Because /batch is a prompt-based skill rather than hardcoded logic, its reliability tracks current model behavior. Not a setting, not a config flag. Between February and April 2026, Claude Code went through a documented quality regression. Fortune's April 24 coverage, corroborated by Anthropic's own April 23 postmortem, named three specific engineering changes. TrustedSec, quoted in the Fortune piece, measured a 47% drop in code quality.

The pattern in GitHub Issue #42796 is the load-bearing data point. The reporter, running 5 to 10 concurrent Claude Code sessions, watched the read-to-edit ratio collapse from 6.6 to 2.0, "edit without read" behavior rise from 6.2% to 33.7%, and the daily cost rate jump 122-fold from February to March. That concurrent-session pattern is exactly what /batch automates at scale. Boris Cherny, Claude Code's creator at Anthropic, closed the issue on April 6 with an official response.

Next, the Issue #41411 hook bypass. Sub-agents that generate automation scripts can route around CLAUDE.md rules and PreToolUse hooks, because those hooks govern interactive Bash, Write, and Edit calls inside the session, not the external API calls inside the script the agent wrote. The reporter wasted around two hours of GPU time on 60 incorrectly-parameterized video generations. For /batch, the implication is direct: worktree isolation protects your codebase from cross-agent interference, but if any of your units generate scripts with side effects, that protection doesn't extend to whatever those scripts do. The wider context for why CLAUDE.md and hooks aren't interchangeable safety layers is in Where Does That Rule Go?.

Then there's rate-limit amplification. The Register reported on March 31, 2026 that one developer reverse-engineered what they described as a session-level caching bug "silently inflating costs by 10-20x." A /batch run with 5 to 30 concurrent agents amplifies any session-level cost bug multiplicatively. None of it is permanent. But the regression timeline is the kind of thing worth checking before kicking off a fan-out you can't stop.

A pre-flight checklist

Run through these before kicking off /batch on real work.

1. Are the units truly independent? If unit B needs a utility unit A creates, /batch can't sequence the dependency.
2. Is the change pattern-based or coherent-redesign-shaped? /batch flattens coherent designs into 30 disconnected PRs.
3. Do any units touch shared services? Database migrations, queue topology changes, and Redis schema edits fight each other across worktrees.
4. Have you tested the transform on one file by hand first? The first run isn't the run to discover that the prompt's decomposition logic misread the intent.
5. Have you checked the Claude Code changelog and recent GitHub Issues for active regression advisories in the past 30 days? Skill behavior tracks model behavior.
6. Do any units generate scripts with side effects? If yes, the CLAUDE.md-and-PreToolUse-hooks safety layer doesn't load-bear inside what they generate.
7. Do you have reviewer capacity for 5 to 30 PRs landing within the next 48 hours? Fan-out moves the bottleneck to review.

If every answer is yes, /batch is a productivity multiplier. If two or more are no, sequential work in a single session is faster end-to-end, even though it looks slower per agent-minute.

The right framing isn't whether /batch is good or bad. The right framing is whether the work in front of you is the work /batch is good at. For the adjacent audit pattern that catches CLAUDE.md, hooks, and subagent drift before a Claude Code upgrade ships, see the Opus 4.7 compatibility scanner.

If you are scoping a Claude Code rollout where /batch is on the table, a 15-minute call is the fastest path to a defensible decision; the advisory tier is the structured next step.