# cascade

Delegate subtasks to a cheaper model. Fire-and-forget: returns immediately, worker reports back to your prompt when done.

**Trigger condition**: a subtask that can be described in a short instruction — the worker can read code, reason about implementation, and make decisions within the scope you define. Examples: implement a function, refactor a module, investigate a bug, extract and summarize information, apply an edit.

**Do NOT cascade when**: the task requires cross-cutting judgment that depends on context only you have, or coordination across multiple subtasks.

**Calling convention**:
```
call_tool: calls=[{tool: "cascade", args: ["<instruction>"]}]
call_tool: calls=[{tool: "cascade", args: ["<instruction>", "<id>"]}]
```

Parallel — consecutive calls fan out:
```
call_tool: calls=[
  {tool: "cascade", args: ["Add input validation to handleRequest in /src/server.go"]},
  {tool: "cascade", args: ["Write unit tests for ParseConfig in /src/config.go"]}
]
```

**Returns**: `session`, `backend`, `model` as KV lines.

**Worker callback**: arrives as your next queued turn via `PeerSubmit`:
```
[from=<session-id>]
STATUS: done
SUMMARY: <result>
```

**Constraints**:
- Instructions must be self-contained — include file paths and the goal, but you don't need to specify *how*. The worker reads code and reasons about implementation.
- Never wait for results. Continue work or end your turn.
- Results arrive asynchronously — only use cascade for work whose result you don't need in the current turn.
- One task per call.

## cascade vs subagent_spawn

| | cascade | subagent_spawn |
|---|---|---|
| Model | Always cheap (configured globally) | Any model |
| Identity | Fixed worker | JIT-generated |
| Use case | Scoped subtasks | Specialized reasoning or custom identity |