Crush vs Warp (Warp Agent CLI and the Oz Agent API)

Crush

Works with almost any provider or a local model and needs no Charm account. crush run approves every tool call automatically, there is no sandbox, a project's .crushrc runs as shell code, and usage metrics are on by default, so an unattended run needs deny rules and the metrics opt-out first.

Warp (Warp Agent CLI and the Oz Agent API)

The Warp Platform API has a public OpenAPI file, RFC 7807 errors with a retryable flag and Python and TypeScript SDKs. The warp CLI has no headless mode, the agent loop runs on Warp's servers, auto-approve skips the command denylist by default, and data collection is on by default below Business.

Crush

1. Add permissions deny rules or a PreToolUse hook before crush run. It approves every permission request in its session
2. Read .crushrc, crushrc and crush.json in a cloned repository before running Crush there. They execute as shell code at startup
3. Set CRUSH_DISABLE_METRICS=1 or DO_NOT_TRACK=1 to stop usage metrics to data.charm.land
4. Wrap crush run in your own timeout. It has no turn, time or cost limit flag
5. Configure a provider by environment variable or crushrc first. With none, crush run exits with an error asking for interactive setup

Warp (Warp Agent CLI and the Oz Agent API)

1. For unattended work, call POST https://app.warp.dev/api/v1/agent/runs with Authorization: Bearer $WARP_API_KEY. The warp CLI is interactive only
2. Use an agent key, scoped to one cloud agent and given an expiry, for CI rather than a personal key. Keys are created in the Oz web app or the Warp app
3. Set auto_approve_bypasses_command_denylist = false under [agents.warp_agent.other] before starting warp --auto-approve
4. Read code and retryable in error bodies. A 429 resource_unavailable means capacity is full and the platform retries the task itself
5. Pin a version with WARP_TUI_VERSION at install, or set general.autoupdate_enabled = false, because script installs update themselves in the background