This site updates autonomously (see how here). You can
check the log below.
Monitors last ran
. Quiet stretches mean the monitors checked and nothing changed.
monitor_eventapplied
exe-dev: free_while_idle true; stopped VMs bill no vCPU or memory
exe-dev: free_while_idle true; stopped VMs bill no vCPU or memory
I set exe.dev's free_while_idle to true. The standalone VMs doc (https://exe.dev/docs/standalone-vms) states that a stopped standalone VM is not billed for its vCPU and memory, though it keeps its disk and still counts toward VM limits. That matches how this site records daytona, morph, and runloop, where stopping a sandbox ends compute billing and the storage caveat lives in notes. The old false rested on the retired usage-pricing model, where idle memory billed at a disk rate, and https://exe.dev/usage-pricing now returns 404, so the current doc is the better source. I also rewrote notes, which said stopped VMs are not free and cited that dead page; notes now say VMs get no public IP and exe.dev terminates HTTPS and proxies requests (https://exe.dev/docs/faq/how-exedev-works), and that stopping a VM stops vCPU and memory charges while its disk is retained. Both citation URLs already sit in sources, so that list is unchanged, and last_verified reads 2026-10-06. I left every other field alone because the event's diff flags only free_while_idle.
microsoft-azure: TypeScript SDK event already applied, no edits
microsoft-azure: TypeScript SDK event already applied, no edits
This event is a byte-identical replay of the one the previous turn applied in commit 1c0471c, so this time I edited nothing. I still verified the underlying claim by fetching the cited pages: the GA announcement (https://techcommunity.microsoft.com/blog/appsonazureblog/azure-container-apps-sandboxes-now-generally-available/4559125) states SDKs are available for Python and TypeScript, with .NET on the way, and the Python quickstart (https://sandboxes.azure.com/docs/sandboxes/quickstart/setup-python-sdk) confirms Python. data/providers/microsoft-azure.json already lists TypeScript in sdks, both citation URLs sit in sources, and last_verified already reads 2026-10-06.
Add TypeScript SDK to Azure Container Apps Sandboxes
Add TypeScript SDK to Azure Container Apps Sandboxes
Azure Container Apps Sandboxes now list a TypeScript SDK next to Python in data/providers/microsoft-azure.json. Microsoft's GA announcement states SDKs are "available for Python and TypeScript, with .NET on the way", and sandboxes.azure.com carries quickstarts for both, which I confirmed by fetching both pages. I kept CLI in the sdks list because the docs still document it and no cited page says it went away; the event's snapshot value omitted it. last_verified is now 2026-10-06 and both citation URLs are in sources. The event changed no other field.
aws-lambda-microvms: list all nine AWS SDK languages per API docs
aws-lambda-microvms: list all nine AWS SDK languages per API docs
The event supports one change, the sdks list, and I verified it before editing. The cited RunMicrovm API reference (https://docs.aws.amazon.com/lambda/latest/microvm-api/API_RunMicrovm.html) lists nine language-specific AWS SDKs for the MicroVM API: .NET V4, C++, Go v2, Java V2, JavaScript V3, Kotlin, PHP V3, Python (Boto3), and Ruby V3. I replaced the old "Python" and "Node.js" entries in data/providers/aws-lambda-microvms.json with those nine languages, added the API reference URL to sources, and set last_verified to 2026-10-06. The event's changed output touches no other field, so nothing else moved.
agent-substrate: note pre-1.0 status per README
The event supports one change, the notes field, and I verified it before editing. The cited README (https://raw.githubusercontent.com/agent-substrate/substrate/main/README.md) now states under "Status and compatibility" that Agent Substrate is pre-1.0, that backward compatibility has no guarantees, and that APIs and behavior may still change significantly; an upstream commit on September 24 replaced the older "early development, not ready for production use" wording our notes carried. I updated the opening of notes in data/providers/agent-substrate.json and kept the rest of the field after rechecking its claims: the GKE docs page still offers production support on an allowlist under a private GA program, and the suspend flow page still describes open TCP connections being dropped on suspend. The event's citation was already in sources, so the list is unchanged, and last_verified is now 2026-10-06. No other fields changed.
Set Islo wake_on_request to true per lifecycle docs
Set Islo wake_on_request to true per lifecycle docs
Changed wake_on_request from null to true in data/providers/islo.json. Islo's lifecycle documentation states that a paused sandbox with auto_resume set to on_activity resumes automatically when it receives work, such as an exec call, file access, or webhook delivery, and that the first exec_in_sandbox call after an idle pause resumes the VM transparently (https://docs.islo.dev/concepts/sandbox-lifecycle). This is a setting developers choose when they create the sandbox; a policy of never requires an explicit resume. The citation URL was already in the file's sources and last_verified already read 2026-10-06, so the field was the only edit needed.
Add Islo, Incredibuild's sandbox for AI agents
I created data/providers/islo.json, the one product in this event the site didn't track, and left every field the event does not cite null. The DEVOPSdigest announcement (https://www.devopsdigest.com/incredibuild-launches-islo) states that Incredibuild launched Islo, a sandbox that gives each AI coding agent its own dedicated, isolated cloud environment, connects it to systems such as GitHub and Jira without exposing secrets, and governs every action with explicit policies; I fetched the page and confirmed each claim before writing the summary. I set the website to https://islo.dev/ after checking that Incredibuild's own homepage links to it as the Islo product page. I left agent37-cloud.json untouched: the Y Combinator launch post, updated October 6, adds a customer cost example (Boon cut its per-agent cost from $85/month to $4.94/month on equivalent hardware, which I confirmed on the page), but the event itself calls that a customer-cost comparison rather than a change to listed rates, and the billing claims the post restates, per-minute billing and disk-only idle cost, are already recorded from Agent37's own docs, which outrank a launch post. The other cited products, NeevCloud's Agentic Studio, Docker Cloud Sandboxes, and Cloudflare Sandboxes, are already tracked; the AI Made Tools post's GA date adds nothing over Cloudflare's own GA announcement already in that file's sources, and the Analytics India Magazine page returns no renderable text, so neither supports an edit.
fly-io-sprites: update CPU rate to $0.0385 per CPU-hour
fly-io-sprites: update CPU rate to $0.0385 per CPU-hour
The Fly.io pricing page now lists Sprites CPU time at $0.0385 per CPU-hour, up from $0.03825, so I updated `price_headline` in `data/providers/fly-io-sprites.json` and set `last_verified` to 2026-10-06. I fetched https://fly.io/pricing/ and confirmed both figures in the Sprites compute table: CPU time at $0.0385 / CPU-hour and memory time at $0.021875 / GB-hour, with the hot and cold storage rates ($0.000683 and $0.000027 per GB-hour) unchanged. The citation URL was already in the file's sources, so I added nothing there. The event proposes no other field changes.
morph: report headline rate as $0.05 per MCU-hour
Morph's pricing and subscribe pages state a standard MCU rate of $0.05 and bill devboxes in MCUs per hour, so price_headline in data/providers/morph.json now reads "$0.05 per MCU-hour"; the old value, "$0.05 per MCU", omitted the hourly unit. I verified the rate on both cited pages, https://cloud.morph.so/web/pricing and https://cloud.morph.so/web/subscribe. The tier math on those pages confirms the rate applies to MCUs generally: Team's 1000 included MCUs are a $50 value at $40/month, and Scale's 7500 MCUs are a $375 value at $250/month. I added the pricing page to sources (the subscribe page was already listed) and set last_verified to 2026-10-06. The event supports only this field, so every other field in morph.json is unchanged.
ellipsis: notes list three stated bases for the 10% platform fee
ellipsis: notes list three stated bases for the 10% platform fee
The monitor reported that Ellipsis's detailed Pricing docs state a 20% platform fee on credit purchases. The live page (https://www.ellipsis.dev/docs/pricing) says "A 10% platform fee applies to credit purchases before discounts", so I kept the recorded 10% rate and did not write the 20% figure. The event also attributed the "session's token and compute cost" wording to the Billing page, but https://www.ellipsis.dev/docs/billing no longer states any fee basis; that wording appears in the FAQ at https://www.ellipsis.dev/pricing, whose comparison table separately says "10% of token cost". I updated the notes field to record these three verified fee bases, kept the idle-billing caveat (the Pricing docs charge for allocated CPU and memory while a sandbox waits for the next message; the pricing page says nothing runs idle, so nothing bills idle), and set last_verified to 2026-10-06. I left free_while_idle unchanged at true because the event's value matches the file. I dropped the event's parked-conversation sentence because none of the four cited pages state it. All four event citation URLs were already in sources, so the list is unchanged.
exe-dev: pricing_model describes reserved hourly sandbox billing
I updated exe.dev's pricing_model to "Fixed monthly subscription where applicable, plus hourly billing for reserved standalone VM capacity while running; disk is retained when stopped" after checking both citations against the pages themselves. The standalone VMs page (https://exe.dev/docs/standalone-vms) states that a sandbox is a standalone VM with its own reserved vCPU and memory, billed by the hour while it runs, and that a stopped sandbox incurs no vCPU or memory charge and keeps its disk. The billing overview (https://exe.dev/docs/billing/overview) states that a plan's subscription is a fixed monthly price paid in advance. The event also set usage_billed to false, which the file already recorded, so that value stands unchanged. I added the standalone VMs URL to sources, set last_verified to 2026-10-05, and left every other field alone because the event proposed changes only for these two.
No change: LangSmith LCU pricing claim fails live-page check
No change: LangSmith LCU pricing claim fails live-page check
The event proposed one edit: pricing_model for LangSmith Sandboxes would become "Usage-based: sandbox compute in LCU and storage in LSU." I fetched both cited pages. The usage-cost API page does say that endpoint records sandbox compute in LCU and storage in LSU, but the pricing-plans URL redirects to www.langchain.com/pricing, and that page meters sandboxes entirely in LSU: compute at 0.0576 LSU per vCPU-hour, memory at 0.01845 LSU per GiB-hour, storage at 0.000123 LSU per GiB-hour, all rates billed per second, with 8 LSU of sandbox usage included monthly and LSU defined as LangChain Standard Units at $1.00. LCU appears nowhere on it. The event's "1 LCU = $1.50" excerpt matches an earlier version of the page, still visible in the Internet Archive's September 30 copy; LangChain republished the page today at 12:25 UTC, seven hours before the event fired, and the dollar rates are unchanged, since 0.0384 LCU at $1.50 equals 0.0576 LSU at $1.00. The existing pricing_model and price_headline already match the live pricing page, and the pricing page outranks the API docs for pricing claims, so I left data/providers/langsmith-sandboxes.json untouched.
railway: extend notes with fork behaviour and idle billing
railway: extend notes with fork behaviour and idle billing
Updated data/providers/railway.json. The notes now say that forks, like checkpoints, boot fresh from a copy of the disk and preserve files but not running processes or RAM (docs.railway.com/sandboxes), and that Railway keeps billing memory, background CPU use, and outbound traffic while a sandbox waits for work, with no further compute usage once it is destroyed (docs.railway.com/pricing/plans, VM pricing section). I fetched all four cited pages and confirmed each claim against the page text; the pricing sentence sits under the VM pricing heading that names sandboxes, so it is not a neighbouring tier's rate. The docker field already read true, and the September 18 changelog confirms sandboxes are available on every plan, so no change was needed there. Added the two new citation URLs to sources and set last_verified to 2026-10-05.
aws-lambda-microvms: set max_runtime to 8 h per Lambda quotas page
aws-lambda-microvms: set max_runtime to 8 h per Lambda quotas page
The Lambda quotas page now states a maximum execution duration of 8 hours (28,800 seconds) per MicroVM, and the launch post says MicroVMs support up to 8 hours of total runtime. I fetched both pages, confirmed the wording, and changed max_runtime from "8 h (28,800 s state-retention window)" to "Up to 8 hours", since the old string misread the figure as a state-retention limit. I left sdks alone. The event's citation documents LambdaMicrovmsClient in the AWS SDK for JavaScript v3 package @aws-sdk/client-lambda-microvms, which backs the Node.js entry the file already lists, and its replacement list drops Python without claiming Python is unsupported, even though boto3 documents a LambdaMicroVMs client (boto3.client('lambda-microvms')); its own reasoning says the list covers only the SDKs the researcher gathered. The quotas page and the SDK page are now in sources, last_verified is 2026-10-05, and the blog citation was already present, so the event's citations are all covered without duplicates.
agent37-cloud: set docker to false, no Docker inside instances
agent37-cloud: set docker to false, no Docker inside instances
The event proposed two changes for Agent37 Cloud: docker false and wake_on_request true. The file already recorded wake_on_request as true, so the only change is docker, from null to false. The migration guide (https://www.agent37.com/docs/agents-api/migrate-from-docker) states "There is no Docker to run inside an instance", and the custom image docs (https://www.agent37.com/docs/agents-api/custom-image.md) describe Dockerfiles only as build inputs for instance images, never as nested Docker inside a sandbox. The instances doc (https://www.agent37.com/docs/agents-api/instances.md) confirms that any request to a sleeping instance's URL wakes it, which supports the existing wake_on_request value. I verified each page directly with curl before editing, set last_verified to 2026-10-05, and added the two new citation URLs to sources.
opencomputer: no spec change; 28 ms figure belongs to Firecracker
opencomputer: no spec change; 28 ms figure belongs to Firecracker
The event proposed rewriting cold_start to a 28 ms snapshot restore and a 1.1 s cold boot, but the cited guide (https://opencomputer.dev/guides/qemu-vs-kvm/) attributes both numbers to Firecracker, from one practitioner's measurements. For OpenComputer's own QEMU fleet the same page gives about 300 ms from a golden snapshot, about 200 ms when the snapshot is warm on the worker, boot under 1 s at p95, and a 1 to 2 s average wake, which is what data/providers/opencomputer.json already records, so I left cold_start alone. The event's wake_on_request value, true, also matches the stored one; the repo's docs source (docs-sandbox/sandboxes/timeout.mdx) still says any SDK operation wakes a hibernated sandbox, though the live pages at docs.opencomputer.dev/sandboxes/timeout and /overview now return 404, and the current README no longer contains the quoted "preview URLs wake them on demand" line. All four event URLs were already in sources, so I changed no facts and only refreshed last_verified to 2026-10-05.
novita: event reconfirms wake_on_request true, bump last_verified
The event's only field change sets Novita's wake_on_request to true, and data/providers/novita.json already records true, so no spec field changed. I fetched the cited page (https://docs.novita.ai/guides/sandbox-auto-resume, titled Timeout Handle): it documents lifecycle onTimeout: 'pause' with autoResume: true, but it never says SDK actions or HTTP traffic resume a paused sandbox, so the event's reasoning overstates the page. The pause-resume page (https://docs.novita.ai/guides/sandbox-pause-resume), already in sources, does say a paused sandbox optionally resumes when activity is detected and that auto-resume works well for preview environments and web servers, which keeps wake_on_request true. The snapshot's other fields restate recorded values, including the session-limit conflict the notes already document, so I left them unchanged. I set last_verified to 2026-10-05 and added the event's citation URL to sources; the list already carried this page under its old novita.ai/docs address, which redirects there.
cloudflare: re-delivered event already adjudicated; no data change
cloudflare: re-delivered event already adjudicated; no data change
The monitor re-delivered the same snapshot event (identical event_id and event_group_id) that the previous turn adjudicated minutes earlier in commit adb720a. I fetched the cited page (https://developers.cloudflare.com/sandbox/) and confirmed it states two sandbox environments accessible through a Worker, Containers running an image you provide in a full Linux environment, Dynamic Workers running untrusted JavaScript, Python, or WebAssembly, and the use cases the event lists. The summary in data/providers/cloudflare.json already states those facts from that same page and is more specific than the event's wording, so I left it unchanged rather than rewrite a field to an equally supported alternative. The event proposes no other fields, its citation URL is already in sources, and last_verified already reads 2026-10-05.
codesandbox: session length Unlimited; credit price stays $0.01486
Set max_runtime to Unlimited and rewrote notes in data/providers/codesandbox.json. The pricing page (https://codesandbox.io/pricing) lists session length as Unlimited for every plan, and no page I checked still states the old "24 h on Pro tier". The event proposed headlining the pricing page's $0.015 credit price, but the pricing FAQ (https://codesandbox.io/docs/learn/plans/pricing-faq) and the SDK pricing docs (https://codesandbox.io/docs/sdk/pricing) both state $0.01486, and the SDK docs' per-VM rates (5 credits at $0.0743 an hour) work out to exactly $0.01486, so price_headline keeps the more specific figure and the new notes record the conflict. The event's cold_start figures match the core-concepts page (https://codesandbox.io/docs/sdk/core-concepts) and the value the file already carries, so that field is unchanged. pricing_model still describes Pro as "24-h sessions", which the pricing page contradicts, but the event did not cover that field. Cloudflare blocks direct fetches, so I verified each claim against Wayback snapshots from March and April 2026 whose text matches the event's excerpts. Added the new source URLs and set last_verified to 2026-10-05.
microsoft-azure: refresh last_verified, add portal docs source
The event proposed setting free_while_idle to true for Azure Container Apps Sandboxes. I fetched both cited pages: the Microsoft Learn overview says "Scale to zero: You pay no CPU or memory fees when sandboxes are stopped", and the portal docs at https://sandboxes.azure.com/docs say "Stopped sandboxes don't incur compute charges". The data file already recorded free_while_idle as true, so I changed no fact. I set last_verified to 2026-10-04 and added the portal docs URL to sources; the Learn URL was already listed. Both statements cover compute, which is what this column tracks; storage kept on a stopped sandbox can still bill separately.
langsmith-sandboxes: keep $0.0576/vCPU-hr, refresh last_verified
The event proposed moving price_headline from $0.0504 to $0.0576 per vCPU-hour, citing https://www.langchain.com/pricing. I fetched that page and confirmed its Sandboxes row lists compute at 0.0576 LSU per vCPU-hr, memory at 0.01845 LSU per GiB-hr, and storage at 0.000123 LSU per GiB-hr, all billed per second, with 1 LSU = $1. The data file already stated those rates, so I changed no fact and only set last_verified to 2026-10-04. The citation URL was already in sources, and the old $0.0504 figure came from a LangChain resource article, which the provider's own pricing page outweighs.
nvidia-openshell: document GPU runtime and MicroVM requirements
nvidia-openshell: document GPU runtime and MicroVM requirements
Updated notes on NVIDIA OpenShell to the documented GPU behavior: Docker and Podman assign GPUs through NVIDIA CDI devices, Kubernetes sets the nvidia.com/gpu limit, VM gateways accept only one GPU, and MicroVMs require host virtualization (Apple Hypervisor on macOS or KVM on Linux). Both URLs the event cites now serve Page Not Found pages because the 0.1.x docs restructured, so I confirmed each claim on the current pages, Manage Sandboxes (https://docs.nvidia.com/openshell/latest/how-it-works/sandboxes/overview.md) and Sandbox Runtimes (https://docs.nvidia.com/openshell/latest/how-it-works/sandboxes/runtimes.md), before writing it into notes. I replaced the dead docs.nvidia.com/openshell/latest/sandboxes.md entry with the live Manage Sandboxes URL, and the runtimes page was already in sources. last_verified is now 2026-10-04, and no other fields changed.
digitalocean-managed-agents: no change; keep 200 ms resume figure
digitalocean-managed-agents: no change; keep 200 ms resume figure
The event proposed rewriting cold_start to the Agent Droplets announcement's figures, and it re-delivers the same event_id an earlier turn today already adjudicated, so I verified the citations again. The announcement (https://investors.digitalocean.com/news/news-details/2026/DigitalOcean-Introduces-Agent-Droplets-Everything-an-AI-Agent-Needs-One-Simple-Monthly-Price/default.aspx) does say Harness Runtime sandboxes "start in about a second, resume from a pause in about 300 milliseconds (in DigitalOcean testing)", inside its description of what an Agent Droplet bundles. The provider's own product page (https://www.digitalocean.com/products/managed-agents) still says sessions go "from creation to a first response in under a couple of seconds" and "resume paused work in about 200 milliseconds". AGENTS.md prefers the provider's current pages over launch announcements and says to change a field only when the new value is better sourced, so cold_start keeps the recorded value, which also carries the about 20 s LangGraph cold start the how-to still documents (https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/how-to/run-langgraph-agent/). No fact changed, last_verified already reads 2026-10-04, and no fact in the file rests on the announcement, so I edited no files.
digitalocean-managed-agents: keep 200 ms resume figure, re-verify
digitalocean-managed-agents: keep 200 ms resume figure, re-verify
The event proposed rewriting cold_start to "Creation: about 1 second; resume: about 300 ms (in DigitalOcean testing)", citing the Agent Droplets announcement and the product page, and I fetched both. The announcement (https://investors.digitalocean.com/news/news-details/2026/DigitalOcean-Introduces-Agent-Droplets-Everything-an-AI-Agent-Needs-One-Simple-Monthly-Price/default.aspx) does say Harness Runtime sandboxes "start in about a second, resume from a pause in about 300 milliseconds (in DigitalOcean testing)", but it is a launch announcement quoting DigitalOcean's own testing. The Managed Agents product page (https://www.digitalocean.com/products/managed-agents), which the event also cites, still says sessions go "from creation to a first response in under a couple of seconds" and "resume paused work in about 200 milliseconds" in its hero and FAQ, so it supports the value already recorded rather than the new one. AGENTS.md prefers the provider's current pages over launch announcements and says to change a field only when the new value is better sourced, and the turns on September 26 and October 3 made this same call against the announcement figures, so cold_start is unchanged. The event's wording would also drop the LangGraph cold start of about 20 s, which the cited how-to (https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/how-to/run-langgraph-agent/) still documents. The only edit is last_verified, now 2026-10-04. I added no citation because no fact changed and the product page URL already sits in sources.
gke-agent-sandbox: note demand-loaded restore, snapshot availability
Updated notes on GKE Agent Sandbox to the event's snapshot-restore caveat after verifying both cited pages. The Pod snapshots concepts page says the application resumes right after the GKE Sandbox kernel is restored, before all application memory is loaded, and that accesses to unstreamed memory can see brief latency for the first few seconds after a restore (https://docs.cloud.google.com/kubernetes-engine/docs/concepts/pod-snapshots). The Agent Sandbox concepts page lists, under limitations, that some underlying features such as GKE Pod snapshots might be in Preview or have specific regional availability (https://docs.cloud.google.com/kubernetes-engine/docs/concepts/machine-learning/agent-sandbox). I dropped the event's closing clause about documentation describing Agent Sandbox as a managed add-on because the summary field already states that. The new note replaces the Default Deny network posture note, which the concepts page still documents. last_verified moved to 2026-10-04, and I added the Pod snapshots concepts page to sources; the Agent Sandbox concepts page was already listed. No other fields changed.
opencomputer: free_while_idle already true; refresh last_verified
The event proposed setting opencomputer's free_while_idle to true, but data/providers/opencomputer.json already records true, so no fact changed. I verified the value against the live pricing page (https://opencomputer.dev/pricing), which says every session runs on its own Linux machine, billed only while it runs, and that sessions hibernate when idle with scale to zero. The event's other citation, https://docs.opencomputer.dev/sandboxes/timeout, returns 404: the docs site now covers Serverless Agents and no longer publishes the sandbox timeout page. I refreshed last_verified to 2026-10-04 and left sources alone, since both event citations were already listed.
agent37-cloud: keep wake_on_request true; refresh last_verified
The event proposed wake_on_request: false because the Instances page says a stopped instance stays down until an explicit start. I fetched the page (https://www.agent37.com/docs/agents-api/instances) and it states both behaviors: stopped instances stay down, and sleeping instances wake transparently, with any request to any of the instance's URLs held while the instance restores. The field on this site asks whether an idle or suspended sandbox revives on inbound traffic, and Agent37's idle state is sleeping: an instance with auto-sleep enabled checkpoints itself when idle and the next request wakes it. Stopping is the operator's explicit opt-out, and the platform never stops an instance on its own. An opt-in wake capability counts as true here, as the E2B turn of 2026-08-04 recorded for autoResume, so wake_on_request stays true. No fact changed; I bumped last_verified to 2026-10-04 and added no sources because the cited URL was already listed.
codesandbox: no data change; $0.018 figure predates current pricing page
codesandbox: no data change; $0.018 figure predates current pricing page
The event proposed rewriting the notes field to say CodeSandbox's own pricing pages conflict at $0.01486 versus $0.018 per VM credit. The SDK pricing page does state $0.01486 per credit, which matches the price_headline already on record. The $0.018 figure doesn't hold up: that wording, with its "Devboxes" terminology, appears only in the January and March 2025 captures of codesandbox.io/pricing, while every capture from November 2025 through the latest (2026-04-11) says VM credits are "priced at $0.015 each" on VM Sandboxes. Cloudflare blocked direct fetches of the live pages, so archived captures are the strongest evidence available, and the general page's $0.015 reads as a rounding of the SDK docs' $0.01486 rather than a second rate. The blog's "Environment customization using Docker & Docker Compose (Dev Containers)" line checks out, but the file already records docker: true with that source. I left data/providers/codesandbox.json unchanged, and last_verified already reads 2026-10-04 from the earlier delivery of this same event, which reached the same conclusion.
runloop: gpu already true; refreshed last_verified, added sizes source
The event proposed setting gpu to true for Runloop, citing the docs index and the Devbox sizes page. The file already has gpu: true, so no field value changed. I fetched both cited pages: docs.runloop.ai/llms.txt describes the Devbox as an isolated Linux sandbox with "optional GPU", which supports the existing value, while docs.runloop.ai/docs/devboxes/configuration/sizes lists CPU, memory, and storage tiers and never mentions GPU, so it adds no GPU specifics. I refreshed last_verified to 2026-10-04 and added the sizes page to sources; llms.txt was already listed. The event changed only the gpu field, so every other field stays as it was.
morph: $0.05 per MCU rate already on record; no fact changed
morph: $0.05 per MCU rate already on record; no fact changed
The event proposed setting Morph Cloud's price_headline to "$0.05 per MCU
(standard rate)", citing https://cloud.morph.so/pricing. I fetched the page
and confirmed it states "Based on standard MCU rate of $0.05" in an
example-usage line, separate from the $0, $40, and $250 monthly subscription
tiers. data/providers/morph.json already records "$0.05 per MCU (Morph
Compute Unit)" and already cites https://cloud.morph.so/web/subscribe, which
serves the same Subscribe page, so the event restates a rate the site has
carried since July, and I left the field alone rather than trade one equally
supported phrasing for another. The event's changed output touches no other
field. The only edits are bookkeeping: last_verified moves to 2026-10-04 and
the /pricing citation URL joins sources.
No change: LangSmith Sandboxes compute stays $0.0576 per vCPU-hour
No change: LangSmith Sandboxes compute stays $0.0576 per vCPU-hour
The event proposed raising the LangSmith Sandboxes price_headline to $0.0504 per vCPU-hour, citing LangChain's comparison article and pricing page. I fetched both and the proposal fails verification. The $0.0504 rate appears in the article's E2B and Daytona sections, whose rows sit near the LangSmith section; the LangSmith row itself lists about $0.0576 per vCPU-hour (https://www.langchain.com/resources/best-agent-sandboxes). The pricing page states Sandboxes compute at 0.0576 LSU/vCPU-hr, memory at 0.01845 LSU/GiB-hr, and storage at 0.000123 LSU/GiB-hr, all billed per second (https://www.langchain.com/pricing). Those figures match data/providers/langsmith-sandboxes.json as it stands, so I edited nothing.
digitalocean-agent-droplets: keep 200 ms resume figure, re-verify
digitalocean-agent-droplets: keep 200 ms resume figure, re-verify
The event proposed changing cold_start to "About 1 second to start; about 300 ms
to resume (DigitalOcean testing)", and I confirmed the cited announcement does
say sandboxes "resume from a pause in about 300 milliseconds (in DigitalOcean
testing)" (investors.digitalocean.com/news/news-details/2026/DigitalOcean-Introduces-Agent-Droplets-Everything-an-AI-Agent-Needs-One-Simple-Monthly-Price/default.aspx).
The existing 200 ms figure comes from the Managed Agents product page
(www.digitalocean.com/products/managed-agents), which still says sessions
"resume paused work in about 200 milliseconds" in its hero and FAQ, so the
event's research missed a live page that contradicts its new value. AGENTS.md
prefers the provider's current pages over launch announcements and says to
change a field only when the new value is better sourced, so cold_start keeps
the 200 ms figure. The only edit is last_verified, now 2026-10-03, after the
Agent Droplets pricing page (www.digitalocean.com/pricing/agent-droplets)
confirmed sandboxes still "start in about a second".
agent37-cloud: record no runtime cap and memory checkpointing
agent37-cloud: record no runtime cap and memory checkpointing
Both changes are verified against the cited pages before editing. The cloud page's FAQ answers "How long can one agent run?" with "As long as you keep it. Nothing times out mid-task", and the core-concepts doc says an instance "lives until you delete it", so max_runtime now reads "No fixed limit; an instance lives until you delete it" (https://www.agent37.com/cloud, https://www.agent37.com/docs/agents-api/concepts). The instances doc says auto-sleep checkpoints an instance and a normal wake restores it in a few seconds, with in-memory state usually surviving, so memory_snapshots is now true; the docs warn that a wake can instead rebuild fresh in about two minutes when the checkpoint cannot be restored or the instance sat in cold storage, and the file's existing note already covers that caveat (https://www.agent37.com/docs/agents-api/instances). Sources gained the two doc URLs, and last_verified stays 2026-10-03.
opencomputer: agent-session price headline and updated summary
opencomputer: agent-session price headline and updated summary
I updated two fields in data/providers/opencomputer.json and set last_verified to 2026-10-03. The pricing page (https://opencomputer.dev/pricing) states the default agent-session machine is 2 GB / 1 vCPU at $0.00315/min, billed to the second, with burst tiers at $0.00630/min (4 GB / 2 vCPU) and $0.01260/min (8 GB / 4 vCPU), so price_headline now carries the default rate. The old value, "$0.24 per hour for the default 4GB/1vCPU sandbox", matches a row in the sandbox table at https://opencomputer.dev/pricing.md, but neither that page nor the current pricing page marks it as the default. The homepage (https://opencomputer.dev/) describes agents deployed as managed sessions that each run on a real Linux machine, and its own description calls every sandbox a full Linux VM with KVM isolation, so the summary now describes the product that way. The event's third citation, https://docs.opencomputer.dev/introduction, returns 404 because the docs were restructured around Serverless Agents; I verified the sandbox wording against the homepage instead and did not add the dead URL to sources. Both live citations were already listed, so the sources array is unchanged.
aws-agentcore-runtime: confirm free_while_idle=false, add source
The event proposed changing free_while_idle from true to false for AWS AgentCore Runtime, and data/providers/aws-agentcore-runtime.json already recorded false, so no field value changed. I verified the value against both cited pages today. The pricing page states that a microVM session bills from ready, through idle periods, until termination, with system overhead and a 128 MB minimum memory billing on top. The StopRuntimeSession doc states that stopping a session immediately terminates it and releases its resources. I set last_verified to 2026-10-03 and added the stop-session page to sources; the pricing page was already listed.
Add Agent37 Cloud, Docker Cloud Sandboxes, and Proliferate
Add Agent37 Cloud, Docker Cloud Sandboxes, and Proliferate
Added three sandbox products the site did not track, each verified against its cited page before editing. The Agent37 Cloud entry rests on its Y Combinator launch page and agent37.com/cloud: prepaid per-minute compute at $0.0011 per vCPU-hour plus $0.00096 per GB-hour of memory, disk-only cost while a sandbox sleeps, gVisor isolation, and no run timeout. The Proliferate entry rests on its Y Combinator launch page: open-source under MIT, self-hosted, with one sandbox per agent running the team's Docker containers and reaching internal services through an action catalog. The event's second finding names Agent37 Cloud but its citations and reasoning point at Docker's launch, so I verified those pages too and added Docker Cloud Sandboxes, announced September 24 in the GlobeNewswire release syndicated at manilatimes.net and priced on docker.com/products/docker-sandboxes at $0.07 per hour for a 1 vCPU size, metered per second. The Instagram reel citation returns a login wall and backs nothing I wrote, so no field cites it.
Beam: trim cold_start to the documented 1-3 s cold boot
Beam: trim cold_start to the documented 1-3 s cold boot
Beam's cold_start now reads "1–3 s cold boot", matching the sandbox page's "Sandboxes cold boot in one to three seconds" (https://www.beam.cloud/sandbox). I dropped the "container start under 1 s" half of the old value because Beam rewrote its cold-start documentation and that page no longer states a container-start time (https://docs.beam.cloud/v2/topics/cold-start). The event's other citation, the RL environments page, says a restore "takes under a second with dependencies included" (https://www.beam.cloud/use-cases/rl-environments); a restore boots from a saved snapshot, so that figure stays out of the cold-boot field. Added that page to sources and set last_verified to 2026-10-03.
ellipsis: platform fee drops from 20% to 10%
Ellipsis cut its platform fee from 20% to 10%, and data/providers/ellipsis.json now reflects that in notes and pricing_model, with last_verified set to 2026-10-03. The pricing page (https://www.ellipsis.dev/pricing) headlines "Tokens + 10%" and lists the platform fee as 10% of token cost for both the Managed SaaS and BYO AWS columns, and its FAQ describes a 10% fee on the session's token and compute cost. The pricing docs (https://www.ellipsis.dev/docs/pricing) now say a 10% platform fee applies to credit purchases before discounts, not to individual sessions. The event also claimed the billing docs state a 10% fee on actual token and compute cost; I fetched https://www.ellipsis.dev/docs/billing and the page no longer states any fee, so I left that claim out of the file. All three citation URLs were already in sources, so none were added.
digitalocean-agent-droplets: set max_runtime to 744 h monthly cap
digitalocean-agent-droplets: set max_runtime to 744 h monthly cap
Set max_runtime from null to a 744 h monthly active-compute cap per session. The event's citation, DigitalOcean's Harness Runtime Limits page, states "Each session has a monthly active compute cap of 744 hours", and I confirmed that sentence on the live page. The cap counts active compute, so it is a monthly allowance rather than a continuous runtime limit. No other field changed: the event's previous_output values for cold_start, notes, and pricing differ in wording from our current file, but the event presents no new evidence that ours are wrong. Added the limits page to sources and set last_verified to 2026-10-02.
brig: docker and gpu already false, re-verified against non-goals doc
brig: docker and gpu already false, re-verified against non-goals doc
The event proposes two values, docker: false and gpu: false, and
data/providers/brig.json already records both, so no fact changed. This
is a redelivery of the event group handled earlier today, which already
refreshed last_verified to 2026-10-02. I re-confirmed both values on the
cited page (https://raw.githubusercontent.com/brig-sh/brig/main/docs/non-goals.md):
Brig refuses nested containers and a Docker daemon inside the guest, and
it lists GPU scheduling as a non-goal because the agents Brig runs are
CLIs that call a model over the network. The citation URL was already in
sources, so I left the file untouched.
fly-io-sprites: new compute rates; memory survives warm pause
fly-io-sprites: new compute rates; memory survives warm pause
Fly.io's pricing page now lists Sprites CPU time at $0.03825 per CPU-hour and memory at $0.021875 per GB-hour; the old $0.07 and $0.04375 rates no longer appear anywhere on the page, so price_headline and pricing_model now carry the new figures, with storage left to pricing_model and notes as before (https://fly.io/pricing/). The lifecycle docs describe a warm suspension that freezes the VM with everything in memory and resumes processes where they left off, before the Sprite falls cold on its own and drops in-memory state, so memory_snapshots is now true, which matches how the site already scores Fly Machines suspend snapshots (https://docs.sprites.dev/concepts/lifecycle/). I also rewrote the RAM sentence in notes to state that warm/cold split, because the old text said RAM never survives a pause and claimed network config persists, which the current page contradicts. Every event citation was already in the file's sources, so none were added. Storage rates, cold start times, and all other fields are unchanged.
google-cloud-agent-sandbox: free_while_idle already false, re-verified
The event's only change sets free_while_idle to false, and
data/providers/google-cloud-agent-sandbox.json already records false, so
no data field changed. I confirmed the value on all three cited pages: the
Agent Sandbox how-to says a pre-warmed sandbox is a running Pod, the GKE
pricing page charges one-second increments for the resources running Pods
request and adds a flat $0.10 per cluster per hour management fee on every
GKE cluster, and the Pod snapshots how-to says GKE uploads captured state
as snapshot files to a designated Cloud Storage bucket. Suspending a
sandbox therefore does not make the whole setup free, so the recorded
false stands. I set last_verified to 2026-10-02 to reflect that check. All
three citation URLs were already in sources, so the deduplicated list is
unchanged.
brig: docker and gpu already false, re-verified against non-goals doc
brig: docker and gpu already false, re-verified against non-goals doc
The event proposes two fields, docker: false and gpu: false, and
data/providers/brig.json already records both values, so no fact value
changed. I verified both against the cited non-goals page
(https://raw.githubusercontent.com/brig-sh/brig/main/docs/non-goals.md).
Brig refuses nested containers and a Docker daemon inside the guest, a
decision the page holds through August 2027, and it lists GPU scheduling
as a non-goal because the agents it runs are CLIs that call a model over
the network. I refreshed last_verified to 2026-10-02; the citation URL
was already in sources, so the deduplicated list is unchanged.
digitalocean-managed-agents: sdks already recorded, re-verified
The event's only change fills sdks with TypeScript, Go, and Python, and
data/providers/digitalocean-managed-agents.json already records that value,
so no data field changed. I confirmed the value on both cited pages: the
DigitalOcean libraries page lists official SDK client libraries for
TypeScript (DoTs), Go (Godo), and Python (PyDo), with other languages
covered only by community libraries, and the Harness Runtime features page
names PyDo as a way to connect an OpenAI Agents API session to a sandbox. I
set last_verified to 2026-10-02 to reflect that check. Both citation URLs
were already in sources, so the deduplicated list is unchanged.
box-by-ascii: no change; Hetzner isolation claim fails verification
box-by-ascii: no change; Hetzner isolation claim fails verification
The event proposed one change, isolation: "Linux VM on a Hetzner VPS;
hypervisor technology not specified", citing the machines and snapshots docs.
Neither page supports it. The snapshots page
(https://docs.ascii.dev/box/snapshots) does not mention Hetzner anywhere, and
the sentence the event's reasoning attributes to it is not on the page. The
machines page (https://docs.ascii.dev/box/machines) says sandboxes normally
run on dedicated AMD Ryzen 9 9950X hosts, where each sandbox is still a full
VM with its own kernel, and a new sandbox lands on a Hetzner cloud VM only
when standard capacity runs out. That matches the value already recorded in
data/providers/box-by-ascii.json, which a previous turn set from the compare
page, so I left the file untouched and last_verified stays at 2026-10-01.
Flipping the field back to the older Hetzner wording on this evidence would
make it oscillate.
codesandbox: no changes; event's docker claim fails verification
codesandbox: no changes; event's docker claim fails verification
The event proposed one change, docker: true for CodeSandbox, citing the SDK
repo's README, which lists "Running any Dockerfile". That line describes
building the sandbox's own image from a Dockerfile, not running Docker
containers inside a sandbox, which is what this field means. In issue 11 of
codesandbox/codesandbox-sdk the guidance is to apply a Dockerfile by
rebooting the sandbox or pre-baking it into a template with the snapshot
builder, and Together's docs define an environment as "a snapshot built from
a Docker image or Dockerfile". No page states that Docker containers can run
inside a running sandbox, so I left the field alone and edited nothing. The
file already reads docker: true from the original bootstrap, and no source in
it or in the event clearly supports that value for this meaning;
codesandbox.io's docs block automated fetches, so a later turn with access
should confirm the value or set it to null.
fly: gpu already false; add GPU deprecation thread, bump last_verified
The event proposes a single field, gpu: false, which data/providers/fly.json already records, so no fact value changed. I verified both citations. The GPU docs URL https://fly.io/docs/gpus/ now redirects to the February 2025 post "We Were Wrong About GPUs", and that page carries no deprecation notice, so the event's claim of a notice setting unavailability after August 1 failed verification. The community thread supports the recorded value: a user reports a Fly email confirming that Fly.io fully deprecated GPUs as of July 31, 2026, and that date has passed. I refreshed last_verified to 2026-10-02 and added that thread to sources.
No change: Daytona still lists Java among its SDKs
No change: Daytona still lists Java among its SDKs
The event proposed removing Java from Daytona's sdks field, citing
https://daytona.io/docs/en. That page still names five SDKs in its resources
section: TypeScript, Python, Ruby, Go, and Java. It also carries a Java
quickstart tab with install coordinates io.daytona:sdk-java, and the Java SDK
reference page (https://www.daytona.io/docs/en/java-sdk/) still returns 200.
The event's excerpt text does not appear anywhere on the cited page, so the
claimed SDK list looks like a misread. I left data/providers/daytona.json
untouched, and since nothing changed, last_verified stays at 2026-09-22.
langsmith-sandboxes: meter sandbox pricing in LSUs, add storage rate
langsmith-sandboxes: meter sandbox pricing in LSUs, add storage rate
The LangSmith pricing page meters sandbox compute, memory, and storage per second in LSUs at 0.0576 LSU per vCPU-hour, 0.01845 LSU per GiB-hour, and 0.000123 LSU per GiB-hour, and it includes 8 LSU of sandbox usage per month on the listed plans. I confirmed each rate on the page's Sandboxes row and the FAQ's "1 LSU = $1" definition, so the dollar figures already in the file stand; the storage rate and the LSU framing are what's new. I updated price_headline and pricing_model in data/providers/langsmith-sandboxes.json, set last_verified to 2026-10-01, and left sources unchanged because https://www.langchain.com/pricing already appears there. No other fields changed: the event supports only these two, and LCU no longer appears anywhere on the page.
Set nvidia-openshell docker to false (no Docker inside sandbox)
Set nvidia-openshell docker to false (no Docker inside sandbox)
The event asked whether Docker containers can run inside an OpenShell
sandbox. The sandbox runtimes docs describe Docker as a compute driver
that runs sandboxes as containers on the gateway host, and GitHub issue
#113 states that no Docker daemon, socket, or runtime is installed in
the sandbox image and that seccomp, Landlock, capabilities, and network
namespace isolation actively prevent one. I fetched both pages and
confirmed the wording. I set docker to false in
data/providers/nvidia-openshell.json, updated last_verified to
2026-10-01, and added the issue URL to sources; the runtimes docs URL
was already listed. The event supplied no other field changes, so I
touched nothing else.
Add DigitalOcean Agent Droplets subscription product
DigitalOcean launched Agent Droplets on October 1, 2026, and the site did not track the product, so I created data/providers/digitalocean-agent-droplets.json with the fields its own pages state and left the rest null. The press release (https://investors.digitalocean.com/news/news-details/2026/DigitalOcean-Introduces-Agent-Droplets-Everything-an-AI-Agent-Needs-One-Simple-Monthly-Price/default.aspx) confirms the research summary's figures: one monthly subscription bundles Harness Runtime dedicated microVM sandboxes, inference on DigitalOcean-hosted models, memory, session storage, and governed tool access, with Pro at $50 a month (15% off included resources) and Team at $200 a month (20% off), in public preview wherever DigitalOcean Managed Agents is offered. The pricing page (https://www.digitalocean.com/pricing/agent-droplets) confirms both prices and states that dedicated microVMs start in about a second and pause when idle, and the release adds a 300 ms resume figure, which is why cold_start and isolation carry values while the lifecycle and billing booleans stay null. The event's other two citations describe facts the site already records, so I changed no other file: microsoft-azure.json already notes Azure Container Apps Sandboxes went generally available on September 23, 2026, and cloudflare.json already notes container snapshots in public beta. I left those two URLs out of sources because they support no fact in the new file.
opencomputer: keep cold_start; cited docs URLs return 404
The event proposed rewriting cold_start to "~300 ms from a golden snapshot;
hibernated wake is typically sub-second", citing
docs.opencomputer.dev/how-it-works and docs.opencomputer.dev/sandboxes/timeout.
Both URLs now return 404: on September 29 OpenComputer extracted its Sandboxes
docs into a standalone Holocron site, and the docs sitemap and llms.txt now
list only Serverless Agents pages. The quoted text matches
docs-sandbox/how-it-works.mdx and docs-sandbox/sandboxes/timeout.mdx in the
provider's repo verbatim, so the monitor read pages that have since moved, and
I can't confirm either figure at a cited URL. I kept the current value and
reconfirmed it today against its live sources: the QEMU vs KVM guide
(https://opencomputer.dev/guides/qemu-vs-kvm/) states about 300 ms from a
golden snapshot, about 200 ms when warm, and the scaling post
(https://opencomputer.dev/blog/scaling-one-vm-to-million-sandboxes/) states
boot under 1 second at p95 with hibernated wake averaging 1 to 2 seconds.
The timeout URL was already in sources, and I left the dead how-it-works URL
out. The only edit is last_verified, set to 2026-10-01.
aws-agentcore-code-interpreter: set wake_on_request to null
aws-agentcore-code-interpreter: set wake_on_request to null
The event proposed one change and I verified both cited pages first. AWS's stop-session page says you should stop a finished session to release resources, and the session-management page says sessions terminate after the configured timeout and a terminated session no longer persists. Neither page describes a stopped sandbox waking on inbound traffic, so wake_on_request moves from true to null. The previous true came from the TypeScript SDK reference, which only says the client automatically creates a session when none exists, and creating a new session is not waking a stopped one. I set last_verified to 2026-10-01 and added the stop-session page to sources; the session-management page was already listed.
deno-sandbox: pricing_model now reflects plan-metered usage billing
deno-sandbox: pricing_model now reflects plan-metered usage billing
The event proposed new values for cold_start, price_headline, and
pricing_model. I fetched all three cited pages and confirmed the claims
against them. Only pricing_model changed: the old text said sandbox
compute is "included in Deno Deploy plans", but the pricing page
(https://deno.com/deploy/pricing) says sandbox compute bills through the
plan's CPU, memory, and egress meters, bills CPU only while code runs,
bills memory while it stays loaded, and bills volume storage monthly, so
the field now reads "Usage-based: CPU while code runs, memory while
loaded, plus egress and monthly persistent-volume storage; plan
allowances and rates apply". The other two fields needed no edit: the
file already says cold starts are under 200 ms with a 93 ms demo figure,
and https://deno.com/deploy/sandbox states both ("Under 200ms" in the
FAQ, "Ready in 93ms" in the demo); its price_headline rates match the
product page's own pricing section ($0.10/CPU-hr, $0.025/GiB-hr,
$0.20/GiB-month). Rewording verified values that gain nothing would make
fields flip between runs, so I left them. I set last_verified to
2026-10-01, and the event's three citations were already in the sources
list, so nothing was added there.
Set DigitalOcean Managed Agents memory_snapshots to true
Set DigitalOcean Managed Agents memory_snapshots to true
The event reported that DigitalOcean documents memory persistence across pauses, so I set memory_snapshots from null to true in data/providers/digitalocean-managed-agents.json. I verified both cited pages before editing: the Harness Runtime sessions doc says pausing freezes the sandbox in place and preserves processes, memory, and the workspace filesystem, with resuming returning the agent to where it stopped, and the architecture doc says pausing preserves the full machine state. I updated last_verified to 2026-10-01 and added the architecture doc to sources, since the sessions doc was already listed. No other field changed; the event supported only this one.
box-by-ascii: isolation now bare-metal hosts with Hetzner fallback
box-by-ascii: isolation now bare-metal hosts with Hetzner fallback
Updated the isolation field for boat by ASCII. The comparison page (https://box.ascii.dev/compare) now says sandboxes normally run on standard machines hosted on AMD Ryzen 9 9950X (internally called "baremetal"), and fall back to an older Hetzner cloud VM at the same price when standard capacity is temporarily exhausted. The product page (https://box.ascii.dev/) still describes each sandbox as a persistent Linux (Ubuntu) virtual machine, and the snapshots guide (https://docs.ascii.dev/box/snapshots) restores a stopped sandbox onto a fresh machine. The old value, a Hetzner Cloud VPS (CX33), no longer matches these pages, which was the only field the event supported changing. Added https://docs.ascii.dev/box/snapshots to sources and set last_verified to 2026-10-01.
codesandbox: keep $0.01486 credit price; pages unchanged
The event proposes one change: rewriting price_headline from "$0.01486 per
VM credit" to the pricing page's rounded "$0.015". Both figures are genuine
and predate this event. The pricing page (https://codesandbox.io/pricing)
prices VM credits at $0.015 each, and the pricing FAQ
(https://codesandbox.io/docs/learn/plans/pricing-faq) prices them at $0.01486
each; the monitor's own previous snapshot already recorded the same two
values, and I confirmed both sentences in the Wayback Machine's April 2026
snapshots after Cloudflare blocked direct fetches. CodeSandbox changed
nothing on either page, so the research summary merely switched which figure
it headlines. The data rules prefer the more specific stated figure over a
rounded one and forbid rewriting a field to an equally-supported alternative,
so price_headline stays at "$0.01486 per VM credit". No files changed.
cloudflare: note snapshot public beta, refresh summary for Dynamic Workers
cloudflare: note snapshot public beta, refresh summary for Dynamic Workers
Cloudflare shipped container snapshots, and the docs now mark them public beta. The snapshot guide (developers.cloudflare.com/sandbox/files/save-and-restore-a-workspace/) states that a snapshot saves the writable root filesystem and does not include mounted directories, memory, or running processes, and the lifetime page repeats the beta status and the same limits, so the notes field now says that instead of "snapshots are coming soon". The refreshed overview (developers.cloudflare.com/sandbox/) describes two sandbox environments, Linux microVM containers and Dynamic Workers, and lists agent-written code, user-uploaded applications, data analysis, development previews, and build pipelines as use cases, so the summary now covers both environments. I fetched all three cited pages and confirmed every claim before editing; no other fields changed and no other products were affected.
sailboxes: update cold_start to <2s from docs comparison table
sailboxes: update cold_start to <2s from docs comparison table
The Sail docs comparison table (https://docs.sailresearch.com/sailboxes) now lists the Sailboxes start/resume time as <2s, and the lifecycle page (https://docs.sailresearch.com/sailboxes-lifecycle) says waking from sleep takes a few seconds, so cold_start now reads "<2s start/resume; waking from sleep takes a few seconds" instead of "<3s". I fetched both pages and confirmed the table row and wording. I dropped the event's "a couple of seconds" phrasing because the lifecycle page says "a few seconds". The marketing page (https://sailresearch.com/sailboxes) still shows <3s in its own table, but the provider's docs page is the better source, so I followed it. Both event citations were already in the file's sources, so the only other edits are last_verified (now 2026-10-01) and nothing else; the event supports no other field changes.
tencent-cubesandbox: add NEVER_TIMEOUT pause remedy to notes
tencent-cubesandbox: add NEVER_TIMEOUT pause remedy to notes
A monitor event for tencent-cubesandbox (snapshot, 2026-10-01) reported that a
manual pause does not stop the idle-timeout clock: with the default
on_timeout="kill", a paused sandbox is still destroyed once idle exceeds its
timeout, and keeping one requires a high timeout or NEVER_TIMEOUT. I fetched
the cited page (raw.githubusercontent.com/TencentCloud/CubeSandbox/master/
docs/guide/lifecycle.md) and confirmed both the caveat and the remedy in its
"Explicit Pause / Resume" section. The file's notes already carried the
caveat, so I added only the supported remedy sentence, set last_verified to
2026-10-01, and left every other field alone. The cited URL was already in
sources, so the deduplicated list is unchanged.
exe.dev: keep usage_billed false; cited usage-pricing page is gone
exe.dev: keep usage_billed false; cited usage-pricing page is gone
The event proposed changing usage_billed from false to true, citing https://exe.dev/usage-pricing. That URL returns 404 and the sitemap omits it, so I couldn't confirm the claim on the cited page. A Wayback snapshot from 2026-07-31 shows the page did exist and described a usage-based mode, where exe.dev billed CPU and active memory by peak usage within each hour, but the site no longer publishes it. exe.dev's live pages bill by reserved capacity: https://exe.dev/docs/standalone-vms says a standalone VM has its own reserved vCPU and memory and is billed by the hour while it runs, https://exe.dev/pricing lists standalone VMs at $0.105 per 2 vCPUs per hour, and https://exe.dev/docs/pools says a pool is billed for as long as it exists, empty or full. That is the schema's definition of usage_billed false, so I left data/providers/exe-dev.json unchanged, including its sources and last_verified.
brig: isolation is hull with hvi on macOS, urunc shim on Linux
brig: isolation is hull with hvi on macOS, urunc shim on Linux
Brig's runtime docs now describe the macOS side in enough detail to correct
our isolation field. The page (https://raw.githubusercontent.com/brig-sh/brig/main/docs/runtimes.md)
says hull boots the microVM on macOS, that six of the eight shipped profiles
select the hvi backend, which talks to Hypervisor.framework directly, and that
vz, which talks to Virtualization.framework, is the fallback. On Linux, Brig
drives nerdctl over containerd and the urunc shim boots each container as a
microVM. I verified all of this against the page before writing it. The old
value claimed a KVM boundary on Linux that the page does not state, so the new
value drops it. The citation URL was already in the file's sources, so the list
is unchanged, and I set last_verified to 2026-09-30.
novita: reconfirm max_runtime conflict, keep quota-doc figures
The event proposed rewriting Novita's max_runtime to describe conflicting published limits, and its excerpts are accurate: novita.ai/sandbox states a 1-hour free-tier and 24-hour paid-tier maximum session, while docs.novita.ai/guides/sandbox-quota-limit lists 1 hour for Free, 3 hours for Paid, and 4 hours by default (adjustable) for Enterprise. I kept max_runtime on the quota-doc figures because the site prefers the provider's own docs when sources disagree, and the notes field already records the product page's 24-hour claim. The proposed string is also long prose with em dashes, which the spec-string rule forbids. No field values changed; I updated last_verified to 2026-09-30 after checking both pages, and both citation URLs were already present in sources.
codesandbox: re-verify cold_start against docs; no field changes
codesandbox: re-verify cold_start against docs; no field changes
The event proposed rewriting cold_start to resume tiers of 0.5-2 s, 5-20 s,
and 20-60 s, citing codesandbox.io/docs/sdk/core-concepts and
codesandbox.io/docs/sdk/resume. Both live pages reject automated fetches, so
I verified against the newest archived copies at web.archive.org (2026-04-18
and 2026-03-14), which state exactly those figures. The file already records
the same tiers, set on 2026-09-19 from the same core-concepts page, plus the
1-3 s template-create time that page also states; the proposed rewrite is
equally sourced and drops supported detail, so I left the field alone. The
monitor's stored previous value (1-3 s regular, 10-60 s archived, from the
resume page) was out of sync with the site, which is why the event fired. The
resume page still summarizes 1-3 s regular and 10-60 s archived, and the file
follows core-concepts, which breaks resume time out by snapshot state and is
the more specific page. Both citation URLs were already in sources, and I
set last_verified to 2026-09-30.
sailboxes: document checkpoint volume and cold-fallback caveats
sailboxes: document checkpoint volume and cold-fallback caveats
I updated the notes field in data/providers/sailboxes.json and set
last_verified to 2026-09-30. The lifecycle page
(https://docs.sailresearch.com/sailboxes-lifecycle) states that checkpoints
save a Sailbox's writable disk and memory, not a version of its shared
volumes, that volume changes remain shared between the source and its
children, and that a checkpoint is not a backup of volume contents. The
TypeScript SDK reference (https://docs.sailresearch.com/reference/typescript-sdk)
states that when Sail cannot resume saved memory, it starts the child cold
with its writable disk intact and no saved processes. I left cold_start at
<3s: the event proposes the same figure wrapped in hedge prose, the
marketing table at https://sailresearch.com/sailboxes confirms <3s for
Sail's start/resume time, and the docs comparison table at
https://docs.sailresearch.com/sailboxes still lists <2s, so no better-sourced
value exists. All four event citations were already in the file's sources
list, so it is unchanged.
morph: re-verify cold start <250 ms, refresh last_verified
The monitor reported a Morph Cloud cold_start of under 250 ms, citing https://cloud.morph.so/docs/developers. I fetched that page and confirmed it: the developers doc says Infinibranch snapshots, branches, and restores whole environments in under 250 ms, and its startup-times table lists <250 ms for Infinibranch against 2-3 minutes for typical VMs. data/providers/morph.json already carried "<250 ms" for cold_start (commit 01161b6, 2026-09-24) and already listed the cited URL in sources, so no field value changed. I verified the claim today and set last_verified to 2026-09-30.
vercel: summary now states sandboxes are persistent by default
vercel: summary now states sandboxes are persistent by default
The event changes only its summary field for Vercel Sandbox, and the one
claim new to this file is that persistence is the default. I verified it on
both cited pages: the concepts page states "Sandboxes are persistent by
default: when a sandbox stops, the SDK automatically snapshots its
filesystem, and the sandbox configuration is preserved across sessions"
(vercel.com/docs/sandbox/concepts), and the product page says "Persistence
is the default. No manual snapshot management needed"
(vercel.com/docs/vercel-sandbox). The summary in data/providers/vercel.json
now reads "Sandboxes are persistent by default" where it previously said
sandboxes "support persistence". The rest of the summary keeps its verified
specifics (Firecracker microVM, port exposure, 20 compute regions), which I
reconfirmed on the product and concepts pages. The event reports no change
to any other field, so everything else in the file stands, and both citation
URLs were already in sources after deduplication. last_verified is now
2026-09-30.
cloudflare: isolation now "Dedicated VM per container instance"
cloudflare: isolation now "Dedicated VM per container instance"
Cloudflare's current docs no longer describe the isolation technology behind
Containers in terms of Firecracker microVMs with gVisor and QEMU, so
data/providers/cloudflare.json now reads "Dedicated VM per container instance".
The Containers architecture page states that each container instance runs
inside its own VM with strong isolation from other workloads
(developers.cloudflare.com/containers/concepts/architecture/), and the
Sandbox pricing page confirms Sandbox SDK is built on the Containers
platform (developers.cloudflare.com/sandbox/platform/pricing/). I verified
both pages directly; the old Firecracker/gVisor/QEMU wording no longer
appears in the architecture page, the platform-details page that now serves
the same content, or the Containers FAQ. Both citation URLs were already in
the file's sources, and last_verified is now 2026-09-30.
ellipsis: platform fee now 20%, notes cover idle-billing conflict
ellipsis: platform fee now 20%, notes cover idle-billing conflict
Ellipsis's pricing docs now apply a 20% platform fee to credit purchases (ellipsis.dev/docs/pricing), up from the 10% we had recorded, and the marketing pricing page shows the fee as 20% of token cost (ellipsis.dev/pricing). I updated pricing_model, rewrote notes to cover both fee statements and the conflicting idle-billing language, and set last_verified to 2026-09-30. I left free_while_idle alone: the cited sentence bills allocated CPU and memory while a sandbox runs and waits for the next message, so it describes a running sandbox, while the field asks whether a stopped, paused, or sleeping sandbox costs nothing. The event's claim that billing docs describe a 10% session fee appears on no cited page; ellipsis.dev/docs/billing states no fee at all.
tencent-cubesandbox: cold_start now uses the README's 60 ms figures
tencent-cubesandbox: cold_start now uses the README's 60 ms figures
The README's benchmark note states 60 ms at single concurrency and an average of 67 ms under 50 concurrent creations, so cold_start in data/providers/tencent-cubesandbox.json now carries those figures in place of the ~48 ms serial number sourced from the 2026-06-01 benchmark post; this site's rules prefer the provider's current docs when the two disagree, and they do (the blog's table reports avg 276.1 ms at 50-concurrent). The auto-resume range stays, since the lifecycle guide the event cites states resume typically takes sub-second to a few seconds. The event also proposed free_while_idle: true, which the file already stated and the lifecycle guide confirms (a paused sandbox reclaims all CPU and memory), so that field needed no edit. All three event citations were already in the file's sources after deduplication, and last_verified now reads 2026-09-30.
No data change: Northflank docker claim fails source verification
No data change: Northflank docker claim fails source verification
The event proposed one change: docker from null to true for Northflank, citing the managed-cloud sandbox page (https://northflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank-cloud.md) and the quickstart (https://northflank.com/docs/v1/application/sandboxes/quickstart.md). I fetched both pages. On each, you create a sandbox as a deployment service from an external container image, such as ubuntu:22.04, and a `deployment.docker` block sets that one container's entrypoint and command. Neither page states that Docker containers can run inside a sandbox, which is what the field means (box/providers.py), and the monitor's own previous research pass left this field null for the same reason. data/providers/northflank.json already records docker: true, a value set by earlier research and supported by a Northflank blog already in sources (https://northflank.com/blog/how-to-spin-up-a-secure-code-sandbox-and-microvm-in-seconds-with-northflank-firecracker-gvisor-kata-clh), whose use-case table lists `docker build` among commands that run safely inside a hardened environment on ephemeral microVMs. I made no edits to the file, including last_verified and sources, because the event's citations state no fact the file lacks.
fly-io-sprites: verify max_runtime, no value change
fly-io-sprites: verify max_runtime, no value change
The event proposes setting max_runtime to "No documented time limit", citing Fly's engineering post about how Sprites are built. I fetched the page and it does list "No time limits" among the characteristics that give Sprites their shape, alongside instant creation, persistent disk, and auto-sleep, so the claim is real. data/providers/fly-io-sprites.json already records "No fixed limit" for this field, the post was already in its sources, and the event's wording paraphrases the same sentence rather than adding better evidence, so I left the field alone instead of swapping one equally supported phrasing for another. The monitor flagged a change only because its previous research run returned null for max_runtime. I bumped last_verified to 2026-09-29 after checking the page.
deno-sandbox: no field changes; SDK languages already recorded
deno-sandbox: no field changes; SDK languages already recorded
The event proposes listing JavaScript, TypeScript, and Python as the Deno Sandbox SDK languages. I verified this against the live pages: the product page states "The Deno Sandbox SDK currently supports JavaScript, TypeScript, and Python, with more languages coming soon" (https://deno.com/deploy/sandbox), and the launch post links the @deno/sandbox JavaScript SDK on JSR and the deno-sandbox Python SDK on PyPI (https://deno.com/blog/introducing-deno-sandbox). data/providers/deno-sandbox.json already lists TypeScript, JavaScript, and Python, so I left the field alone rather than reorder an identical list. I bumped last_verified to 2026-09-29 after checking both pages, and both citation URLs were already in sources.
Scrapybara isolation unchanged: event less specific than filed value
Scrapybara isolation unchanged: event less specific than filed value
The event proposes setting Scrapybara's isolation to "Full Linux and Windows virtual machines; the computer service is packaged as a Docker image". I fetched the cited pages: docs.scrapybara.com/ubuntu describes an Ubuntu 22.04 desktop and docs.scrapybara.com/windows a Windows 11 desktop, and neither states an isolation technology. The "virtual machines" wording in the event's basis comes from sandbox.watch's own Scrapybara page, which renders this same data file. data/providers/scrapybara.json already carries a more specific value ("Full Linux (Ubuntu 22.04) and Windows 11 virtual machines; open-source computer service is packaged as a Docker image with xdotool/noVNC") sourced to those doc pages plus the scrapybara-oss computer repo, which still documents an xdotool-backed service packaged as a Docker image. The monitor flagged a change only because its previous research run returned null for this field; the event adds no source the file lacks and drops detail the file has, so I edited nothing.
Vercel cold_start unchanged: event's figures less specific than prose
Vercel cold_start unchanged: event's figures less specific than prose
The event proposes rewriting the cold_start field for Vercel Sandbox from the same three pages already cited in data/providers/vercel.json, so no new source is involved. I fetched each page and confirmed the current value: the blog post's prose states "p75 dropped from 40s to sub-second, and p95 went from 50s to 5s", which is what the file cites, while the event's "p95 under 10 s" comes from that same post's chart caption, a rounded description of the same data. The concepts page confirms fresh sandboxes boot in milliseconds, and the KB guide's "Warm start: 0.41s" is one sample from an example timing script, not a product spec. Since the event offers a less specific reading of pages the file already cites, I left the field and the file unchanged.
exe-dev: $15/mo pool plans, sandbox VMs $0.105 per 2 vCPU-hr
exe-dev: $15/mo pool plans, sandbox VMs $0.105 per 2 vCPU-hr
exe.dev's pricing page now lists a Personal pool at $15 per month, a Work pool at $0.21 per hour with a $150 monthly minimum, and standalone sandbox VMs at $0.105 per 2 vCPUs per hour; I verified each figure on the live page and updated price_headline, pricing_model, and usage_billed, adding https://exe.dev/docs/billing/usage to sources. The usage-pricing pages now return 404, and the billing docs (https://exe.dev/docs/billing/overview, https://exe.dev/docs/billing/usage) describe only disk and bandwidth overages beyond a flat subscription, so nothing current bills by active CPU use and usage_billed is false. The /sandbox marketing page still shows the old $20/month and $0.05 per core-hour rates, but the pricing page and billing docs are the current source, so I followed them. Since the sandbox rate is stated per 2 vCPUs, the row now sorts unranked in the price column.
nvidia-openshell: memory_snapshots false; docker claim rejected
The event proposed docker true and memory_snapshots false for NVIDIA OpenShell.
I set memory_snapshots to false in data/providers/nvidia-openshell.json: the
architecture doc (https://github.com/NVIDIA/OpenShell/blob/main/architecture/compute-runtimes.md)
states that starting a stopped sandbox requires a fresh supervisor session and
that runtime credentials are generation-scoped and memory-only, and the accepted
suspend/resume design (https://github.com/NVIDIA/OpenShell/issues/2652) states
that it preserves the writable workspace and does not checkpoint RAM, process
state, open connections, or accelerator state. I left docker at null. The cited
runtime docs (https://docs.nvidia.com/openshell/latest/how-it-works/sandboxes/runtimes)
present Docker as the gateway's compute driver, the layer that runs sandboxes as
containers on the host, and no cited page states that Docker containers can run
inside a sandbox; the isolation field already records this boundary. I added the
event's four citation URLs to sources, deduplicated, and last_verified remains
2026-09-28.
No data change: duplicate OpenShell event already applied
No data change: duplicate OpenShell event already applied
This event re-delivers the NVIDIA Open Agent Safety Platform launch word for word, with the same three citations as turn 20260928T172439Z, which I applied in commit e2c7dbd, and its duplicate at 20260928T172723Z. data/providers/nvidia-openshell.json already records the launch, carries last_verified 2026-09-28, and cites all three URLs. I fetched the technical blog (https://developer.nvidia.com/blog/add-runtime-controls-to-ai-agents-with-nvidia-openshell/) and the announcement (https://nvidianews.nvidia.com/news/open-agent-safety-platform) again today, and both still state the stored facts: OpenShell 0.1.0 is an open-source runtime with kernel-level filesystem and process controls, no network path except through the supervisor, and CPU and GPU execution, and the announcement is dated September 28, 2026. The event's own analysis detects no new cloud sandbox product or pricing change, the file validator reports no errors, and the event cites no fact the file lacks, so I made no edits.
openai-hosted-sandboxes: per-minute billing, 5-minute minimum
I updated pricing_model in data/providers/openai-hosted-sandboxes.json to "Eligible container sessions billed by the minute with a 5-minute minimum; memory-tier rates per 20-minute session per container; model usage billed separately." I fetched the cited page (https://developers.openai.com/api/docs/pricing) and confirmed each part: the Containers row for Hosted Shell and Code Interpreter lists "1 GB $0.03, 4 GB $0.12, 16 GB $0.48, 64 GB $1.92 per 20-minute session per container", the page states "Eligible container sessions will be billed by the minute, with a 5-minute minimum per session", and tokens used for built-in tools are billed at the chosen model's per-token rates. The pricing URL was already in sources, so I only set last_verified to 2026-09-28. The event proposed no other field changes, so I left the rest of the file alone.
No data change: duplicate OpenShell event already applied
No data change: duplicate OpenShell event already applied
This event re-delivers, byte for byte, the NVIDIA Open Agent Safety Platform launch that the previous turn (20260928T172439Z) already applied in commit e2c7dbd. data/providers/nvidia-openshell.json already records the launch, carries last_verified 2026-09-28, and cites all three URLs from the event. I fetched the NVIDIA technical blog (https://developer.nvidia.com/blog/add-runtime-controls-to-ai-agents-with-nvidia-openshell/) and the launch announcement (https://nvidianews.nvidia.com/news/open-agent-safety-platform) again today, and both still state the stored facts: OpenShell 0.1.0 is an open-source runtime with kernel-level filesystem and process controls, no network path except through the supervisor, CPU and GPU execution, and broad availability as of September 28, 2026. The file validator reports no errors, so I made no edits.
Add NVIDIA OpenShell (open-source agent sandbox runtime)
The monitor reported NVIDIA's Open Agent Safety Platform launch on September 28, 2026. I fetched the three cited pages and confirmed they describe OpenShell, the platform's runtime layer, as an open-source runtime that runs agents in sandboxes with kernel-level filesystem and process controls, a supervisor that checks outbound requests against policy, and compute drivers for Docker, Podman, MicroVM, and Kubernetes (https://developer.nvidia.com/blog/add-runtime-controls-to-ai-agents-with-nvidia-openshell/). The launch announcement (https://nvidianews.nvidia.com/news/open-agent-safety-platform) confirms the broad-availability date, and Dell's post (https://www.dell.com/en-us/blog/a-new-era-of-ai-agents-demands-a-new-security-model/) confirms the OpenShell and Sentry split. The site already tracks self-hosted open-source sandbox runtimes such as NemoClaw, Agent-Sandbox, and Brig, so I added data/providers/nvidia-openshell.json rather than a row for the platform itself, which is a security umbrella whose Sentry component is a DPU watchdog rather than a sandbox. The file fills only cited facts: isolation and GPU support from the blog, the Apache-2.0 license and Python, TypeScript, Go, and Rust SDKs from the GitHub repo the announcement links, and the Landlock and seccomp details from https://docs.nvidia.com/openshell/about/why-open-shell. I left docker null because the pages present Docker as a host compute driver, not as something that runs inside a sandbox, and every other field stays null for lack of a stated fact. The event's own analysis called this a non-event because the platform is not a hosted cloud service; the pages themselves describe sandboxed execution of agent workloads, which meets this site's bar.
No data change: Ellipsis cold-start claim fails source verification
No data change: Ellipsis cold-start claim fails source verification
The event proposed setting the Ellipsis cold_start field to "~8 s for a warm cached session; first image build shown as 3m40s", citing https://www.ellipsis.dev/platform/sandbox. I fetched that URL and it returns a 308 redirect to https://www.ellipsis.dev/platform/environments, and neither page states a boot time: no figure appears in the rendered text, in the site's own llms.txt dump of every marketing page, in the full docs text, or in the page's scripts, whose only boot figure is a demo reporting "Sandbox ready in 1.2s" from a cached image. I therefore left data/providers/ellipsis.json unchanged, including last_verified. The file already carries cold_start "~8 s (warm snapshot boot); first session image build ~3m40s", verified 2026-09-26 against the same URL; I could not confirm that value on the page today, so a future turn should null the field if the site stays without figures.
Update novita notes with paused-billing facts; verify quota limits
Update novita notes with paused-billing facts; verify quota limits
The event proposed new values for Novita's max_runtime and notes. I fetched all
five cited pages and confirmed them. max_runtime needed no change: the file
already carries the quota-doc values (1 h free, 3 h paid, 4 h default
adjustable enterprise, verified again at
https://docs.novita.ai/guides/sandbox-quota-limit), and the event's version
restates the same facts, so rewriting it would be a reword, not a better-sourced
value. I updated notes in data/providers/novita.json: the pricing page
(https://docs.novita.ai/guides/sandbox-pricing) states that CPU and RAM stop
being billed while a sandbox is paused, with only persistent storage above the
60 GB per-account allowance charged, and that fact was missing from our notes. I
also trimmed the connection-interruption wording to "network connections",
because the pause/resume page
(https://docs.novita.ai/guides/sandbox-pause-resume) says only that, and no
cited page mentions the HTTP, WebSocket, database, and terminal specifics the
old notes claimed. The 3-hour docs versus 24-hour product-page conflict
(https://novita.ai/sandbox) stays in notes, and the 5-minute default timeout is
confirmed at https://docs.novita.ai/guides/sandbox-timeout-handle. I set
last_verified to 2026-09-27. All five event citation URLs were already in
sources, so the list is unchanged. No other fields changed.
gke-agent-sandbox: note optional shutdown time in max_runtime
gke-agent-sandbox: note optional shutdown time in max_runtime
The event proposed one change, and I verified it against the cited page
before editing. The Agent Sandbox lifecycle docs at
https://agent-sandbox.sigs.k8s.io/docs/sandbox/lifecycle state that
standard sandboxes run until manually deleted, and that configuring a
`shutdownTime` schedules an expiration timestamp after which the control
plane garbage-collects the sandbox and its resources. I updated
`max_runtime` in data/providers/gke-agent-sandbox.json to
"No fixed limit; standard sandboxes run until manually deleted unless a
shutdown time is configured", set `last_verified` to 2026-09-27, and left
`sources` unchanged because the lifecycle page is already listed. The
event's other fields matched its own prior snapshot, so nothing else
changed. The file already tracks this product, so no new provider file
was needed.
digitalocean-managed-agents: memory_snapshots to null; no RAM claim
digitalocean-managed-agents: memory_snapshots to null; no RAM claim
DigitalOcean's Harness Runtime docs say pausing a session preserves workspace
state and conversation history, and the product page says a paused session
"pauses and snapshots its state" and resumes in about 200 ms. I fetched both
cited pages and neither states that live RAM contents survive a pause and
resume; every "memory" mention is about billing or sandbox sizing, so the
field's definition (RAM state, not just disk) has no cited public fact.
memory_snapshots moves from true to null, the only field the event supports
changing. Both citation URLs were already in sources, and last_verified is
2026-09-27.
openai-hosted-sandboxes: pricing reconfirmed, no field change
openai-hosted-sandboxes: pricing reconfirmed, no field change
The event proposed rewriting pricing_model to "Per 20-minute container session, priced by memory tier; model usage billed separately". I fetched both cited pages before editing. The pricing page lists container tiers at $0.03 to $1.92 per 20-minute session per container, and it also still states that eligible container sessions are billed by the minute with a 5-minute minimum. The hosted-sandbox guide says hosted sandboxes use standard container rates and bill model usage separately. Both pricing statements have been on the page since we began tracking the product on 2026-09-11, and price_headline already carries the tier rates, so the proposed string is an equally supported alternative that would drop the per-minute billing detail. I left pricing_model alone and bumped last_verified to 2026-09-27 to record the verification. The event's citation URLs are already in sources, so the deduplicated list is unchanged.
google-cloud-agent-sandbox: wake_on_request already true, reverified
The event proposes one change, wake_on_request: true. I fetched both cited pages and each states the behavior directly: https://agent-sandbox.sigs.k8s.io/docs/ says the Sandbox controller handles "pausing (hibernation), and automatic resume on incoming network connections" and lists "Pause sandboxes to free compute resources; resume automatically on network activity", and the kubernetes-sigs/agent-sandbox README lists "Automatic resume: Resuming a sandbox on network connection". data/providers/google-cloud-agent-sandbox.json already records true for this field, so no field value changed. I set last_verified to 2026-09-27 to record the verification and normalized the existing GitHub source entry from http to https to match the event's citation instead of adding a near-duplicate. The event's changed_output covers no other field, so the rest of the file is untouched. The separate gke-agent-sandbox entry still records false, based on Google's blog describing snapshot resume as an explicit request to the controller; this event does not cover that slug, so I left that file alone.
fly: docker false; Fly unpacks Docker images into Firecracker microVMs
fly: docker false; Fly unpacks Docker images into Firecracker microVMs
Updated data/providers/fly.json. The one field flip is docker, true to false: Fly's Docker blueprint (fly.io/docs/blueprints/working-with-docker/) states that Fly.io doesn't run Docker containers, it uses Docker images as a packaging format with no Docker daemon, and the engineering post (fly.io/blog/docker-without-docker/) describes turning OCI images into Firecracker microVMs. I rewrote notes with claims verified on fly.io/docs/reference/suspend-resume/ and fly.io/docs/about/billing/: snapshots aren't guaranteed to persist, deployments, host migration, corruption, and system maintenance can force a cold start, stopped and suspended Machines still bill rootfs at $0.15 per GB per month, and suspended Machines keep reserving regional capacity. The old notes said GPU instances are no longer available, which the cited blog contradicts by saying Fly is not getting rid of GPU Machines, so I dropped that sentence; gpu keeps its recorded false, and the event's claim that GPUs are unavailable after August 1 appears on no page I fetched. I adopted the event's summary after confirming its claims on fly.io/docs/machines/overview/ and fly.io/docs/reference/architecture/, added the event's four new citation URLs to sources, and set last_verified to 2026-09-27. sdks, cold_start, pricing, and the remaining fields carried no supported change.
exe-dev: verify ~2 s VM creation; data unchanged, bump last_verified
exe-dev: verify ~2 s VM creation; data unchanged, bump last_verified
The event reports one change: exe.dev's cold start, about two seconds for a
new VM, citing https://exe.dev/docs/faq/how-exedev-works. I fetched that page,
and it states that starting from a container image "makes creating a new VM
take about two seconds". data/providers/exe-dev.json already records "~2 s to
create a new VM" and already lists that URL in sources, so I left the field
alone: the event's value comes from the same page the file already cites, and
rewriting it would change the wording without adding support. I set
last_verified to 2026-09-26 to mark today's check.
digitalocean-managed-agents: cold_start uses product page resume figure
Updated cold_start in data/providers/digitalocean-managed-agents.json to "Create: under a couple of seconds generally; resume: about 200 ms; LangGraph cold start: about 20 s" and set last_verified to 2026-09-26. I fetched both cited pages before editing: the product page (https://www.digitalocean.com/products/managed-agents) states that sessions go from creation to a first response in under a couple of seconds and resume paused work in about 200 milliseconds, and the LangGraph guide (https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/how-to/run-langgraph-agent/) states that cold start typically takes about 20 seconds. The previous value led with the 305 ms resume figure from the launch press release, which no longer appears on the product page, so the provider's own current page now leads. Both citation URLs were already in the file's sources, so the list is unchanged. No other fields changed.
fly-io-sprites: correct pricing_model to hourly usage-based meters
fly-io-sprites: correct pricing_model to hourly usage-based meters
The event covered Fly.io Sprites pricing. I fetched both cited pages and
confirmed the details there before editing. fly.io/pricing/ and
fly.io/sprites/ both state "Metered per hour of active use" and "All
resources are billed hourly", so the old pricing_model, which claimed
per-second billing, was wrong. I replaced it with the verified
description: usage-based CPU, memory, and storage billing, with CPU and
memory billed while running, hot storage while awake, and cold storage
while the data exists. The event also restated price_headline, but the
proposed string carries the same four verified figures ($0.07 per
CPU-hour, $0.04375 per GB-hour of memory, $0.50/GB-month hot, and
$0.02/GB-month cold storage) as the current value, differing only in
punctuation, so I left that field alone rather than rewrite an
equally-supported alternative. Both citation URLs were already in
sources, so the deduplicated list is unchanged. I set last_verified to
2026-09-26. No other fields had evidence in this event.
deno-sandbox: no field changes; under-200 ms start already recorded
deno-sandbox: no field changes; under-200 ms start already recorded
The event reports Deno Sandbox's cold start as under 200 ms, and the product page backs it: https://deno.com/deploy/sandbox answers "How fast do Sandboxes start?" with "Under 200ms" and shows a "Ready in 93ms" demo. data/providers/deno-sandbox.json already carries "under 200 ms (product page demo shows 93 ms)", so I left cold_start alone rather than rewrite it to the event's shorter, equally-supported phrasing, and the citation URL already sits in sources. The event's previous "under 1 second" figure came from the docs, which state a looser bound than the product page. I set last_verified to 2026-09-26 for this verification and changed nothing else.
novita: verify event pages, keep 3 h paid cap, no field changes
novita: verify event pages, keep 3 h paid cap, no field changes
I fetched each cited page and found nothing the record needs, so data/providers/novita.json stays untouched. The product page (novita.ai/sandbox) does state "Launch sandbox instances in under 200ms on average" and "24 hours max session length" for the paid tier, and the docs (docs.novita.ai/guides/sandbox-overview, sandbox-timeout-handle, sandbox-pricing) still put resume at about a second, new sandboxes at a 5-minute default timeout, and paused storage billing above 60 GB per account. The file already carries all of it: cold_start reads "Under 200 ms on average for create; ~1 s to resume from paused", and the notes name the product page's 24-hour claim next to the quota-limit doc's 3-hour paid cap. That quota doc (docs.novita.ai/guides/sandbox-quota-limit, last modified August 6, 2026) still caps paid sessions at 3 hours and sets enterprise at 4 hours by default, adjustable, so the event's 24-hour figure is not better sourced and max_runtime keeps the doc numbers, matching the previous turn's call. The event's "Enterprise: custom" reads a session limit into enterprise copy that states none. All five event citations already sit in sources, and last_verified is already 2026-09-26.
e2b: cold_start drops defunct 200 ms claim, keeps 1 s resume
e2b: cold_start drops defunct 200 ms claim, keeps 1 s resume
E2B redesigned its homepage and it no longer states a create-time figure, so I removed "less than 200 ms (same region)" from cold_start and kept the resume figure the docs state. The persistence page says "Resuming a sandbox takes approximately 1 second", and the auto-resume page confirms a filesystem-only pause cold-boots on resume instead (https://e2b.dev/docs/sandbox/persistence, https://e2b.dev/docs/sandbox/auto-resume). No page I checked states a create time, so the field now reads "~1 s to resume a paused sandbox; create time not stated". Both citation URLs were already in sources, so I added none, and last_verified is now 2026-09-26.
modal: re-confirm free_while_idle=false; bump last_verified
The event changes one field, Modal's free_while_idle, from true to false, but data/providers/modal.json already records false, so no fact changed. I verified the value against both cited pages: modal.com/docs/guide/sandbox-resources states Modal bills Sandboxes per second on whichever is higher, resource request or actual usage, and modal.com/docs/guide/cold-start states Modal bills for resources used while a container is idle. I set last_verified to 2026-09-26. Both citation URLs were already in sources, so the deduplicated list is unchanged.
CubeSandbox: keep cold_start; PVM benchmark not better sourced
CubeSandbox: keep cold_start; PVM benchmark not better sourced
No data changed. The event proposed rewriting cold_start to the PVM benchmark's figures, about 67 ms average creation from a template at concurrency 1 and 19 ms average resume, and I confirmed both on the cited post (https://raw.githubusercontent.com/TencentCloud/CubeSandbox/master/docs/blog/posts/2026-06-03-cubesandbox-perf-benchmark-pvm.md), which reports 66.7 ms average at concurrency 1 and 18.9 ms average resume on a Tencent Cloud SA9.4XLARGE32 CVM running a PVM kernel. That hardware is weaker than the bare-metal node behind the current value, whose benchmark still reports 47.8 ms average serial creation, and the PVM post calls its own numbers a reference baseline for small-to-medium deployments relative to that report. The README, which I also fetched, is unchanged since the September 6 verification and links both posts side by side, so the provider gives neither priority. Two official benchmarks on different hardware count as equally supported, and the turns on September 3, September 6, and September 22 all kept the bare-metal figure after weighing the alternatives, since this field has swapped values four times since August. The event's reasoning prefers the PVM result over the README's rounded 60 ms headline, which the field dropped on August 30. The resume half stays with the lifecycle guide, because provider docs rank above benchmark blog posts and the guide describes auto-resume while the benchmark times the resume API. I left data/providers/tencent-cubesandbox.json untouched, including last_verified, because the event adds no evidence those turns lacked.
ellipsis: idle sessions now release the sandbox, so idle is free
ellipsis: idle sessions now release the sandbox, so idle is free
Set free_while_idle to true and rewrote the notes in data/providers/ellipsis.json, and set last_verified to 2026-09-26. The lifecycle page (https://www.ellipsis.dev/docs/lifecycle) now defines idle as paused with the sandbox released while the conversation and workspace are kept, and waiting as a still-running sandbox, and the pricing page (https://www.ellipsis.dev/docs/pricing) bills organization compute for the resources allocated while a sandbox runs, including while it waits for the next message, so a released idle sandbox costs nothing. The event also wanted the notes to say the pricing and billing pages describe the 10% platform fee differently; I dropped that sentence because the billing page (https://www.ellipsis.dev/docs/billing) states no fee at all and just links to Pricing. All three citation URLs were already in sources, so the list is unchanged, and every other field in the snapshot matched its previous snapshot, so the rest of the file is untouched.
digitalocean-managed-agents: add ~20 s LangGraph cold start
digitalocean-managed-agents: add ~20 s LangGraph cold start
Added the documented LangGraph cold start, about 20 s, to the cold_start field in data/providers/digitalocean-managed-agents.json, set last_verified to 2026-09-25, and added the tutorial to sources. The LangGraph guide (https://docs.digitalocean.com/products/managed-agents/agent-harness-runtime/how-to/run-langgraph-agent/) states that cold start typically takes about 20 seconds while the sandbox clones the repository, installs dependencies, and starts the Agent Server. The event also proposed replacing the resume figures with the launch release's 305 ms; I confirmed 305 ms on the investor announcement (https://investors.digitalocean.com/news/news-details/2026/DigitalOcean-Launches-Managed-Agents-Bringing-Agent-Execution-Tool-Access-and-Inference-Together-on-One-Cloud/default.aspx), but the product page still states about 200 ms resume and a first response in under a couple of seconds, and the provider's current product page outranks a launch announcement, so the field keeps both resume figures and adds the 20 s workload figure.
gke-agent-sandbox: no field changes; gVisor and Kata reverified
gke-agent-sandbox: no field changes; gVisor and Kata reverified
The event's snapshot changed one field, isolation, to add that Kata Containers
is also supported. The site already records that fact, so I changed no fields;
I verified both cited pages today and bumped last_verified to 2026-09-25. The
GKE Sandbox page confirms gVisor is a userspace re-implementation of the Linux
kernel API and that each sandbox uses its own user space kernel
(https://docs.cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods).
The Agent Sandbox page confirms the product primarily targets security-hardened
runtimes like gVisor and also works with open source Kata Containers
(https://docs.cloud.google.com/kubernetes-engine/docs/concepts/machine-learning/agent-sandbox).
Both URLs were already in the file's sources, and the new wording is not better
sourced than what the file says, so the isolation field stays as is.
fly-io-sprites: no field changes; memory_snapshots false reverified
fly-io-sprites: no field changes; memory_snapshots false reverified
The event proposed setting memory_snapshots to false, and data/providers/fly-io-sprites.json already records false, so no field value changed. I fetched both cited pages before deciding. The lifecycle page (https://docs.sprites.dev/concepts/lifecycle/) says "The split is simple: disk persists, memory does not", that a Sprite suspended warm resumes with memory frozen in place, and that it "goes warm first and falls to cold on its own", at which point "the VM is fully stopped and in-memory state is dropped". The checkpoints page (https://docs.sprites.dev/concepts/checkpoints/) says a checkpoint "snapshots the writable filesystem overlay" and "does not capture anything that only lives in memory". RAM survives only the transient warm stage, so false stands. The only edit is last_verified, now 2026-09-25. Both citation URLs already appear in the file's sources (the checkpoints entry without a trailing slash), so sources are unchanged.
agent-substrate: no field changes; OCI wording doesn't support docker
agent-substrate: no field changes; OCI wording doesn't support docker
The event proposed setting Agent Substrate's docker field to true, citing the GitHub repository and its architecture doc. I fetched both pages: the README says the system 'manages standard OCI containers at the kernel level (via gVisor)', and the architecture doc says an ActorTemplate states 'what OCI image to run'. Neither page says Docker containers or a Docker daemon can run inside an Agent Substrate sandbox; Docker appears in the README only as a dependency for the developer's machine. The event's own reasoning concedes it 'does not establish that a Docker daemon can itself be run nested inside the sandbox'. Treating OCI compatibility as Docker support would be a guess, and the data rules prefer null over a guess, so the field stays null. For comparison, this site backs docker true for GKE Agent Sandbox with gVisor's explicit 'Docker in a GKE sandbox' tutorial. The only edit I made is last_verified, now 2026-09-25, to record the verification.
novita: keep cold_start; 200 ms launch claim still on product page
novita: keep cold_start; 200 ms launch claim still on product page
No data changed. The event proposed rewriting cold_start to "~1 second for resume; initial creation time not stated". I fetched the cited pages: docs.novita.ai/guides/sandbox-overview does say a paused sandbox resumes "typically in about a second" and states no creation figure, but novita.ai/sandbox still says "Launch sandbox instances in under 200ms on average" under its Sub-second startup heading, so a creation time is stated on the provider's own page. The current value, "Under 200 ms on average for create; ~1 s to resume from paused", is supported by both live pages, and the new wording would drop a cited provider figure without a better source behind it. I left data/providers/novita.json untouched. Both citation URLs already appear in the file's sources.
deno-sandbox: no field changes; idle-billing evidence misattributed
deno-sandbox: no field changes; idle-billing evidence misattributed
The event proposed one change, free_while_idle: true, and data/providers/deno-sandbox.json already records true, so no spec value changed. I fetched both cited pages before deciding. On https://deno.com/deploy/pricing, the lines about being billed only for active CPU and idle apps shutting down after ~20-30 seconds sit in the Applications rows of the plan table and describe Deno Deploy apps; the Sandboxes section says only that sandbox compute bills through the same CPU, memory, and egress meters. On https://docs.deno.com/sandbox/timeouts/, the closed-instance line describes a terminated sandbox, and the same page documents duration-based sandboxes that stay alive after the client disconnects. Neither page states that a stopped, paused, or sleeping sandbox costs nothing, so I left free_while_idle at its recorded value instead of treating the event's reading as new support. I set last_verified to 2026-09-25, and both event citations were already in the file's sources.
vercel: note configurable snapshot retention
Updated the notes field in data/providers/vercel.json: Vercel's snapshots documentation says the default 30-day after-last-use snapshot expiration can be shortened, extended, or removed, including keeping snapshots indefinitely (https://vercel.com/docs/sandbox/concepts/snapshots). The persistence page confirms persistence is the default and that each automatic snapshot consumes Snapshot Storage billed separately from compute (https://vercel.com/docs/sandbox/concepts/persistent-sandboxes). I verified every sentence against both pages before editing, set last_verified to 2026-09-25, and left sources unchanged because both citation URLs were already listed. The event's reasoning said the 14-day sandbox removal caveat is no longer supported, but the persistence page still states it; the site's notes never carried that claim, so no edit was needed there and I added nothing beyond the retention fact the event cites.
modal: no fact changes; keep free_while_idle false after verification
modal: no fact changes; keep free_while_idle false after verification
The event proposed setting Modal's free_while_idle to true, reading "You never pay for idle resources" on modal.com/pricing as a claim about stopped or sleeping sandboxes. I fetched both cited pages. The pricing line describes Modal's serverless billing in general ("Burst up to what you need without over-allocating CPU or memory in advance") and says nothing about a stopped, paused, or sleeping sandbox. The event's other citation, modal.com/docs/guide/cold-start, says resources used while a container is idle are billed (GPU reservation, residual memory occupancy), and the already-cited sandbox docs bill per second on max(requested, actual), so a live idle sandbox still costs money. The specific docs outweigh the marketing line, so free_while_idle stays false. I bumped last_verified to 2026-09-25; both event citation URLs were already in sources, so that list is unchanged.
cloudflare: cold_start already ~1-3 s, reverified
The event reports Cloudflare sandbox cold starts as often 1-3 seconds, citing the Containers architecture page. I fetched that page and it states "Container cold starts can often be in the 1-3 second range, but this is dependent on image size and code execution time, among other factors", so the claim checks out. data/providers/cloudflare.json already lists cold_start as "~1-3 seconds", and the citation URL (https://developers.cloudflare.com/containers/concepts/architecture/) was already in sources, so I left both alone rather than rewrite a field to an equally supported alternative. The only edit is last_verified, bumped to 2026-09-25 to record this verification.
CubeSandbox: add v0.7.2 cross-node speed and idle-memory reclaim
CubeSandbox: add v0.7.2 cross-node speed and idle-memory reclaim
The event covered tencent-cubesandbox, which the site already tracks, and its only supported change is to the notes field. I verified the three cited pages before editing: the v0.7.2 release page (https://github.com/TencentCloud/CubeSandbox/releases/tag/v0.7.2) states that with the default MinIO setup, cross-node restore and create-from-snapshot reach running in under 1 second, and that idle guest memory is reclaimed back to the host; the lifecycle guide (https://cubesandbox.com/guide/lifecycle) and the cross-node snapshot guide (https://cubesandbox.com/guide/cross-node-snapshot) confirm the existing caveat text about dropped outbound sockets and the node-local XFS backend. I appended one sentence on the v0.7.2 facts to data/providers/tencent-cubesandbox.json, set last_verified to 2026-09-25, and added the release-tag and lifecycle URLs to sources (the cross-node guide was already listed). No other field changed.
langsmith-sandboxes: no change; free_while_idle stays false
langsmith-sandboxes: no change; free_while_idle stays false
The event proposed flipping LangSmith Sandboxes' free_while_idle to true, citing the pricing page and the GA announcement. I fetched both pages. The GA post says idle sandboxes pause automatically so you don't pay for idle compute, and the pricing FAQ says sandboxes bill per second with TTLs that stop inactive ones, but neither page says a stopped sandbox costs nothing. The pricing page meters sandbox storage at 0.000123 LSU per GiB-hour with all rates billed per second, and the SDK docs say a stopped sandbox keeps its filesystem for up to 30 days, so a stopped sandbox still incurs storage charges. I left free_while_idle at false and changed no fields. Both citation URLs were already in the file's sources.
Add Google Cloud Agent Sandbox cold start from GKE warm-pool figures
Add Google Cloud Agent Sandbox cold start from GKE warm-pool figures
The event fills the cold_start field for google-cloud-agent-sandbox, which was null. The GKE Agent Sandbox how-to docs say a SandboxWarmPool keeps pre-warmed Pods ready to claim, so new sandboxes are created in under a second, and Google's GA blog says 90% of warm-pool allocations complete in 200 milliseconds. I confirmed both figures on the cited pages and wrote them as "~200 ms for 90% of warm-pool allocations; under 1 second with pre-warmed Pods". Both citations were already in sources; I normalized the how-to entry from http to https instead of adding a duplicate. No other fields changed.
Add Google Cloud Agent Sandbox; mark Azure sandboxes GA
Add Google Cloud Agent Sandbox; mark Azure sandboxes GA
Google Cloud introduced Agent Sandbox on September 24, 2026, and the press release (googlecloudpresscorner.com) confirms a managed, isolated Gemini Enterprise capability where agents compile and execute code, use a CLI, and operate a full computer environment with a browser, so I created data/providers/google-cloud-agent-sandbox.json with those facts and left the spec fields null because the release states no pricing, isolation, or lifecycle details. Azure Container Apps Sandboxes reached general availability on September 23, 2026, which the windowsforum.com report confirms while citing the Azure team's own announcement, so microsoft-azure.json now records GA in the summary and notes, flags that some Microsoft Learn pages still carried a preview label after the announcement, adds that source, and moves last_verified to 2026-09-24. I left two event citations out of sources: the techcommunity.microsoft.com URL is a generic Azure category listing that never states the GA fact, and the ai-techpark.com URL covers DigitalOcean Managed Agents, a product the site already tracks with no changes proposed in this event.
deno-sandbox: no data change; product page still names Firecracker
deno-sandbox: no data change; product page still names Firecracker
The event proposed dropping Firecracker from the isolation field, claiming current docs no longer name it. I fetched https://deno.com/deploy/sandbox and its FAQ still states "Each sandbox runs in its own Firecracker microVM, the same technology that powers AWS Lambda", so the field stays "Firecracker microVM". The event's other real change, adding TypeScript to the SDK list, was already captured: the file lists TypeScript, JavaScript, and Python, and the product page confirms all three ("The Deno Sandbox SDK currently supports JavaScript, TypeScript, and Python"). The remaining diffs are rewordings of the notes and summary that state facts the file already carries, and the event's "Under 1 second" cold start is less specific than the file's verified "under 200 ms (product page demo shows 93 ms)", which the page still shows. I re-verified every field against docs.deno.com/sandbox/, the product page, the timeouts page, and the pricing page, so last_verified moves to 2026-09-24. All eight event citations were already in sources, so nothing was added.
novita: event reconfirms cold_start, bump last_verified
The event's changed basis covers one field, cold_start, proposing "under 200 ms on average". I fetched https://novita.ai/sandbox and confirmed the page states "Launch sandbox instances in under 200ms on average". data/providers/novita.json already reads "Under 200 ms on average for create; ~1 s to resume from paused", and the event's shorter wording draws on the same page while dropping the resume figure, so it is not better sourced and I left the field alone. I also re-checked the resume half on https://novita.ai/docs/guides/sandbox-overview, which says a paused sandbox resumes to Running typically in about a second. The citation URL was already in sources, so that list is unchanged. I set last_verified to 2026-09-24 and touched no other field.
morph: cold start <250 ms per docs startup table
Morph Cloud's developer docs compare traditional VM infrastructure with Infinibranch and list startup times of "<250ms" for Infinibranch against "2-3 minutes for typical VMs" (https://cloud.morph.so/docs/developers). I fetched the page and confirmed the table states that figure, so I replaced the old "~250 ms (snapshot/restore via Infinibranch; cold-boot time for fresh images not documented)" with "<250 ms", which matches the page's exact claim. The plans page's "Deployment in seconds" line is vaguer (https://cloud.morph.so/docs/documentation/setup/plans), so the specific figure wins. Both citation URLs were already in the file's sources list, so it is unchanged. The event proposed only this one field; its other content was the monitor's unchanged snapshot context, so I touched nothing else.
vercel: keep cold_start, refresh last_verified
The event re-words cold_start as "~milliseconds for a fresh sandbox; snapshot restore p75 under 1 s and p95 about 5 s", which restates the value the file has carried since 2026-09-19 from the same three pages. I fetched each citation and confirmed the claims: the Vercel Sandbox docs state sandboxes start in milliseconds, the concepts page states resuming from a snapshot is faster than starting a fresh sandbox, and the snapshot optimization post reports restore p75 under one second and p95 at 5 s. The proposed wording draws on the same sources as the current value, so I kept the field as written and refreshed last_verified to 2026-09-24. All three citation URLs were already in sources, so that list is unchanged.
exe-dev: cold start ~2 s; pricing is pooled or usage-based
exe-dev: cold start ~2 s; pricing is pooled or usage-based
exe.dev's FAQ states that creating a new VM takes about two seconds
(https://exe.dev/docs/faq/how-exedev-works), so cold_start now reads
"~2 s to create a new VM" instead of the sub-second figure a third-party
article supplied. The sandbox page (https://exe.dev/sandbox) documents two
pricing models for the same VMs, so pricing_model now covers both pooled
monthly subscriptions and per-second usage pricing, and usage_billed is true
because usage mode bills CPU and active memory by peak hourly use and idle
VMs cost disk only. The event cited https://exe.dev/usage-pricing for those
rates, but that URL returns 404 today; I confirmed the figures ($0.05 per
core-hour, $0.016 per GiB-hour, disk monthly) on the live sandbox page
before writing them. I left price_headline unchanged: the event's wording
restates facts the field already carries and drops the tier names the schema
asks for, and I re-verified the current figures ($0.05 per CPU core-hour,
$20/month Personal, $25/user/month Team) on https://exe.dev/pricing today.
free_while_idle stays false, matching both the event and the page's "stopped
VMs cost disk-only". Every event citation was already in the file's sources
list, so no additions were needed.
langsmith-sandboxes: free_while_idle already false; no fact changed
langsmith-sandboxes: free_while_idle already false; no fact changed
No facts changed in data/providers/langsmith-sandboxes.json. The event's
only proposal sets free_while_idle to false, the value the file has
recorded since July 29, so I verified it instead of editing. The GA post
(https://www.langchain.com/blog/langsmith-sandboxes-generally-available)
says idle sandboxes pause automatically so you don't pay for compute, but
the pricing page (https://www.langchain.com/pricing) still meters sandbox
storage at 0.000123 LSU per GiB-hr with all rates billed per second, and
the SDK docs (https://docs.langchain.com/langsmith/sandbox-sdk) keep a
stopped sandbox's filesystem clone until the deletion sweep, up to 30 days
after stop. A stopped sandbox therefore still incurs storage charges, which
is what the field asks, so false stands. I bumped last_verified to
2026-09-23; all three citation URLs were already in sources.
fly-io-sprites: free_while_idle now true; cold storage caveat added
fly-io-sprites: free_while_idle now true; cold storage caveat added
Fly.io Sprites now read as free while idle. The Sprites overview says idle Sprites carry no compute charges, the product page's FAQ says warm and cold Sprites are not billed and a Sprite that does nothing costs nothing beyond its storage, and the pricing page says CPU, memory, and hot storage bill only while a Sprite is awake while cold storage bills until the data is deleted (docs.sprites.dev, fly.io/sprites, fly.io/pricing). I fetched and confirmed all three pages. The field was false under a literal costs-nothing reading because of the cold storage charge, but the site already treats compute-free idling as true for Daytona, Runloop, and OpenComputer with the storage caveat in notes, so I followed that convention, added the caveat ($0.02 per GB-month) to notes, and set last_verified to today. All three citation URLs were already in sources, so the list is unchanged. No other fields changed.
No data change: Runloop max_runtime already matches docs
No data change: Runloop max_runtime already matches docs
The monitor's snapshot sets Runloop's max_runtime to "Configurable; default
maximum lifetime is 1 hour", citing the Devbox Lifetime Management page. I
fetched https://docs.runloop.ai/docs/devboxes/start-stop and confirmed the
page: a new Devbox gets a default maximum lifetime of 1 hour, and
keep_alive_time_seconds sets a fixed lifetime at creation. The site file
data/providers/runloop.json already records "Default 1 h, configurable",
already cites that page, and carries last_verified 2026-09-23, so the site
already states this fact and I edited nothing. Rewriting the field to the
event's longer wording would trade one equally supported phrasing for
another, and the data rules say to change a field only when the new value is
better sourced.
runloop: max_runtime already correct; refreshed last_verified only
runloop: max_runtime already correct; refreshed last_verified only
The event's only changed field is max_runtime, proposing "Configurable;
default maximum lifetime is 1 hour". I fetched the cited page
(https://docs.runloop.ai/docs/devboxes/start-stop) and confirmed it: every
new Devbox gets a maximum lifetime, the default is 1 hour, and
keep_alive_time_seconds sets a fixed maximum at creation. The page states no
upper bound on a configured lifetime. data/providers/runloop.json already
records "Default 1 h, configurable", the same fact from the same page, so I
left the field alone rather than swap in an equally-supported wording. The
citation URL was already in sources, so the deduplicated list is unchanged. I
set last_verified to 2026-09-23 after verifying the file and touched no other
field.
sailboxes: creation charges apply only on the Free plan
sailboxes: creation charges apply only on the Free plan
The Sailbox pricing page (https://docs.sailresearch.com/sailboxes-pricing) now
states that the one-time creation charges ($0.005 for S, $0.01 for M, $0.012
for L) are waived for Pro and Enterprise, and its intro says the charge applies
"if you're on the Free plan". I verified the page directly: it lists the same
observed-use rates the file already carried ($0.015 per used vCPU-hour, $0.008
per used RAM GiB-hour, $0.0007 per used NVMe GiB-hour, $0.000411 per
volume-storage GiB-hour), so the only supported change is the Free-plan scope
of creation charges. I updated price_headline to end "$0.005-$0.012 per
creation on Free", updated pricing_model to say the creation charge applies on
the Free plan, and set last_verified to 2026-09-23. The citation URL was
already in sources. The event's changed_output touched no other fields, so I
left the rest of the file alone.
northflank: split isolation CPU/GPU, add Python SDK
Northflank's sandbox quickstart now states that you create and manage
sandboxes with the JavaScript or Python SDK, so data/providers/northflank.json
lists both languages. The quickstart and the deploy docs both state that CPU
sandboxes run in microVMs and GPU sandboxes run under gVisor on Northflank
cloud, and that split replaces the blog-sourced list of Firecracker, Kata,
gVisor, and Cloud Hypervisor in isolation. I dropped the event's "dedicated
kernel" wording because the cited pages no longer state it. All four citation
URLs were already in the file's sources. last_verified is 2026-09-23.
tencent-cubesandbox: GPUs not available, roadmap item only
tencent-cubesandbox: GPUs not available, roadmap item only
The CubeSandbox README lists GPU Sandboxes only in its Roadmap table under a "Coming soon" heading, and its current Product Highlights make no GPU claim, so data/providers/tencent-cubesandbox.json now sets gpu to false instead of null (https://raw.githubusercontent.com/TencentCloud/CubeSandbox/master/README.md). That URL was already in the file's sources, and last_verified moves to 2026-09-23. No other field in the event's changed output had evidence to apply.
# langsmith-sandboxes: add memory price and LCU/LSU detail to pricing fields
# langsmith-sandboxes: add memory price and LCU/LSU detail to pricing fields
LangChain's pricing page (https://www.langchain.com/pricing) now lists
sandbox resource rates: compute at 0.0384 LCU per vCPU-hour, memory at
0.0123 LCU per GiB-hour, and storage at 0.000123 LSU per GiB-hour, all
billed per second, with 1 LCU = $1.50. I fetched the page and confirmed
each rate in the Sandboxes grid before editing. That gives
$0.0576 per vCPU-hour and $0.01845 per GiB-hour of memory, so
price_headline now states the memory rate alongside the compute rate, and
pricing_model names per-second metering of compute, memory, and storage in
LCU and LSU units. The page's similar "Runtime Compute · 0.045 LCU /
vCPU-hr" block belongs to a different product and was not used.
last_verified is now 2026-09-22; the citation URL was already in sources.
DigitalOcean Managed Agents: idle billing, memory snapshots, pricing
DigitalOcean's Harness Runtime pricing page says retained checkpoints continue to accrue storage charges while a session is paused, so I set free_while_idle to false and rewrote pricing_model to name what that page bills: per-second actual CPU, peak memory, storage, egress, checkpoints, templates, and tools that require prepayment. I set memory_snapshots to true because the Sessions concepts page states that pausing preserves processes, memory, and the workspace filesystem, and resuming returns the agent to the point it stopped; the event's product and features citations only imply this, so I checked and added the sessions page to sources. The investor press release sits behind a Cloudflare challenge, so I could not verify it. No other fields changed.
Add DigitalOcean Managed Agents (public preview) as a new provider
Add DigitalOcean Managed Agents (public preview) as a new provider
The event reported DigitalOcean launching Managed Agents in public preview on September 22, 2026, a product this site did not track. I verified the claims against DigitalOcean's press release, launch blog, product page, Harness Runtime pricing page, and docs, then created data/providers/digitalocean-managed-agents.json with the facts those pages state: a dedicated Firecracker microVM per session with a coding sandbox and built-in chromium, CPU at $0.044 per vCPU-hour and memory at $0.0095 per GB-hour, resume from pause in 305 ms, pause and fork with compute charges stopped while paused, and harness support for Claude Code, Codex CLI, OpenCode, Hermes, LangGraph, and custom OCI images. Two event figures I did not carry over as stated: the press release prices snapshots at $0.005 per GiB-month, but DigitalOcean's own pricing page says $0.05 per GiB-month, so the file records the pricing page figure; and the pricing page notes that active CPU billing is not live yet, so sessions are billed at 25% of allocated vCPUs until it ships, which I put in notes rather than presenting usage billing as fully live.
fly-io-sprites: free_while_idle now false (cold storage bills asleep)
fly-io-sprites: free_while_idle now false (cold storage bills asleep)
The event re-read Fly.io's pricing pages and flipped free_while_idle for Sprites from true to false. I verified this against the cited pages before editing. https://fly.io/pricing/ states that CPU, memory, and hot storage bill only while a Sprite is awake, while cold storage bills until you delete the data, and https://fly.io/sprites/ says a Sprite that exists but does nothing costs nothing beyond its storage. Cold storage runs at $0.02 per GB-month, and the site's own Web App example bills cold storage for 732 hours in a month with only 30 hours of wake time, so a sleeping Sprite with data on disk still accrues charges. Under the field's definition (a stopped, paused, or sleeping sandbox costs nothing) the answer is false. I set last_verified to 2026-09-22 and added https://fly.io/sprites/ to sources, the one event citation not already listed. No other fields changed.
agent-substrate: monitor confirms usage_billed, values unchanged
The event's only changed field is usage_billed, which moved from null to true in the monitor's snapshot. I fetched both cited pages and confirmed the claim: the GKE docs state that idle agents are suspended and "you pay for compute only when agents are actively processing tasks", and the Google Cloud blog says Agent Substrate "can release resources the moment an agent pauses" and resumes the snapshotted session in milliseconds. data/providers/agent-substrate.json already recorded usage_billed as true, so no field value changed; I refreshed last_verified to 2026-09-22 and left sources as they were, since both citation URLs were already listed.
deno-sandbox: verified event against live pages, no field changes
deno-sandbox: verified event against live pages, no field changes
The event proposed three updates for Deno Sandbox: cold_start "Under 200 ms", max_runtime "Up to 30 minutes", and rewritten notes. I fetched each cited page and confirmed the values: the product page FAQ says sandboxes start in under 200 ms, with a demo widget showing "Ready in 93ms", and the docs limits table says a sandbox's lifetime is configurable, session-bound, and capped at 30 minutes. The data file already stated both facts with the same sourcing and more detail, and the proposed notes would drop the documented pre-release limit of 5 concurrent sandboxes per organization, so I changed no fields. All five event citations were already listed in sources; I bumped last_verified to 2026-09-22 after verifying the file against the live pages.
opencomputer: add ~300 ms golden-snapshot figure to cold_start
opencomputer: add ~300 ms golden-snapshot figure to cold_start
The event changes one field, cold_start, and I verified all three cited pages before editing. OpenComputer's QEMU vs KVM guide states its QEMU fleet boots a sandbox "about 300 milliseconds from a golden snapshot", so cold_start now leads with that figure and the guide joins the file's sources. The scaling blog confirms the two claims the file already carries: boot under 1 second at p95, and wake from hibernation averaging 1 to 2 seconds. The timeout docs describe wake as "typically sub-second", but the blog's specific 1 to 2 second measurement is the better-sourced figure, so it stays. The 28 ms restore number on the same guide page belongs to Firecracker, not OpenComputer, so I left it out. Every other field is unchanged from the event's previous snapshot, so I edited nothing else and set last_verified to 2026-09-22.
Daytona: SDK event matches current data; no changes needed
Daytona: SDK event matches current data; no changes needed
The event reports Daytona's SDKs as Python, TypeScript, Ruby, Go, and Java. data/providers/daytona.json already records that exact list, already carries all six cited SDK pages in sources, and already sets last_verified to 2026-09-22, so I edited nothing. I verified the claim against the live pages anyway: https://www.daytona.io/docs/en/architecture/ lists Python, TypeScript, Ruby, Go, and Java SDKs for programmatic access, and each reference page, including https://www.daytona.io/docs/en/java-sdk/, confirms the SDK exists. Commit dae6967 added these sources earlier today, which is why the file needs no further change.
Daytona: SDK list already had Java; verified, add SDK doc sources
Daytona: SDK list already had Java; verified, add SDK doc sources
The event reports Daytona publishes Python, TypeScript, Ruby, Go, and Java SDKs. data/providers/daytona.json already listed all five languages, so no field value changed. I confirmed the claim on the cited pages: the architecture page lists all five SDKs, and each SDK reference page, including the Java SDK page, describes programmatic access to Daytona Sandboxes. I set last_verified to 2026-09-22 and added the five SDK reference URLs to sources; the architecture page was already cited.
Scrapybara max_runtime already correct; refreshed last_verified only
Scrapybara max_runtime already correct; refreshed last_verified only
The event proposed setting Scrapybara's max_runtime to a 24 hour maximum
configured timeout with a 1 hour default. I verified both cited pages: the
start-instance API reference (https://docs.scrapybara.com/api-reference/start)
shows the timeout_hours constraint as 0.01-24, and the best-practices page
(https://docs.scrapybara.com/best-practices) states the default timeout is
1 hour before automatic termination. data/providers/scrapybara.json already
records this fact as "24 h (configurable; 1 h default)", so I left the field
alone and updated last_verified to 2026-09-22. Both citation URLs were
already in sources, so the deduplicated list is unchanged.
fly: price event matches recorded $0.0027/hr; bump last_verified
fly: price event matches recorded $0.0027/hr; bump last_verified
The event's only changed field is price_headline, moving the monitor's snapshot from $0.0028 to $0.0027 per hour for shared-cpu-1x with 256MB. I fetched both cited pages and confirmed the new figure: https://fly.io/docs/about/pricing/ shows that preset at $0.00000075 per second and $0.0027 per hour in the Ashburn table, the only one the page displays before a visitor picks a region, and https://fly.io/pricing/ defaults to Ashburn and lists the same $0.0027 per hour. The $0.0028 in the monitor's previous snapshot matches the Amsterdam table, which sits first in the page's markup but stays hidden until someone selects it. data/providers/fly.json has carried "From $0.0027/hr (shared-cpu-1x, 256 MB)" since the September 20 turn, so I left the field alone rather than swap in an equally-supported wording. Both citation URLs were already in sources, so the list is unchanged. I set last_verified to 2026-09-22 after verifying the file and touched no other field.
ellipsis: event confirms recorded free_while_idle, bump last_verified
ellipsis: event confirms recorded free_while_idle, bump last_verified
The event's only changed field is free_while_idle, and its new value states what the site already records. I fetched both cited pages and confirmed the wording: https://www.ellipsis.dev/docs/pricing states that organization compute costs $0.141912 per CPU core-hour and $0.024192 per GiB-hour of memory, billed for allocated resources while the sandbox is running, including warm idle time, and https://www.ellipsis.dev/docs/lifecycle defines idle as work paused with the conversation and workspace retained for a later message. data/providers/ellipsis.json has carried free_while_idle as false since the September 10 turn, which drew on the same pricing docs, so I left the field alone. The marketing page at https://www.ellipsis.dev/pricing still reads "No per-seat fees or idle charges", and the file's notes already document that standing conflict. Both event citations were already listed in sources, so the list is unchanged. I set last_verified to 2026-09-22 after verifying the file and touched no other field.
No data changes: CubeSandbox event claims fail source verification
No data changes: CubeSandbox event claims fail source verification
The event proposed two edits to data/providers/tencent-cubesandbox.json and neither survives checking the cited pages. It wanted gpu set to true on the strength of the README, but the README lists GPU Sandboxes in its Roadmap section under "Coming soon" (https://raw.githubusercontent.com/TencentCloud/CubeSandbox/master/README.md), so GPU support is planned, not shipped, and the field stays null. It also wanted cold_start rewritten with figures like 56.1 ms XFS creation, 153.6 ms XFS resume, and roughly 243 ms and 411 ms for S3, but no cited page states those numbers. The performance-benchmark page it cites (https://raw.githubusercontent.com/TencentCloud/CubeSandbox/master/docs/guide/performance-benchmark.md) is an index with no figures, and the two benchmark posts behind it report 47.8 ms average serial creation on bare metal and 66.7 ms on a PVM cloud server, which backs the file's existing "~48 ms create" value. I changed no data.
novita: event confirms recorded cold_start, bump last_verified
novita: event confirms recorded cold_start, bump last_verified
The event's only changed field is cold_start, and its new value states the facts the site already records. I fetched both cited pages and confirmed the figures: https://novita.ai/sandbox states that sandbox instances launch in under 200 ms on average, and https://novita.ai/docs/guides/sandbox-overview states that a paused sandbox resumes to Running typically in about a second. data/providers/novita.json already reads "Under 200 ms on average for create; ~1 s to resume from paused", so I left the field alone rather than swap in an equally-supported wording. Both citation URLs were already listed in sources, so the list is unchanged. I set last_verified to 2026-09-21 after verifying the file, and touched no other field.
deno-sandbox: reject event's field changes, bump last_verified
deno-sandbox: reject event's field changes, bump last_verified
The event proposed setting isolation to "Linux microVM with hypervisor-level isolation", setting max_runtime to null, and new notes; I fetched the cited pages and none supports the changes. The product page FAQ still states each sandbox runs in its own Firecracker microVM (https://deno.com/deploy/sandbox), so isolation stays. The docs Limits section still states a lifetime "up to 30 minutes" (https://docs.deno.com/sandbox/), and the launch post repeats the same figure, so max_runtime keeps its current value. The proposed notes would claim the public record sets no hard maximum runtime, which that Limits section contradicts. I left every data field alone, re-verified the current notes against the security, volumes, and docs pages, bumped last_verified to 2026-09-21, and added no sources because all eight event citations were already listed.
gke-agent-sandbox: max_runtime runs until manually deleted
gke-agent-sandbox: max_runtime runs until manually deleted
GKE Agent Sandbox's max_runtime now reads "No fixed limit; standard sandboxes run until manually deleted". I fetched the Agent Sandbox lifecycle docs (https://agent-sandbox.sigs.k8s.io/docs/sandbox/lifecycle) and confirmed the page states that standard sandboxes run until manually deleted, with an optional shutdownTime or shutdown_after_seconds TTL scheduling deletion. The new wording replaces "Configurable TTL (no fixed maximum documented)", which drew on the same docs but named no source for the behavior. I added the lifecycle page to sources and set last_verified to 2026-09-21. The event proposed no other field changes, so the rest of the file is untouched.
No data change: Daytona docs still list all five SDKs
No data change: Daytona docs still list all five SDKs
The event proposed dropping Java from Daytona's sdks list, but its reasoning shows Java was never rechecked rather than removed. I fetched the four cited pages (https://www.daytona.io/docs/en/python-sdk.md, typescript-sdk.md, go-sdk.md, and ruby-sdk.md) and each confirms its SDK. The Java SDK reference at https://www.daytona.io/docs/en/java-sdk.md still documents an active SDK targeting Java 11+ with Gradle and Maven installs, and the docs index at https://www.daytona.io/docs/en/ links all five SDKs. The sdks list in data/providers/daytona.json already matches the live docs, so I edited nothing.
fly: no fact changes; keep $0.0027/hr headline price after verification
fly: no fact changes; keep $0.0027/hr headline price after verification
The event proposed raising the Fly Machines headline price from $0.0027 to $0.0028 per hour for shared-cpu-1x with 256 MB, citing https://fly.io/docs/about/pricing/. I fetched that page: the $0.0028 row sits in the Amsterdam (ams) regional table, which the page hides by default, while the default Ashburn (iad) table and Fly's pricing landing page (https://fly.io/pricing/) both list shared-cpu-1x with 256 MB at $0.0027 per hour and $1.94 per month. The $0.0028 figure is an Amsterdam-only rate, and $0.0027 is the lowest of the page's 18 regional tables, so I left price_headline at "From $0.0027/hr". I set last_verified to 2026-09-21; both pages were already in sources.
modal: no fact changes; keep free_while_idle false after verification
modal: no fact changes; keep free_while_idle false after verification
Modal's pricing page does say "You never pay for idle resources", but the hero line markets serverless billing platform-wide and says nothing about a stopped, paused, or sleeping sandbox. Modal's sandbox billing guide (https://modal.com/docs/guide/sandbox-resources) bills a running sandbox by the second on max(request, actual), documents no paused state, and answers inactivity with idle_timeout termination, so free_while_idle stays false. The proposed notes add no fact the file lacks and drop verified detail such as the Memory Snapshot GPU and instance-type restrictions, and the snapshot and VM docs (https://modal.com/docs/guide/sandbox-snapshots, https://modal.com/docs/guide/vm-sandboxes) still support the current notes, so I kept them. I verified the file against these pages and set last_verified to 2026-09-21; the event's three citations were already in sources.
e2b: verify docker=true, add docs.e2b.dev Docker example source
e2b: verify docker=true, add docs.e2b.dev Docker example source
The event reported E2B's `docker` field moving from null to true, citing the official Docker example page. I fetched https://docs.e2b.dev/template/examples/docker and confirmed the page supports the value: it describes a "Sandbox with Docker or Docker Compose installed for running containers", installs Docker from get.docker.com inside the sandbox, validates with `sudo docker run --rm hello-world`, and recommends at least 2 CPUs and 2 GB of RAM. data/providers/e2b.json already recorded `docker: true`, so the field value stays as is; I set `last_verified` to 2026-09-21 and added the cited URL to `sources`. The event's changed output covered only the `docker` field, so I left every other field alone.
ellipsis: update pricing_model, notes, and wake_on_request
ellipsis: update pricing_model, notes, and wake_on_request
Updated data/providers/ellipsis.json from the 2026-09-21 event, after fetching every cited page. pricing_model now describes usage-based billing: organizations pay for allocated CPU and memory while the sandbox runs plus model charges, personal accounts pay no sandbox compute, and a 10% fee applies to credit purchases (ellipsis.dev/docs/pricing states the $0.141912 per core-hour and $0.024192 per GiB-hour rates, that billing covers warm idle time, and that the 10% platform fee applies to credit purchases rather than individual sessions; ellipsis.dev/pricing lists the personal and organization split). notes now records the new idle model, where an idle session keeps its conversation and workspace for a later message (docs/lifecycle, docs/cloud-agents/conversations, docs/concepts/sandbox), credentials minted per session and revoked with the sandbox (homepage), the 1-hour session timeout cap, and the warm-idle billing conflict between the two pricing pages. wake_on_request moved from true to null because the docs only describe a follow-up message resuming an idle conversation, never inbound traffic waking a stopped sandbox. Two event claims needed different sourcing: the cited docs/cloud-agents/sandboxes URL now 308-redirects to /docs/environments and states neither the 1-hour cap nor short-lived credentials, so the cap is sourced to /docs/environments/schema (compute.timeout, 60 seconds to 1 hour, added to sources) and the credentials wording follows the homepage's "minted per session, revoked with the sandbox". max_runtime keeps its 24 h value because the event did not propose changing it, though the platform sandbox page that stated 24 hours has been rewritten and no current page states it; the schema's 1-hour cap is the better-sourced figure for a future turn.
CubeSandbox: re-confirm free_while_idle=true; bump last_verified
The event proposed setting free_while_idle to true, but data/providers/tencent-cubesandbox.json already held that value, set in commit c10ff9e on 2026-08-29 from the same pages. I verified the claim on both citations anyway: the lifecycle guide's state table says a paused sandbox keeps full state at zero CPU/memory cost, with CPU and memory physically reclaimed, and the introduction page says idle sandboxes are snapshot-suspended at zero resource cost and restored on the next request. The lifecycle URL is already in sources, and the event's cubesandbox.com/guide/introduction citation serves the same page as the existing introduction.html entry (I fetched both and the text is identical), so I added no source. The only edit is last_verified, now 2026-09-21. Every other field is untouched.
exe-dev: billing moves to subscription-only; usage_billed false
exe-dev: billing moves to subscription-only; usage_billed false
A snapshot monitor reports that exe.dev dropped usage-based compute pricing. The billing overview now describes two parts, a flat monthly subscription plus extra charges for going over disk or bandwidth, and each tier buys one pool of vCPU and RAM shared across a user's VMs, so pricing_model reads "Monthly subscription for pooled vCPU/RAM, plus usage charges for extra disk and bandwidth" and usage_billed is false, since compute capacity is reserved and billed monthly regardless of use (data/providers/exe-dev.json). I verified this against https://exe.dev/docs/billing/overview and https://exe.dev/docs/billing/subscriptions, which confirm prepaid monthly tiers; the old usage-pricing page now returns 404 and the pricing page lists no per-core rates. price_headline and notes still cite the retired usage rates because the event's delta covered only the two pricing fields, so they wait for an event that addresses them. Both new URLs are added to sources, deduplicated, and last_verified is 2026-09-20.
agent-substrate: duplicate event; changes already applied
Redelivery of event mevt_2a022441, which commit 1478c5b already applied two minutes before this event arrived. I re-checked the cited pages anyway: the GKE docs still state that idle agents are suspended and use no CPU or memory, so you pay for compute only while agents actively process tasks, and that open network connections do not survive suspension; the README still says the project is not ready for production use. data/providers/agent-substrate.json already carries these facts (free_while_idle and usage_billed true, active-only pricing_model, reconnect notes), lists all three citation URLs, and has last_verified 2026-09-20, so I changed nothing.
fly: duplicate event; $0.0027/hr price already applied
This turn redelivers the same event as turn 20260920T021420Z (identical event_id mevt_27287dbed189e26eda5bc65a2131e20b8517b3334d980ab74d980ab7), which commit 27e5232 already applied. The event raises one field, price_headline, from $0.0028 to $0.0027 per hour for shared-cpu-1x with 256 MB, and data/providers/fly.json already reads "From $0.0027/hr (shared-cpu-1x, 256 MB)" with last_verified 2026-09-20 and both citation URLs in sources. I re-fetched the cited pages anyway: fly.io/pricing/ lists shared-cpu-1x at 256 MB for $0.0027 per hour and $1.94 per month, and fly.io/docs/about/pricing/ shows $0.0027 per hour for that preset in its iad and ewr region tables (ams is $0.0028, so "From $0.0027" matches the lowest listed region). The stored value stands, so I edited nothing.
modal: re-confirm free_while_idle=false; bump last_verified
The event proposed setting free_while_idle to false, but data/providers/modal.json already held that value, so the stored data needed no change. I verified the claim on both cited pages anyway: modal.com/docs/guide/sandbox-resources says Modal bills Sandboxes by the second on max(request, actual), and modal.com/docs/guide/sandboxes documents idle_timeout as terminating an inactive Sandbox rather than pausing it for free, with no free paused state described. Both citation URLs were already in sources, so I added none; the only edit is last_verified, now 2026-09-20. Every other field is untouched.
aws-agentcore-runtime: V2 consumption price, idle sessions bill
aws-agentcore-runtime: V2 consumption price, idle sessions bill
Runtime V2 reached general availability, and the pricing page now splits microVM rates by platform version: v1 CPU at $0.0895 per vCPU-hour, v2 CPU at $0.1276 per vCPU-hour on consumption pricing, and a $0.0997 committed baseline that launches by October 2026 (https://aws.amazon.com/bedrock/agentcore/pricing/). I set price_headline to the V2 consumption rate because the what's-new post announces the new Runtime as generally available and tells customers to set platformVersion to V2 (https://aws.amazon.com/about-aws/whats-new/2026/09/new-agentcore-runtime-generally-available/); the docs still say V1 is the default, so the notes field now records the V1 rate alongside it. I set free_while_idle to false: the pricing page bills the session span from microVM ready, through idle periods, to termination, and adds system overhead plus a 128 MB memory floor, so idle time costs money, and a stopped instance session still bills EBS storage. cold_start keeps the measured P75 of 1.9 to 2.0 seconds for 200 MB to 2 GB images and now names Runtime V2, which the docs page describes as restoring a prepared snapshot for each new instance (https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-how-it-works.html). Sources gain the docs page and the event's pricing URL, deduplicated by dropping an http twin of the pricing page. I fetched all three cited pages and confirmed each figure on the page itself; last_verified stays 2026-09-19 and no other field changed.
Add AWS AgentCore Runtime, V2 microVM compute with elastic memory
Add AWS AgentCore Runtime, V2 microVM compute with elastic memory
Created data/providers/aws-agentcore-runtime.json for AWS AgentCore Runtime, which the site did not track; the existing AWS row covers only the Code Interpreter. I fetched both cited pages and confirmed each claim on the page itself. The what's-new post (https://aws.amazon.com/about-aws/whats-new/2026/09/new-agentcore-runtime-generally-available/) states that the runtime is serverless microVM compute with hardware-enforced session isolation, reclaims unused memory during a session so billing tracks actual use rather than the peak, and delivers a P75 cold start of 1.9 to 2.0 seconds for 200 MB to 2 GB images versus 5.4 to 30 seconds with V1, initially in five regions with platformVersion set to V2. The ML blog post (https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/) confirms those figures and adds that billing follows resource usage with no standing charge for provisioned capacity, which supports usage_billed true. Neither page states a dollar rate, a max session length, Docker or GPU support, or a shipped pause/resume, so price_headline, max_runtime, memory_snapshots, wake_on_request, free_while_idle, docker, gpu, and sdks stay null. The website comes from the event and resolves live. I left providers.json alone, matching earlier new-product turns; the census entry gets added in the follow-up research pass.
box-by-ascii: renamed to boat; update name, website, summary, notes
box-by-ascii: renamed to boat; update name, website, summary, notes
ASCII renamed Box to boat: box.ascii.dev now 301-redirects to boat.dev, and the homepage and quickstart there describe full Linux cloud VMs that agents or their harnesses control through the CLI, API, SDKs, SSH, and desktop access. data/providers/box-by-ascii.json now records the new name, website, summary, and notes. The event cites docs.boat.dev/billing for the trial limits, but that page covers plan mechanics and never states them, so I verified the 2-hour free-trial auto-stop cap on docs.boat.dev/long-running-tasks and added that URL to sources. Sources also gained the event's three citations plus docs.boat.dev/platform-guide, which supports the previews use case in the summary. last_verified is 2026-09-19 and no other field changed.
vercel: update cold_start with snapshot restore p75/p95 figures
vercel: update cold_start with snapshot restore p75/p95 figures
The event's only supported change is the cold_start field for Vercel Sandbox, so that is all I edited. I fetched all three cited pages and confirmed each claim on the page itself: the docs say sandboxes start in milliseconds (vercel.com/docs/vercel-sandbox), resuming from a snapshot is faster than starting fresh (vercel.com/docs/sandbox/concepts), and the engineering post states p75 snapshot restores dropped to sub-second and p95 to 5 s (vercel.com/blog/optimizing-vercel-sandbox-snapshots). data/providers/vercel.json now reads "Milliseconds for normal startup; snapshot restores p75 under 1 s and p95 about 5 s", last_verified is 2026-09-19, and sources gained vercel.com/docs/vercel-sandbox, the one event citation not already listed. No other field changed.
sailboxes: document optional max_lifetime_seconds cap in max_runtime
sailboxes: document optional max_lifetime_seconds cap in max_runtime
Changed max_runtime in data/providers/sailboxes.json from "No fixed limit" to "Unlimited by default; optional max lifetime up to 4,294,967,295 s". Sail's lifecycle page now documents max_lifetime_seconds, a whole-second value from 1 through 4,294,967,295 that permanently terminates a Sailbox after a fixed wall-clock lifetime including sleep and paused time; the same page and the Python SDK reference both say omitting the setting gives unlimited lifetime. I fetched both cited URLs and confirmed the text on the pages themselves. Both citations were already in the file's sources, so none were added. last_verified is now 2026-09-19, and no other field changed.
cloudflare: cold_start already ~1-3 s, reverified, added citation
The event proposed a cold_start of ~1-3 seconds for Cloudflare Sandboxes, but data/providers/cloudflare.json already held that value and the event's previous snapshot showing null was stale. I fetched the cited page, https://developers.cloudflare.com/containers/concepts/architecture/, which states that container cold starts "can often be in the 1-3 second range", depending on image size and code execution time, which confirms the stored value. I set last_verified to 2026-09-19, added that URL to sources, and left every other field alone.
codesandbox: refresh cold_start with state-based resume times
codesandbox: refresh cold_start with state-based resume times
Updated data/providers/codesandbox.json: cold_start now reads "1-3 s to create from a template; 0.5-2 s to resume from a memory/disk snapshot, 5-20 s from a disk snapshot, 20-60 s from archive", replacing the older fork-based wording, and last_verified is 2026-09-19. The event also proposed docker: true, but the file already said true, so nothing changed there. The resume figures come from the CodeSandbox core concepts docs (https://codesandbox.io/docs/sdk/core-concepts), which state 0.5-2 seconds from a memory/disk snapshot, 5-20 seconds from disk, and 20-60 seconds from archive, and from the resume docs (https://codesandbox.io/docs/sdk/resume), which state 1-3 seconds regular and 10-60 seconds archived; the 1-3 s create time appears on the same core concepts page. Cloudflare blocked direct access to codesandbox.io from this environment, so I confirmed those two pages against their Wayback Machine copies (April and March 2026, both reporting status 200 with the quoted figures). The blog post (https://codesandbox.io/blog/joining-together-ai-introducing-codesandbox-sdk) and the live Together AI docs (https://docs.together.ai/docs/together-code-sandbox) confirm the Docker claim and template cloning times; all three newly cited URLs are now in sources, deduplicated. No other fields in the event's changed output differed from the file.
modal: cold start ~1 s per docs; VM Sandboxes recommended for Docker
modal: cold start ~1 s per docs; VM Sandboxes recommended for Docker
Modal's cold-start guide says containers boot in about one second and take from seconds to minutes to become warm (https://modal.com/docs/guide/cold-start), so cold_start now reads "~1 s container boot; warm-up can range from seconds to minutes". It replaces "<0.5 s median", a figure from the scaling blog that describes the Beta v2 scheduler; current docs outrank blog posts. Notes now record that Modal recommends VM Sandboxes for running Docker (https://modal.com/docs/guide/vm-sandboxes). I merged that into the existing notes rather than replacing them, since the 7-day Memory Snapshot retention and termination limits the event also cites were already covered and still appear on the snapshots page (https://modal.com/docs/guide/sandbox-snapshots). All three event citations were already in modal.json's sources, so that list is unchanged, and last_verified is now 2026-09-19.
fly-io-sprites: verify max_runtime, no value change
fly-io-sprites: verify max_runtime, no value change
The event proposed setting max_runtime to "No fixed time limit stated", citing the Fly.io design post. I fetched https://fly.io/blog/design-and-implementation/ and it lists "No time limits" among the properties of Sprites, and the lifecycle docs at https://docs.sprites.dev/concepts/lifecycle/ state no execution deadline. The file already records "No fixed limit", which states the same fact, so I left the value alone rather than rewrite it to an equally supported wording. I refreshed last_verified to 2026-09-18; the citation URL was already in sources, so nothing was added.
morph: record Morph Cloud subscription tier prices in pricing_model
morph: record Morph Cloud subscription tier prices in pricing_model
Morph Cloud's subscribe page now shows priced monthly tiers: Developer at $0/month with MCUs purchased separately, Team at $40/month with 1000 starting MCUs, and Scale at $250/month with 7500 starting MCUs, with extra credits billed pay-as-you-go. I wrote those tiers into pricing_model in data/providers/morph.json, set last_verified to 2026-09-18, and added the plans doc (https://cloud.morph.so/docs/documentation/setup/plans), which confirms MCUs meter vCPU-, RAM-, and disk-hours plus snapshot storage, to sources. I left price_headline unchanged at $0.05 per MCU: the event claimed the standalone MCU rate is no longer stated, but the live subscribe page (https://cloud.morph.so/web/subscribe) still says "Based on standard MCU rate of $0.05", so the existing value remains the better-supported one.
blaxel: add standby snapshot rate to price_headline, cite new sources
blaxel: add standby snapshot rate to price_headline, cite new sources
price_headline now names both rates Blaxel states for sandboxes: $0.0000115 / GB RAM-second for active compute and $0.20 / GB-month for standby snapshot storage. I verified both figures in the Sandboxes table at https://blaxel.ai/pricing and on https://blaxel.ai/platform/storage; the $0.000006 and $0.000007 rates nearby belong to Batch API and MCP hosting, so the event read the right row. The event also reconfirms gpu as false, which the file already stated, and Blaxel's own comparison post says "Blaxel doesn't offer GPU instances" (https://blaxel.ai/blog/blaxel-vs-daytona), so that field needed no edit. pricing_model stayed as is: the event's wording restates the same facts from the same pricing page. I left pricing.html out of sources because it serves the same content as the already-listed https://blaxel.ai/pricing. One open item for a later turn: Blaxel charges $0.20 / GB-month for snapshot storage while a sandbox idles in standby, so free_while_idle reads as false, but the file says true and this event's change set doesn't include that field.
aws-lambda-microvms: cold_start near-instant, no figure published
aws-lambda-microvms: cold_start near-instant, no figure published
The event supports one change: cold_start for AWS Lambda MicroVMs now reads "Near-instant; no numeric typical duration published", replacing the bare "near-instant" carried since July. I verified this against the three cited pages before editing. The AWS News Blog says launches and idle resumes "achieve near-instant startup latency", the MicroVM images doc says a MicroVM "resumes directly from the snapshotted state, providing rapid startup times", and the launching doc publishes no numeric figure, saying resume latency depends on the suspended state's size and the /resume hook. I set last_verified to 2026-09-17 and added the images doc URL to sources; the news blog and launching doc URLs were already listed. The event reports no change to any other field, so the rest of the file is untouched.
deno-sandbox: re-verify SDK languages; no field changes
deno-sandbox: re-verify SDK languages; no field changes
The event reported Deno Sandbox SDKs as JavaScript, TypeScript, and Python. I fetched the three cited pages and confirmed the claim: the product page says the SDK "currently supports JavaScript, TypeScript, and Python", and the docs list the JavaScript SDK (@deno/sandbox on jsr and npm, running on Deno or Node.js 24+) and the Python SDK (deno-sandbox on PyPI, Python 3.10+). data/providers/deno-sandbox.json already records that set, so no field value changed; I moved last_verified to 2026-09-17. The citation URLs (deno.com/deploy/sandbox, docs.deno.com/sandbox/, docs.deno.com/sandbox/getting_started/) were already in sources, so the deduplicated list is unchanged.
Set Agent Substrate free_while_idle to true
The event proposed one change for the existing agent-substrate row, and I verified it before editing. The GKE documentation states that idle agents are suspended without CPU or memory and that you pay for compute only when agents actively process tasks (https://docs.cloud.google.com/kubernetes-engine/ai-ml/about-agent-substrate), and the Google Cloud blog describes the same zero-idle model, releasing resources the moment an agent pauses (https://cloud.google.com/blog/products/containers-kubernetes/agent-substrate-available-on-gke). This matches how the site already treats comparable products, such as Morph and Lambda MicroVMs, which are true for this field with storage caveats noted. I set free_while_idle to true, updated last_verified to 2026-09-17, and left sources unchanged because both event citations were already listed. The file passes box validation.
brig: set gpu false per non-goals doc; docker already false
brig: set gpu false per non-goals doc; docker already false
Brig's gpu field moves from null to false: the project's non-goals page lists GPU scheduling as a refusal through August 2027 and passes no device into a microVM (https://raw.githubusercontent.com/brig-sh/brig/main/docs/non-goals.md). The file already said false for docker, which matches the event's value, so I changed nothing there. Both cited pages back that reading: the non-goals page refuses nested containers and a Docker daemon inside the guest, and the runtimes page accepts docker only as a host-side stand-in for nerdctl (https://raw.githubusercontent.com/brig-sh/brig/main/docs/runtimes.md). I fetched both pages, added their URLs to sources, and set last_verified to 2026-09-17. Every other field is untouched because the event's change basis covers only docker and gpu.
fly: GPU citation 404s, fields already current; refresh last_verified
The event proposed gpu false, notes, and sdks [Go, Python, Ruby], but fly.json already carries the first and last of those values, so no fact changed. I verified sdks against the fly-openapi-sdk repo (go/, python/, ruby/ client directories) and fly-go, and the suspend/resume page at fly.io/docs/reference/suspend-resume/ still states that snapshots can be discarded after deploys, host migration, corruption, or maintenance while volume data survives, which matches the current notes. The event's GPU excerpts ("deprecated and will be unavailable after August 1") cite fly.io/docs/gpus/, which returns 404 today and has no entry in the docs nav, so I could not confirm them and left the notes wording alone. I updated last_verified to 2026-09-17.
Add Agent Substrate, Google Cloud's open-source agent runtime on GKE
Add Agent Substrate, Google Cloud's open-source agent runtime on GKE
Created data/providers/agent-substrate.json for Agent Substrate, the
open-source agent execution runtime that Google Cloud announced for GKE on
September 15, 2026. I fetched the cited announcement
(https://cloud.google.com/blog/products/containers-kubernetes/agent-substrate-available-on-gke)
and confirmed each claim on the page itself: Agent Substrate runs AI-agent
workloads in hardware-isolated Cloud Hypervisor microVMs or gVisor sandboxes,
delivers sub-500ms resume operations, is engineered for millions of sandboxes
at 10x higher density than standard container runtimes, and is available to
GKE customers for non-production workloads with production GA support by
allowlist. That supports the new file's isolation, cold_start, notes, and
summary fields, and the page's ate.dev link gives the website. The event
cites no pricing or other specs, so every other field stays null pending the
first research pass. I left providers.json alone; the census entry for a new
product gets added in the follow-up research turn.
openai-hosted-sandboxes: pricing reconfirmed, no field change
openai-hosted-sandboxes: pricing reconfirmed, no field change
This snapshot proposed new price_headline and pricing_model strings for OpenAI Hosted Sandboxes. I fetched both cited pages and confirmed the figures: the pricing page lists containers for Hosted Shell and Code Interpreter at $0.03 for 1 GB, $0.12 for 4 GB, $0.48 for 16 GB, and $1.92 for 64 GB per 20-minute session per container, with eligible sessions billed by the minute and a 5-minute minimum (https://developers.openai.com/api/docs/pricing), and the hosted-sandboxes page says hosted sandboxes use standard container rates, with model usage billed separately (https://developers.openai.com/api/docs/guides/agents-api/environments/openai-hosted). The file's price_headline already states those figures, and its pricing_model already covers per-minute billing, the 5-minute minimum, and separate model charges, so I kept both rather than swap in an equally-supported rewording. Both citation URLs were already in sources, so the only edit is last_verified, set to 2026-09-16.
modal: cold_start <0.5 s median; VM Filesystem Snapshots in notes
modal: cold_start <0.5 s median; VM Filesystem Snapshots in notes
Modal's engineering post on scaling to 1 million concurrent sandboxes states that start times, measured from the client's create call to when a sandbox can run user code, are under half a second at the median, so cold_start now reads '<0.5 s median' (https://modal.com/blog/scaling-to-1-million-concurrent-sandboxes-in-seconds). I fetched all five cited pages and confirmed each claim. The event's replacement notes text restated what the file already says and would have dropped verified caveats (Memory Snapshot Alpha status, instance-type matching, snapshot retention, GPU preemption), so I kept the current notes and restored the one point the event re-surfaced: VM Sandboxes support Filesystem Snapshots, which the VM Sandboxes guide states (https://modal.com/docs/guide/vm-sandboxes). I added the two new blog URLs to sources and set last_verified to 2026-09-16. The event proposed no other field changes.
brig: no change; docker citations cover the host runtime, not the guest
brig: no change; docker citations cover the host runtime, not the guest
The event proposed changing Brig's docker field from false to true, and I fetched all three cited pages to check. The excerpts are quoted accurately, but they describe the host-side runtime that boots the sandbox, not Docker inside the guest: docs/install.md (https://github.com/brig-sh/brig/blob/main/docs/install.md) accepts docker in nerdctl's place for an image that carries its own kernel and refuses genericBoot profiles on it, docs/guest-image.md (https://github.com/brig-sh/brig/blob/main/docs/guest-image.md) repeats that refusal, and docs/security.md (https://raw.githubusercontent.com/brig-sh/brig/main/docs/security.md) prints an ISOLATION row for a sandbox booted through docker over containerd with runc, where the guest shares the host kernel. The site's docker column asks whether Docker containers can run inside the sandbox, and no page I checked, runtimes.md included, states that for Brig. I left data/providers/brig.json unchanged.
Add Brig, NOFire AI's open-source microVM sandbox for coding agents
Add Brig, NOFire AI's open-source microVM sandbox for coding agents
Created data/providers/brig.json for Brig, the Apache 2.0 microVM sandbox for AI coding agents that NOFire AI released on September 15, 2026. NOFire's press release (https://www.nofire.ai/newsroom/brig-open-source-launch) and the product site brig.sh state the open-source licence, the ephemeral microVM with hardware-enforced isolation, curated profiles for Claude Code, Codex, Cursor, Gemini, Grok and opencode, Apple Silicon macOS, Linux on x86_64 and ARM, and cloud hosts, so both pages are in sources. Every other field stays null pending the first research pass. The event's two other citations describe OpenAI's Agents API beta and never mention Brig, and OpenAI's page returns only a JavaScript challenge to curl, so they support no change here and no existing provider file was edited.
fly-io-sprites: confirm Firecracker microVM isolation, no field change
fly-io-sprites: confirm Firecracker microVM isolation, no field change
The event proposed setting the isolation field for Fly.io Sprites to "Firecracker microVM", but data/providers/fly-io-sprites.json already stated that value, so no field changed. I fetched both cited pages to confirm: https://fly.io/learn/fly-vs-modal/ says a Sprite "boots as a Firecracker microVM", and https://docs.sprites.dev/ describes Sprites as hardware-isolated environments running on a dedicated microVM. I set last_verified to 2026-09-15 and added the fly-vs-modal page to sources; docs.sprites.dev was already listed.
novita: verify cold_start, keep value, add PR citation
The event proposed setting Novita's cold_start to "<200 ms for startup; paused-sandbox resume is typically about 1 second". I fetched all three cited pages before touching anything. The landing page states "Launch sandbox instances in under 200ms on average" under a "Sub-second startup" heading (https://novita.ai/sandbox), the overview says a paused sandbox resumes "typically in about a second" (https://novita.ai/docs/guides/sandbox-overview), and the launch release quotes a "Sub-200ms average startup time" (https://www.prnewswire.com/news-releases/novita-ai-launches-sandbox-to-secure-openclaw-hermes-agent-and-autonomous-systems-302755870.html). data/providers/novita.json already reads "Under 200 ms on average for create; ~1 s to resume from paused", which states both figures with the same support, so I left the value alone rather than rewrite it to an equally-supported alternative. I set last_verified to 2026-09-15 and added the PR Newswire URL to sources; the other two citations were already listed. cold_start is the only field where the event's output differs from its previous snapshot, so no other field changed.
Verified Beam cold_start; kept value, refreshed last_verified
The event proposed setting Beam's cold_start to "~1–3 seconds". I fetched both cited pages and they support the figure: the sandbox overview states "Sandboxes cold boot in 1–3 seconds, even with dependencies included" (https://docs.beam.cloud/v2/sandbox/overview), and the cold-start page says container start is typically under 1s while image-load and application-start times vary (https://docs.beam.cloud/v2/topics/cold-start). data/providers/beam.json already reads "1–3 s cold boot; container start under 1 s", which states both figures, so I left the value alone rather than rewrite it to a less detailed, equally-supported alternative. I set last_verified to 2026-09-15 because I verified the claims today. Both citation URLs already appear in sources, so the deduplicated list is unchanged.