Every error says whether to retry it, and its status means what HTTP says

Each error now has retryable, true or false; a retryable one always carries a Retry-After header, and no other does. Each code has one status, listed with every code in Responses and errors and in the OpenAPI document's x-error-codes. Codes are unchanged, so code that reads code keeps working; a check on the status may need a look: - 409 is now only a state you change first, or one that clears by itself (snapshot_not_ready, image_not_ready, volume_releasing, ... are retryable). - Your own limits that clear by themselves are 429, always with Retry-After: quota_exceeded on what runs at once (details.limit such as sandbox.count or sandbox.memory_mib), the no_credit_* limits on what runs, process_limit, transfer_limit, guest_busy, build_in_progress and the daily caps. - A count that falls only when you delete something is 409, with retryable: false and no Retry-After, so no retry library retries it: no_credit_kept_limit, limit_reached (keys, invitations, compartments) and quota_exceeded on what is kept (volumes, snapshots, images, secrets, sandbox.kept). Delete one, or raise the limit. - A full region or host is 503 with Retry-After: no_capacity, host_capacity, own_share_full. - A product switched off on a deployment is 501, not 503, so no client retries it. - A fault of ours that a retry does not fix is 500 (operation_failed, price_unavailable, and watch_failed: Runtime's own file watcher in a sandbox); a service behind the API is 502 or 504. - A request that cannot be done as asked is 422: disk_too_small, idempotency_conflict, no_credit_size_limit, a program in your sandbox that failed (interpreter_failed, tunnel_unavailable).