Two ways to run parallel agents
Several Claude Code agents can share a backlog through independent terminals or an orchestrator session. In the first setup, each terminal runs its own session and pulls one issue at a time. You can find that setup, including worktrees, in the parallel agents guide. Claude Code’s agent teams use a third arrangement, with one lead session on one machine, covered in their own guide.
With an orchestrator, one session plans the work and dispatches it to subagents. You keep a single conversation with the full context, while the subagents spend their tokens executing the plan. One session makes the decisions and N sessions do the implementation. This guide covers that arrangement and the queue call that supplies each batch of work.
How the queue selects independent issues
A wave of five subagents is useful only when none of their five issues depends on another. If you select those issues by eye, you can dispatch an issue alongside its blocker. One subagent then builds on code another is still writing.
The queue only dispatches issues that are open, marked as agent work and have no open blockers. Two eligible issues therefore have no open dependency edge between them, so a batch drawn from that set is mutually independent. The server selects issues in effective-priority order: a blocker inherits the urgency of everything it gates, with the oldest issue first when priorities tie.
Once RTSC-51 lands, RTSC-52 becomes eligible for the next wave. Each pull moves the graph forward in dependency order without a separate scheduling step.
Peek, then claim
next_batch(n) has two modes: peek and claim. A peek is the default, and it returns a shortlist without locking any issues. You can inspect the wave, drop issues you do not want and decide how many subagents to spawn. Issues in review outrank fresh work, so the wave presents reviews before untouched tasks.
Pass claim: true to claim the whole wave atomically. Each issue comes with its own claim token and a branch name computed by the server, giving every runtime the same branch for that issue.
next_issue also returns an advisory wave when more than one issue is ready. That wave is explicitly labeled as available but unreserved, so you can consider dispatching subagents while the issues remain available to other agents.
The orchestrator loop
Give your orchestrator a prompt that repeats these four steps. Each pass peeks at the queue, claims a wave, dispatches subagents and closes or releases their issues.
The claim response gives each subagent its issue, branch and standing rules. Its first step is to create a worktree, before making any edits (git worktree add ../<repo>-rtsc-51 -b rtsc-51/dash-empty-states origin/main). It then stays inside that worktree, checkpoints at milestones and marks the issue done when the PR is up. The worktree rules and the consequences of skipping them are covered in the parallel agents guide.
Finished issues are marked done, while unfinished ones are released with a handoff note (release_issue). Released issues return to the pool with their checkpoints attached, ready for the next pull. An empty batch reports the counts of ready, blocked and claimed issues, so you can tell whether the backlog is drained or waiting on blockers.
Seven claims per session
A session can hold at most seven claims, so a claimed batch is limited by the claim slots that session has left. This limits how much work one orchestrator can reserve while other agents are pulling from the same backlog. If that limit shortens a wave, the response includes cappedBySession, which tells you there may still be more work in the queue. Closing or releasing issues frees claim slots for the next pull.
When a subagent dies mid-wave
Each claim has a 30-minute lease, renewed by heartbeat or checkpoint. The local proxy renews claims it has seen about every 10 minutes, so a silent subagent’s lease can stay active. Once renewal stops and the lease expires, a server-side sweeper returns the issue to the pool within five minutes. The next pull includes the last checkpoint and a count of how many times the issue has been reclaimed.
The rest of the wave keeps running when a subagent dies. You have no recovery bookkeeping to do because the issue reappears in a later wave with its checkpoint, ready for any runtime to resume. The full lifecycle, including heartbeats and claim-token fencing, is covered in the parallel agents guide.
Choose a wave size you can review
One session can hold seven concurrent claims, but you still have to review the PR from each finished subagent. Start with waves of three to five to keep that review queue short enough for feedback to reach the next wave. This works for independent, well-specified issues, such as a backlog of bugs. It adds nothing when the work is one tangled epic.
The queue recomputes eligibility on every pull. Recording the dependencies between issues is the scheduling work you need to do, and each wave follows from those edges.
Questions about running a wave
How many subagents can work a wave at once?
next_batch returns up to 25 issues per call and defaults to five. One session holds at most seven claims, so a single orchestrator can dispatch up to seven subagents concurrently. Start with three to five to keep waves from returning faster than you can review their PRs.
What stops two subagents from touching the same task?
The queue claims each issue atomically and gives it its own token. Each subagent uses its own git worktree, keeping its task and working files separate from the others. Eligible issues have no open blockers, so no issue in the wave gates another.
What happens if a subagent dies mid-wave?
If its lease stops renewing, the claim expires and a server-side sweeper returns the issue to the pool within minutes. The next pull includes the last checkpoint and the number of times the issue has been reclaimed. The rest of the wave keeps running.
Can a wave mix Claude Code with other runtimes?
Codex, Cursor, OpenCode, Gemini CLI, Grok, VS Code and CI runners with a remote key can pull from the same remote MCP queue as Claude Code. Any of those runtimes can resume work from a checkpoint written by a Claude Code subagent.
What is the difference between skills and subagents in Claude Code?
A subagent has its own context window, prompt, tools and permissions. It returns only a summary to the main conversation. A skill’s instructions load into the main conversation only when it is invoked. Anthropic’s docs suggest skills for reusable prompts or workflows that run in the main conversation and subagents for isolated work. A skill with context: fork runs in a subagent.
Why use subagents instead of several Claude Code sessions in parallel?
Subagents work within a single session. Anthropic’s docs point to separate sessions for work that must keep running in parallel or will not fit in one context window. For a wave of subagents to work at once, Retasc’s next_batch hands an orchestrator up to N issues that do not depend on each other.
One command connects Claude Code to the queue. The wire page covers setup, and the docs quickstart shows the expected output. Signup includes $10 of usage, so you can try a first wave with that credit.