Warp

PASS consensus from 2 PASS, 1 PARTIAL.

The linked key, environment, run, status, and session steps form one complete API path. The API & SDK quickstart gives one numbered path with copyable curl for key export, run creation against POST /api/v1/agent/run, status polling on GET /agent/runs/<RUN_ID>, and the session_link, and it names how to obtain the environment ID with oz environment list. The API/SDK quickstart documents creating an API key, submitting a run, polling state, and viewing the session link via curl, but creating the required cloud environment redirects to the Cloud Agents Quickstart which uses the Warp desktop app, not the API. An agent starting from zero cannot create an environment purely through the documented API.

PARTIAL consensus from 3 PARTIAL.

Plan values are findable, but two pages disagree on whether auto-reload fires at or below 100 credits. Add-on expiry (12 months from purchase), the 100-credit auto-reload threshold, and the $200 default monthly spend limit are stated exactly, but every per-plan credit allowance and seat limit is deferred off-docs to warp.dev/pricing, and the reset anchor is given three different ways across pages. Monthly credit allowances are findable (Build ~1,500 credits implied from Max's 12× reference, Max 18,000, Business 1,500/seat, Enterprise custom), but the Build plan's allowance is only implied, not stated explicitly. The documentation consistently delegates to the external marketing pricing page for exact numbers. Unused credits do not roll over; add-on credits roll over for 12 months; auto-reload triggers at 100 credits with a default $200/month spend cap.

PASS consensus from 2 PASS, 1 PARTIAL.

The 409 page identifies pending as the blocked state and tells readers to wait for in progress before retrying. The wait-and-retry correction is stated and the error is marked retryable, but the page's example response points cancellation at /api/v1/agent/tasks/abc123/cancel while the real endpoint is POST /agent/runs/{runId}/cancel, and its lowercase "pending" and "in progress" are not the literal RunState tokens an agent must compare against. The conflict error page documents the exact 409 scenario (cancelling a task in PENDING state), provides the full error response schema, marks the error as retryable, and gives a clear two-step resolution: wait for the task to transition to INPROGRESS, then retry the cancel request.

PASS consensus from 3 PASS.

The key page covers both key types, WARP_API_KEY, Oz CLI authentication, and REST bearer authentication through the linked quickstart. The API keys page covers the whole path end to end: personal versus agent key semantics, creation in the Oz web app, the Warp app, or oz api-key create, the wk- prefix, export WARP_API_KEY, and the quickstart supplies the matching Authorization: Bearer $WARP_API_KEY header for REST. The API Keys page documents creating personal and agent API keys in the Oz web app or Warp app, setting WARP_API_KEY, authenticating the Oz CLI and REST API, and managing keys. The API/SDK quickstart reinforces the same flow with curl examples.

PARTIAL consensus from 2 PARTIAL, 1 FAIL.

The main example reads run_id, but its configuration example switches to warp-sdk and reads task_id. No page on docs.warp.dev contains a package name, an install command, an import, a client constructor, or a single line of TypeScript, and even the SDK-titled demo page carries zero code blocks, so the docs alone cannot get an agent to a run_id. The SDK README shows npm install oz-agent-sdk, client initialization with WARP_API_KEY, and creating a run. The first example correctly uses response.run_id, but the second example uses response.task_id (deprecated per the SDK source, which says 'Use run_id instead') and imports from 'warp-sdk' instead of the installed 'oz-agent-sdk', creating inconsistency.