Daytona

PASS consensus from 3 PASS.

The landing page documents account setup, SDK installation, Python configuration, sandbox creation, and Hello World execution in one sequence. The Quick Start puts account creation, API key retrieval, `pip install daytona`, client construction, `daytona.create()`, and the hello-world run in one numbered sequence on the landing page with no cross-page hops. The documentation gives a complete four-step path from zero (create account, get API key, pip install, create sandbox, run code) with a single unambiguous code example on the landing page and in llms-full.txt.

PARTIAL consensus from 3 PARTIAL.

The docs conflict on Tier 1 memory and show a 20 GiB resize above the stated 10 GiB disk maximum. The Limits page states Tier 1 as 10 / 10GiB / 30GiB in its Tiers table and as 10 vCPU / 20 GiB / 30 GiB in its Limits table two sections below, and per-sandbox values appear only on the Sandboxes page while the Limits page defines the term without giving numbers. Two tier-limit tables on the same page disagree on Tier 1 memory: the first table says 10 GiB RAM, the second table says 20 GiB. Tier 2-4 values are consistent across both tables. A cost-sensitive agent would get the wrong answer depending on which table it reads.

PASS consensus from 3 PASS.

The limits and troubleshooting pages document 429 mapping, error headers, applicable throttlers, Retry-After, capped retries, and exponential backoff. The Limits page documents the four rate-limit header patterns, the throttler suffix that names which limit fired, the 429 JSON body, and case-insensitive header access, and Troubleshooting adds a runnable Python retry function that reads `retry-after-sandbox-create` and falls back to exponential backoff. The docs explain the DaytonaRateLimitError class, name the rate-limit response headers (X-RateLimit-Limit-{throttler}, X-RateLimit-Remaining-{throttler}, X-RateLimit-Reset-{throttler}, Retry-After-{throttler}), and provide a complete Python retry function with exponential backoff that reads Retry-After from the error object.

FAIL consensus from 3 FAIL.

The docs cover endpoint creation and payloads but document no signature header, shared secret, or authenticity verification algorithm. Endpoint creation and the full `sandbox.created` and `sandbox.state.updated` payload schemas are documented, but the Webhooks page contains zero occurrences of signature, signing, verify, HMAC, or Svix, and a full-text search of llms-full.txt finds no signing secret, no signature header name, and no verification code anywhere in the documentation. The webhooks page documents endpoint creation, the JSON payload format, and the delivery-log viewer, but it does not mention any signing secret, HMAC signature, signature header, or authenticity verification mechanism. An agent can receive payloads but cannot verify they came from Daytona.

PASS consensus from 2 PASS, 1 PARTIAL.

The official Python example uses sandbox.process.code_run, matching the documented POST /process/code-run API endpoint and payload. The SDK path is consistent across the Quick Start, the Python SDK reference, and Process & Code Execution, but the equivalent Toolbox REST call for the same operation is shown without any Authorization header on those pages while Troubleshooting shows Toolbox calls carrying `Authorization: Bearer YOUR_API_KEY`, and the Toolbox OpenAPI document declares no security scheme at all. The Python SDK page shows pip/poetry install, synchronous and async clients, environment-variable and explicit config, and a minimal sandbox create-and-exec example that agrees with the code on the landing page and in llms-full.txt.