A failed fork deletes the copies it started

When POST /v1/sandboxes/{id}:fork fails after some copies have started, the copies that started are now deleted and no longer appear in GET /v1/sandboxes. The error's details.startedSandboxIds still names them, and details.copiesDeleted is true. When the error is a 5xx, a failure on Runtime's side (for example, no capacity for a later copy, a copy that does not reach running in time, or the source cannot be woken), none of their running time is billed and details.copiesBilled is false. When it is a 4xx, caused by the request or the account (a limit or quota, or a copy or the source deleted or changed during the fork), the time they ran is billed. A copy whose create completed after the fork had already failed is deleted too. A copy that could not be deleted at once is named outside details.deletedSandboxIds, details.copiesDeleted is false, and it is deleted within 15 minutes. If the server handling the fork stops before it returns, the fork is marked failed with a 500 once it has run longer than any fork can (15 minutes, plus about 20 seconds for each GiB of the source's memory), and its copies are deleted unbilled within 15 minutes after that. A fork that does not answer within the request deadline is a failure on Runtime's side, and its copies are not billed; if your client closes the connection before the fork answers, the copies are deleted and billed for the time they ran. Previously these copies kept running, and were billed, until you stopped them.