Skip to main content
One of Dispatch’s core strengths is parallel execution. Multiple workers can run simultaneously, each with their own full context window, while your main session stays lean.

​
Dispatching Multiple Independent Tasks

When tasks don’t depend on each other, dispatch them all at once: 
/dispatch three things:
1. use opus to do a security review of the auth module
2. use sonnet to write unit tests for the API endpoints  
3. use gemini to update the README with recent changes
Dispatch creates three separate plan files and spawns three workers: 
.dispatch/
  tasks/
    security-review/
      plan.md
      ipc/
    api-tests/
      plan.md
      ipc/
    update-readme/
      plan.md
      ipc/
All three run concurrently. Your main session is immediately free.

​
How It Works

  1. Dispatcher analyzes the prompt and identifies 3 independent tasks
  2. Creates 3 plan files — one for each task with its own checklist
  3. Spawns 3 workers + 3 monitors — all as background processes
  4. Returns control immediately — your session is idle while workers execute

​
Checking Status of Multiple Tasks

Ask for status on any or all tasks: 
/dispatch status

​
Status Response Example

Here's the current status:

● security-review (opus) — 3/5 items complete
  ✓ Scan for hardcoded secrets
  ✓ Review authentication logic
  ✓ Check dependency vulnerabilities
  ⋯ Audit SQL injection risks (in progress)
  ○ Write findings report

● api-tests (sonnet) — 2/4 items complete
  ✓ Write tests for /auth endpoints
  ✓ Write tests for /users endpoints
  ⋯ Write tests for /orders endpoints (in progress)
  ○ Run test suite and fix failures

● update-readme (gemini) — COMPLETE
  ✓ Review recent changes in git log
  ✓ Update README installation section
  ✓ Update README usage examples
  ✓ Commit changes

​
Understanding Task Independence

Tasks are independent when:
  • They work on different parts of the codebase
  • They don’t need results from each other
  • They won’t create merge conflicts

​
Good for Parallel Execution

/dispatch three tasks:
1. security review the auth module
2. write tests for the API
3. update documentation
These work on different areas and won’t conflict.

​
Bad for Parallel Execution

/dispatch two tasks:
1. refactor the database schema
2. update all database queries to use the new schema
Task 2 depends on task 1 completing first. Use sequential execution instead.

​
Sequential Dependencies

When task B depends on task A, dispatch them sequentially: 
/dispatch refactor the database schema to use UUIDs
Wait for completion, then: 
/dispatch update all database queries to use UUIDs

​
Alternative: Single Task with Sequential Steps

Or describe it as a single task with steps: 
/dispatch database migration:
1. refactor schema to use UUIDs
2. update all queries to use UUIDs  
3. write migration script
4. test migration on staging data
The worker handles the sequential flow within a single plan.

​
Real-World Parallel Example

Pre-launch sweep with 5 parallel tasks: 
/dispatch we launch Thursday, need a full pre-launch sweep:

1) security audit the auth flow (JWT, sessions, password reset) and the
   stripe payment integration. use opus, do it in a worktree

2) performance - load test the top 5 API endpoints, find N+1 queries,
   check db indexes on users/orders/products tables. sonnet in a worktree

3) frontend audit - accessibility (WCAG 2.1 AA), bundle size, flag any
   components missing error boundaries. dispatch sonnet

4) generate OpenAPI specs for every endpoint that's missing one. use gemini

5) error handling audit - find uncaught exceptions, missing try/catch,
   inconsistent error response formats across all API routes. sonnet, worktree
Dispatcher Response: 
All 5 workers dispatched with their monitors. Here's the summary:

Security (worktree):
  ● security-audit — Opus 4-6 (worktree): Full auth + payment security review

Performance (worktree):
  ● perf-audit — Sonnet 4-6 (worktree): API load testing + DB index review

Frontend (single worker):
  ● frontend-audit — Sonnet 4-6: Accessibility, bundle size, error boundaries

Docs (single worker):
  ● api-docs — Gemini 2.5 Flash: Generate missing OpenAPI specs

Error handling (worktree):
  ● error-handling — Sonnet 4-6 (worktree): Uncaught exceptions + error format audit

All running in background. Five workers, three models, three worktrees —
your session wrote five checklists and is idle. Dispatch more work or say
"status" anytime.

​
Task Isolation

Each worker has:
  • Own plan file — tracks its progress independently
  • Own IPC directory — handles questions/answers separately
  • Own context window — starts fresh, doesn’t share memory with other workers
  • Own output file — writes results to its own location

​
Example Task Structure

.dispatch/tasks/
  security-audit/
    plan.md       # Security review checklist
    output.md     # Security findings report
    ipc/
      001.question  # "Should I flag INFO level logs?"
      001.answer    # User's response
      001.done      # Worker acknowledged
  
  perf-audit/
    plan.md       # Performance review checklist
    output.md     # Performance findings report
    ipc/
      .done         # Completed without questions
  
  frontend-audit/
    plan.md       # Frontend review checklist
    output.md     # Frontend findings report
    ipc/
      001.question  # "Found 15 accessibility issues. List all?"
      # Waiting for answer...

​
Advantages of Parallel Execution

​
Your Session Stays Lean

Without dispatch: 
You: Do a security review, write tests, and update docs

Claude: [reads auth code, analyzes patterns, writes findings...]
        [reads API code, writes tests...]
        [reads git log, updates README...]
        
        Context: 50,000 tokens used
        Status: You're waiting, can't do anything else
With dispatch: 
You: /dispatch three tasks:
     1. security review the auth module
     2. write tests for the API
     3. update documentation

Dispatch: [writes 3 checklists, spawns 3 workers]
          Context: 2,000 tokens used
          Status: You're free immediately

Worker 1: [full context window for security review]
Worker 2: [full context window for test writing]
Worker 3: [full context window for docs update]

​
Faster Completion

Sequential (traditional):
  • Security review: 5 minutes
  • Write tests: 5 minutes
  • Update docs: 3 minutes
  • Total: 13 minutes (you wait the entire time)
Parallel (dispatch):
  • All three run simultaneously
  • Total: ~5 minutes (longest task duration)
  • You’re free the entire time

​
Fresh Context Per Task

Each worker starts with a clean slate — no context pollution from other tasks.
See the Error Handling guide for managing failures in parallel tasks and the Examples guide for more real-world scenarios.

Build docs developers (and LLMs) love

Get started for freeTalk to us