Runtime changelog, 28 September 2026
What shipped in Runtime Cloud on 28 September 2026: a console that reports your day; each sandbox's commands, on its page; scheduled jobs; secrets for jobs; the region is now us-east; a sandbox from a browser; passkeys; a Go SDK; a Ruby SDK; a Java SDK; faster starts, pauses and stops; persistence can be turned off, and a stopped persistent sandbox deleted; and agents can list images, volumes, volume backups and snapshots.
A console that reports your day
Home, Sandboxes, Images, Volumes, Usage & billing and Agents & API keys each open on what needs you, then today in a line, two charts and the list. Sandboxes describes today's runs as a whole, hour by hour against yesterday, by who started them and by image, and its list opens on what runs now, with search over every day. A sandbox's page says how it ended and why, draws its life from start to stop and copies what happened for your agent. Usage & billing shows spend by who started it and each key's use against its daily limit. Agents & API keys, in Settings, tells agents connected from a tool apart from API keys. Today is counted in your browser's time zone.
Each sandbox's commands, on its page
A sandbox's page lists the commands run in it, pytest · exit 1 · 28 s, with failures in red and a running one as running: on its Activity tab while it runs, and in its life once it ends. Runtime keeps each command's program name, exit code and duration for 14 days, never its arguments. See observability.
Scheduled jobs
Run a command in a fresh sandbox once at a time you choose or on a cron schedule in your timezone, with each run's exit code and output kept, retries when you ask for them, and pause, resume and cancel: runtime job create nightly --cron "0 3 * * *" -- python3 report.py, runtime.jobs in the SDKs, or the runtime_job MCP tool. Runs are paid sandboxes at the sandbox rates. See scheduled jobs.
Secrets for jobs
runtime secrets set NAME --jobs keeps a copy a job puts into its run's environment (--secret NAME on runtime job create); with --host as well, one command stores it for sandboxes and jobs alike. The jobs copy can be rotated and read back; the sandboxes' copy still never can.
The region is now us-east
It was us-east-vin, the name of one building; a region is named for its place, so more data centres nearby can join it. Every sandbox, snapshot, volume, image and job moved with it and keeps running. Asking for us-east-vin now answers invalid_region and names us-east, and an identity token's region claim reads us-east, so update a trust policy that names the old one. withruntime 0.8.4 sends us-east as a job's default region; update with npm i withruntime@latest or pip install -U withruntime. A job that names a region Runtime does not have is now refused when you create it, rather than waiting at every run.
A sandbox from a browser
A sandbox session is a short-lived token your own web page uses to run commands, read and write files and reach previews in one sandbox, with no API key and no proxy of your own. It cannot stop, extend or change the sandbox, lasts 1 hour unless you ask for up to 24 hours, can be revoked at once, and is answered only from the pages you list. sbx.sessions.create({ origins }) makes one and Sandbox.fromSession({ token, sandboxId }) uses it, from withruntime 0.8.3; Blaxel's sandbox.sessions and fromSession now work in the drop-in. See JavaScript and Python.
Passkeys
Sign in with a passkey, with no email link and no code, or use one as the second step in place of an authenticator app's code. Add them under Settings → Two-step sign-in, beside the app or instead of it. See two-step sign-in.
A Go SDK
go get withruntime.com/go installs one Go client for every Runtime product, with a context.Context on every call and only the standard library underneath. See the Go guide.
A Ruby SDK
gem install withruntime installs one Ruby client for every Runtime product, with only the standard library underneath. See the Ruby guide.
A Java SDK
com.withruntime:withruntime on Maven Central is one Java client for every Runtime product, for Java 17 and later with nothing beyond the JDK. See the Java guide.
Faster starts, pauses and stops
A new sandbox runs its first command 331 ms after the create request at the median, down from 374 ms, and 30 of 40 creates were running in under 200 ms. A pause answers in 165 ms, down from 226 ms, and a snapshot is ready in 3.27 s. On the server, without the network to Virginia, a pause answers in 81 ms, a wake in 75 ms and a stop in 37 ms; the speed page now shows those figures beside the ones from a laptop.
Persistence can be turned off, and a stopped persistent sandbox deleted
runtime sandbox update <id> --persistent off, update({ persistent: false }) or :update with {"persistent": false} now works as the guides said: a running sandbox stops paying for its disk at once, and a stopped one has its disk deleted and its name freed. A stopped persistent sandbox is listed by runtime ls, runtime sandbox ls and GET /v1/sandboxes with the live ones, since its disk is still kept and billed.
Agents can list images, volumes, volume backups and snapshots
Over MCP, runtime_image, runtime_volume, runtime_volume_backup and runtime_snapshot take the action list, with the filters and pages of GET /v1/images, /v1/volumes, /v1/volume-backups and /v1/snapshots: state, limit, cursor from the last page's nextCursor, and name, or volumeId for backups and name and sandboxId for snapshots. Their get now reads one by id. See MCP.