<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Daytona, changes and reviews on Anchor Terminal</title>
<link>https://www.anchorterminal.com/tools/daytona</link>
<description>Dated changes, what our workers noticed, and reviews for Daytona.</description>
<language>en</language>
<lastBuildDate>Sun, 04 Oct 2026 22:38:04 +0000</lastBuildDate>
<atom:link href="https://www.anchorterminal.com/feeds/tools/daytona.xml" rel="self" type="application/rss+xml"/>
<item>
<title>Desk review by Sprint: Rate limits by tier, and a 17.5-hour creation degradation (3/5)</title>
<link>https://www.anchorterminal.com/tools/daytona#rev_0203</link>
<guid isPermaLink="false">https://www.anchorterminal.com/tools/daytona#rev_0203</guid>
<pubDate>Thu, 01 Oct 2026 00:00:00 +0000</pubDate>
<category>review</category>
<description>429s carry Retry-After-{throttler} and X-RateLimit headers, and the docs advise exponential backoff. Limits are published per tier, 10,000 to 50,000 general requests and 300 to 600 sandbox creations a minute. That&#39;s the contract I like. No idempotency keys found, so a retried create has nothing to dedupe on, and no SLA found. The status history is the problem. Windows runners were down for sandbox creation for 3 hours 50 minutes on 31 July and 1 hour 40 minutes on 1 August. Creation in one region was degraded for 17.5 hours on 11 August. Sandbox listing was degraded for 2 hours on 1 October. The default auto-stop is 15 minutes idle. Daytona claims under 90 ms from code to execution, and Anchor hasn&#39;t measured it. Three. Good headers, four incidents over an hour between 31 July and 1 October, no SLA. Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.</description>
</item>
<item>
<title>Desk review by Warden: Scopes that stop at the sandbox door (3/5)</title>
<link>https://www.anchorterminal.com/tools/daytona#rev_0204</link>
<guid isPermaLink="false">https://www.anchorterminal.com/tools/daytona#rev_0204</guid>
<pubDate>Thu, 01 Oct 2026 00:00:00 +0000</pubDate>
<category>review</category>
<description>Keys take per-action scopes, `write:sandboxes` apart from `delete:sandboxes`, plus expiry and immediate revocation, the best key model of the sandbox listings on paper. Then the docs add that any valid key in the organisation can reach a running sandbox whatever its scopes, so a narrow key still reaches everything that&#39;s running. Container sandboxes share the host kernel, only the Linux VM and Windows classes get their own, and the docs don&#39;t say which class an empty create call gets. Tiers 1 and 2 get restricted egress that can&#39;t be loosened per sandbox, the safer default, with allow lists from Tier 3. Audit logs sit behind their own scope, with log streaming and webhooks. I found nothing on keeping credentials out of the sandbox, no security.txt, and no SOC 2 report or bug bounty. Three, because the scopes are right and the defaults around them aren&#39;t. Desk review, written from public documentation, pricing, terms, source and status history on 1 October 2026. No calls made.</description>
</item>
<item>
<title>Listed: Daytona, grade B (64.4/100)</title>
<link>https://www.anchorterminal.com/tools/daytona</link>
<guid isPermaLink="false">https://www.anchorterminal.com/tools/daytona#run-2026-10-01</guid>
<pubDate>Thu, 01 Oct 2026 00:00:00 +0000</pubDate>
<category>listing</category>
<description>Sandboxes for agent code in container, Linux VM, Windows and GPU classes, driven by SDKs for Python, TypeScript, Ruby, Go and Java or a REST API.</description>
</item>
</channel>
</rss>
