Dispatch
Every trigger, one run model
An operator, a schedule, or an API client can start a run. Every path uses the same lifecycle and API.
Open source · self-hosted · MIT
Coding agents are tools. Warren turns them into infrastructure.
Warren runs agent harnesses as isolated, observable workloads on infrastructure you control.
It owns the workspace, execution lifecycle, limits, live events, intervention, recovery, and Git delivery.
- Current release
- 0.19.0
- HTTP API paths
- 49
- CLI commands
- 15
- License
- MIT
When to use Warren
When an agent run becomes a workload
A terminal is enough for an interactive run. Warren becomes useful when an agent run stops being a terminal session and starts being a workload.
The run may need to continue unattended, repeat on a schedule, survive failure, or become visible to someone else. Start with one operator. A trusted team can share one deployment and one trust boundary today.
How it works
Warren operates the run
You define the task and review the change. Warren operates the run between those decisions.
- WorkspacePrepare the workWarren refreshes the repository, creates a run branch, and materializes a disposable workspace.
- RuntimeStart the workloadWarren starts the selected harness in a sandbox on one box, in Docker, or in a Kubernetes pod.
- ControlObserve and interveneLive events, spend limits, and cancellation keep the run visible. Runtimes that support steering also accept corrections.
- DeliveryRecover and deliverWarren preserves recoverable work, pushes the branch, and can open a pull request when the forge supports it.
Managed lifecycle
Dispatch. Isolate. Observe. Limit. Intervene. Deliver.
A harness writes the code. Warren manages the infrastructure around it through one run model and one API.
Any harness with a Warren runtime adapter can use that model. The current distribution includes Pi and Claude Code adapters.
Isolate
Give each run a sandbox
Warren creates a disposable workspace for each run. The sandbox can use bwrap, a sibling Docker container, or a Kubernetes pod.
Observe
Keep the run visible
Structured events stream live and remain with the run record. The UI, CLI, and HTTP API read the same event history.
Limit
Enforce limits while work runs
Set a USD cap per project, agent, or dispatch. Warren enforces the cap during the run and applies concurrency limits before dispatch.
Intervene
Correct the run when needed
Cancel any live run. Send a correction when the selected runtime supports steering. Intervention is the escalation path, not the default interface.
Deliver
Return work to Git
Warren finalizes the workspace and pushes the run branch. It can also open a pull request through the configured forge.
Self-host
Your compute. Your credentials. Your run history.
Run Warren on one box, with sibling Docker containers, or on Kubernetes. Set WARREN_RUNTIME to select the execution backend. SQLite is the default store, and Postgres supports the cluster path.
One bearer token guards the deployment today. One operator can run it alone, or a trusted team can share the same trust boundary. Named users, RBAC, and per-user attribution are not in the current release.
Warren carries the MIT license. Read the code, fork it, and run it.
Durable evidence
Conversations evaporate. Runs leave a record.
Warren persists the run events, outcome, cost, and Git delivery facts. You can inspect what happened after the terminal closes.
Optional extensions can build on that record. The audit-log extension exports an append-only trail. The judge extension adds an independent verdict.
Optional extensions
Add the records you need
The base service persists run events and outcomes. Opt-in extensions consume that record without joining the run path.
Install the audit-log extension for an append-only export. Install the judge extension for independent verdicts on finished runs.
Warren runs Warren
Warren dispatches workloads against its own repository and publishes the run history. Watch real runs at app.warren.run, with no login, then run your own.
