Warp

Warp is a terminal and agentic development environment with three layers of multi-agent support. Locally, you run several agents yourself: Warp Agent or other CLI agents in tabs and panes, optionally each in its own Git worktree. Warp detects supported CLI agents and adds notifications, code review and rich input around them, but coordination is by the person, with task ownership, branches and validation commands assigned in the prompts.

The Automation Platform adds orchestration. A parent agent decides what work is needed, spawns child agents with their own prompt, environment and optionally a different model or harness, and merges results. Children do not spawn children, so orchestrations are one level deep. Parent and child can be local or cloud in four combinations, and each run has its own lifecycle, transcript and credit usage. Coordination goes through a durable, server-backed message bus with an inbox per agent, plus lifecycle events (in progress, succeeded, failed, blocked, error, cancelled). Documented patterns include supervisor and worker, fan-out and fan-in, critic and verifier, review swarm, DAG and swarm.

Warp Factories sit above this: a factory is a deployed set of named agents and integrations defined in code, with a foreman agent that orchestrates each task. Factories are in early access. Memory is per run, except Agent Memory, a research preview that carries knowledge across harnesses.

Both orchestration slash commands require explicit approval before any child launches: the agent proposes the number of children, prompts, environments and parallelism, and approving also approves the config every child inherits. In the Warp Agent CLI, each action type is set to always ask, always allow or let the agent decide; by default launching child agents always asks and file edits show a diff before applying. A blocked child run waits for command approval or a permission request, and you can switch between parent and child conversations from the pill bar. Cloud runs can be inspected and shared for review.

curl -fsSL https://app.warp.dev/download/agent-cli | bash

# Warp Agent CLI (macOS, Linux); Homebrew: brew install --cask warp-agent-cli
curl -fsSL https://app.warp.dev/download/agent-cli | bash
warp --version

# Start it; the first run shows a device-code login in your browser
warp

# Inside a Warp conversation, orchestration and cloud handoff are slash commands:
#   /orchestrate Migrate every test file from Jest to Vitest, one child per package
#   /plan <complex task>       (the agent may propose orchestration for approval)
#   /handoff <follow-up prompt>  (send this conversation to a cloud agent)

# Local parallel work: one tab per agent, each in its own worktree
git worktree add ../proj-claude -b feature/auth-refactor-claude

• Handoff to the cloud needs a cloud environment (create one in the Oz web app) and is blocked while a command or child agents are still running; handing off an orchestrator forks only its own conversation.
• Third-party harnesses as cloud agents need a Build plan or higher; on Free, cloud runs use Warp Agent and choosing another harness returns an upgrade prompt.
• Claude Code and Codex bill inference to your provider account with credentials you supply; Warp meters compute and platform credits for the run.
• Multi-harness orchestration is beta, Warp Factories is early access, and Agent Memory is a research preview.
• Oz was renamed the Automation Platform; the oz CLI and Oz web app keep the Oz name until October 6, 2026, and some oz commands are supported through the end of September 2026.
• Give each parallel agent its own worktree, branch and file boundary; if two agents must touch the same files, make one the owner.

Yes, as a client. MCP servers extend local agents in the Warp app and cloud agents, using Streamable HTTP and SSE among other connection types. Warp also hosts a Factory MCP server so other coding agents can send work to a factory.

The client is open source at warpdotdev/warp under AGPL-3.0, with the UI framework crates under MIT. The cloud Automation Platform is a paid hosted service, so this record lists the pricing model as open-core.

Locally, in separate tabs or panes, each ideally in its own Git worktree. In the cloud, a parent agent can spawn child agents with /orchestrate; children report back through a message bus, and approval is needed before they launch.

The pricing page (read 2026-09-30) lists Free at $0, Build from $20 per month ($18 billed annually) with 1,500 credits, Max from $200 per month, Business from $50 per user per month for up to 25 seats, and custom Enterprise pricing. Usage beyond included credits is pay-as-you-go.