Retry creation without losing the machine
A launch request can reach the server even when its response never reaches the client. Starting again with a new operation key can then consume another start and leave the first machine untracked. Mainbrella’s creation API accepts an Idempotency-Key so the client can recover the original reservation.
Keep the operation identity
Generate one key for each intended launch and retain the exact image selection. Retry the same POST body and key while reconciling an ambiguous response. The documented reservation window is 24 hours. Generating a new UUID on every retry defeats the recovery mechanism.
POST /containers
Authorization: Bearer mb_<your-key>
Content-Type: application/json
Idempotency-Key: <one-key-for-this-launch>
{"catalogId":"node"}With a key, the response includes a creation record. Wait for its status to become running, then match creation.containerId and creation.createdAt to a running entry in containers. The first machine in the account list might belong to a different task.
A slot can be reused
The container ID identifies an account slot. After a stop, that slot can hold a new instance. Keep the exact returned createdAt as the generation identifier and send both fields to execution, file transfer, SSH issuance, and deletion.
Consider a cleanup request delayed until after another agent replaces the machine. Deleting by slot alone can target the replacement. A generation-qualified request allows the server to reject that stale action. Construct query strings with URL utilities so timestamps and paths are encoded correctly.
Cleanup needs evidence
The public verification script retries creation up to three times using one key, and only proceeds after matching the creation record to a running generation. Its cleanup runs in finally and deletes only the generation it captured.
If creation remains ambiguous, the report retains the creation key and asks for manual reconciliation. It does not infer ownership from an account list or delete a machine to make the error disappear. A cleanup failure also keeps the known identity so the caller can recover.
Creation safety does not make commands repeatable
The launch key applies to creation. An HTTP execution response can also be lost after a command has completed, but executing that command again can repeat its side effects. Inspect resulting files or application state before retrying a write, deployment, or other mutation.
The container guide, execution guide, and agent skill carry these rules into integrations. They let the agent recover an operation without guessing which machine or effect belongs to it.