Sandboxes: networkRules in API v2
POST /v2/sandboxes accepts spec.networkRules (internet, allow, deny, connect), the same rules as the v1 network field, enforced on every connection the sandbox opens. A rule that cannot be parsed returns 400 invalid_network_rule in v1 and reports the sandbox as failed in v2. Changing networkRules after a sandbox starts stops it with its disk kept; create a new sandbox to use different rules. Network rules on a copy of a snapshot are not supported yet: v1 returns 501 feature_unavailable, and v2 reports the sandbox as failed. A fork keeps its source's rules.
CI/CD checks that run their setup start jobs immediately
When a check runs its setup (its key has no warm snapshot yet), its first job now starts on that set-up machine as soon as the setup ends. Before, the machine was deleted once it was copied, and every job waited for machines started from the copy, which only one server held: when that server was full, a check could wait minutes with no job running. Machines for the rest of its work still start from the copy.
Usage export shows the carry on each outbound traffic row
In GET /v1/usage/export, each sandbox egress row's outbound measurements now include carried: the fraction of a microdollar the row started from, carried in from earlier outbound traffic in the same month, in bytes times microdollars per decimal GB. The row's charge plus written_off_micros equals floor((carried + billable bytes × rate) / 1,000,000,000). Charges are unchanged.
Agent sessions keep their task in the console after their history is archived
A session's history moves to cold storage a week after the session ends. The console now still shows what the session was asked to do: the opening words of its first input. Before, the console showed no task for these sessions. Sessions archived before this change still show no task in the console; their full history is still available through the API.
The MCP server accepts newer protocol versions
A client that requests an MCP protocol version newer than the server supports, such as 2026-07-28, now gets a working session at the server's newest version (2025-11-25). This applies to initialize and to the MCP-Protocol-Version header on later requests. Before, those later requests returned 400 Bad Request: Unsupported protocol version, so clients such as Claude's connectors could not connect. A malformed version, or one older than the server supports, still returns 400.
A sandbox has all its memory when its create returns
POST /v1/sandboxes now returns only after the sandbox's guest holds all the memory it asked for (memoryMiB), so /proc/meminfo reports the full amount from the first command. Previously a sandbox could start with part of its memory and receive the rest during its first seconds. A sandbox created with a memory size other than the default can take longer to create, while the memory past its starting size is added.
A job is no longer failed when its machine is paused by its host
When a check's machine stops responding because its host paused it, the tasks it held now run on the check's other machines and do not count toward the three losses that end a job with "Lost 3 times, never reported".
A check that times out while jobs wait for a machine reports "Could not run"
When a check's timeout: expires while every job that has not finished is still waiting for a machine that was refused for lack of capacity, those jobs now end with the reason no machine came for its jobs in N minutes (...); re-run it once there is room, and the check's GitHub run is titled "Could not run". Before, those jobs were reported as "Ran past its time limit", as if the code under test had hung.
A sandbox's lease counts from when it first runs
A paid sandbox that waits in starting for its server to have room now has its lease renewed while it waits, so it is no longer stopped with time_limit before it ever runs, and its server no longer refuses the start as invalid_lease once the wait used up its lease. No compute is charged for the time spent waiting. diskKept on a stopped sandbox is now true only when POST /v1/sandboxes/{id}:restart starts it from its disk: a stopped sandbox whose server was lost now returns diskKept: false.
Evictable sandboxes
A create or update can now set evictable: true. Runtime may then delete the sandbox once it has been paused or stopped for at least 15 minutes and its server needs the disk, the sandbox idle longest first. It is deleted as by DELETE; a running sandbox is never deleted for it. Use it for work you can recreate, such as build caches and CI machines. Sandboxes return the setting in evictable, and every SDK accepts it on create.