Runtime changelog, 14 October 2026
What shipped in Runtime Cloud on 14 October 2026: swarm worker keys stay inside their own sandboxes; mkdir -p /workspace through the files API is success; a key makes more keys over the API, with no browser; the Python, Go, Java and Ruby SDKs no longer take a failure or a cut stream for a success; free usage is for trying Runtime, and a lower limit applies to every account at once; without credit, fewer sandboxes at once, and a few new limits; every limit is published, and an account with credit is charged, not capped; a stop or delete never loses a snapshot or a sandbox's disk; an agent with no shell can open and pay for an account over MCP; no paid-or-trial choice in the SDKs; a preview, port or private stream keeps going when you extend the time limit; pages in the console answer faster; a working sandbox's memory is not swapped out; a slow command start no longer holds up the sandbox's other calls; snapshots of badly fragmented disks no longer stall the host; a short database outage no longer fails a start, stop, wake or delete; a member an owner removed stays removed; and a wallet top-up that never reached the payment provider says so.
Swarm worker keys stay inside their own sandboxes
A key made by another key with reach agent now gets 403 forbidden on the account's own settings, whatever its person's role: closing the account, webhooks, telemetry exports, the audit log, credit and billing, secrets, domains and networks. It still runs sandboxes, reads its own usage and makes its own keys; an account-wide one keeps everything. See Run a swarm.
mkdir -p /workspace through the files API is success
files:mkdir (and the files tool's mkdir) on /workspace or / answered 400 "Refusing the root of a tree"; it now answers created: false, as for any folder that already exists. And GET /v1/usage?key= with something that is not a key's id answers 400 invalid_request rather than 500.
A key makes more keys over the API, with no browser
For agent swarms and for accounts opened with a wallet. POST /v1/keys, GET /v1/keys and DELETE /v1/keys/{id}, runtime.keys.create/list/revoke/usage in the TypeScript SDK, and runtime keys create --name worker-1 --daily-limit 5 with a key on the machine (--browser keeps the browser approval). New: runtime keys ls, runtime keys usage <keyId>, runtime keys revoke <keyId>, and GET /v1/usage?key=. Each key is its own agent, a new key never has more than its maker, and the daily limits of the keys a key made add up to at most its own. See run a swarm.
The Python, Go, Java and Ruby SDKs no longer take a failure or a cut stream for a success
A call that runs longer than 90 seconds gets its status early and its answer after; when that answer is an error (a create whose host was lost, say), Go, Java and Ruby now raise it, as JavaScript and Python did, instead of returning an empty result. A file read in Go, Java or Ruby is checked against the length and SHA-256 the API sends with it, read again if it came short, and refused rather than returned short. In Python's synchronous client, an event stream (a watch, a log follow) whose connection closed part way raises instead of ending as if it had finished. Each arrives with that SDK's next release.
Free usage is for trying Runtime, and a lower limit applies to every account at once
An account that has never paid gets its 100 free hours (100 GiB-hours of memory and 25 vCPU-hours of active CPU) once, across the 30 days from its opening, and then nothing until it adds credit. An account that has paid gets them every month, as before. Saved copies (10 GB) and disks (5 GB) stay monthly for every account, and the startup hours are unchanged. GET /v1/usage shows freeUntil on each of allowances: when the free machine time ends, or null once the account has paid. Usage & billing and the sign-in and offer pages say it the same way.
Without credit, fewer sandboxes at once, and a few new limits
Four sandboxes run at once, not eight, with at most 8 vCPU and 16 GiB in all, not 16 and 32. An account keeps at most 10 sandboxes, running, paused or stopped (a create past it is refused with no_credit_kept_limit, 409), and makes at most 50 a day, in any 24 hours (no_credit_daily_limit, 429). Waking, resuming or deleting a sandbox you already keep is never refused. Scheduled jobs do not run without credit: a job waits with blockedReason credits until the account holds credit. Adding credit lifts all of these. Public previews and ports other than 80 and 443 were already for paid accounts only. The Python SDK's Inspect integration defaults to four sandboxes at a time.
Every limit is published, and an account with credit is charged, not capped
With credit, an account keeps up to 10,000 volumes, snapshots, images, volume backups, jobs and secrets (5 volumes before), with no limit on the GBs of volumes and images, which its credit pays for. A quota_exceeded now names the limit and its number in its message and in details (limit, max, raise), including the vCPU, memory and disk limits that said only "quota exceeded". The limits guide lists every one, and the console's Limits page shows each with what the account uses.
A stop or delete never loses a snapshot or a sandbox's disk
Stopping or deleting a sandbox while a snapshot of it is still being taken is now refused with snapshot_in_progress (409) and nothing changes, instead of destroying the sandbox and failing the snapshot; wait until the snapshot is ready and stop it again (see troubleshooting). A stop that comes while a paused sandbox is waking from its saved copy, or is still being copied to another host, or just after that copy was restored, keeps the copy and the disk. A resize of a sandbox that only its saved copy holds wakes it from that copy. A volume lost with its host keeps its newest ready backup past its retention, so the backup the error tells you to restore from is still there.
An agent with no shell can open and pay for an account over MCP
Two new tools, runtime_wallet_open and runtime_wallet_claim (also at /mcp?signup=wallet), open an account paid in USDC: the first answers with an address per network, the exact amount and a claim code; the second connects once the payment lands. There is no free trial on this path. The Go, Ruby and Java SDKs gain the wallet calls, and runtime_connect picks up a key saved after the MCP server started. See pay with stablecoins.
No paid-or-trial choice in the SDKs
Free usage comes first, then credit, and there is nothing to choose, so the examples and options that showed funding are gone and Harbor and Inspect tell an account without credit to add credit for a bigger size. The option is still accepted (deprecated in Go and Java), so existing code runs.
A preview, port or private stream keeps going when you extend the time limit
A long download through a private preview was cut at the end of the limit it began under even though you had extended the sandbox, and it now carries on into the new limit. A limit that really ends still cuts it.
Pages in the console answer faster
Every page waits less for the sign-in check and makes fewer database round trips, a click from page to page no longer waits a fixed 0.3 seconds, and a new account's Home is built once, not twice.
A working sandbox's memory is not swapped out
A running sandbox keeps its RAM in memory, and one near its own memory ceiling gives back disk cache before the kernel swaps its RAM.
A slow command start no longer holds up the sandbox's other calls
Starting a command no longer blocks listing processes, reading or writing files and killing processes while it waits for a slot. A command that waits in line longer than 6 seconds is refused as busy, which is safe to retry, instead of ending with an unknown outcome.
Snapshots of badly fragmented disks no longer stall the host
A snapshot of a private disk of 400,000 extents took the host's daemon 8.2 seconds to map and now takes 0.32 seconds, with the same result. A busy host also keeps every running sandbox's disk use measured.
A short database outage no longer fails a start, stop, wake or delete
A broken database connection no longer ends one of these as operation_failed, and after a database restart the first request on a reconnected connection is answered instead of failing with the old session's error.
A member an owner removed stays removed
If an owner removes someone, or they leave, after your directory had deactivated and an invitation had brought them back, single sign-on directory sync no longer restores their membership when it turns them on again.
A wallet top-up that never reached the payment provider says so
A claim whose top-up was never created no longer shows a pay-by time; it says to send the top-up again with the claim code.