Does a Sume 402 insufficient_credits cost you? No, nothing ran

Short answer

No. A 402 insufficient_credits response on a generation submit means Sume could not reserve the estimated cost from the workspace balance. The admission docs say the submit fails before provider work starts, so no job runs and nothing is captured (Generation admission). The error table calls it a balance that is not sufficient for the requested generation (Errors).

What to change

The remedy in the docs is to add funds, or submit a less expensive request. The cost of a request is mostly resolution times length times model. Here is a 10-second Wan 3.0 job at each resolution, using Sume's rates.

Retrying without double-billing

Use the same Idempotency-Key for an exact retry. The docs say a key reused for a different operation or payload returns 409 idempotency_conflict, so a smaller request needs a new key. After a 402 nothing was created, so a fresh key for the cheaper request is correct.

A 402 on submit is different from a job that fails later with the error category quota. The category table says to add funds or decrease the request cost. A job that fails after it started releases or refunds its reserve, as the ledger shows with a refunded row.

Before you retry

• Read GET /v1/balance and compare it with the estimate you expect.
• Drop resolution first; at Wan's rates 1080p to 720p halves the price.
• Shorten the clip; the price is linear in seconds.
• Remember queued jobs also hold a reserve; cancel queued jobs you no longer need to free balance.

A worked example

You hold $2.00 and submit a 10-second Wan 3.0 job at 1080p. The reserve needed is $2.50, so the submit fails with 402 and nothing is held. Re-submit it at 720p, which needs $1.25, with a new idempotency key; it is accepted, and $1.25 is held. When it completes, $1.25 is captured and $0.75 of your balance remains. A second 720p job of the same size then fails with 402 unless you top up, because only $0.75 is spendable.

The check applies to every accepted job, including queued ones, so queued reserves count against the same balance.

Common mistakes

Retrying the same payload with the same key after a 402 will fail again until the balance changes. Adding funds happens in the dashboard; the public API reads balance and usage but has no endpoint to create a top-up. Another mistake is treating the 402 as a transient fault: it is a state of the wallet, so back off by fixing the cause, not by waiting.

The practical advice is to check the balance before large batches. Read the balance, sum the reserves you expect for the accepted capacity, and top up if the sum exceeds it. That avoids a mid-batch run of 402 errors, which are harmless but waste time and can leave a half-submitted campaign.

If a 402 appears for a job that should have fit, read the usage summary: held amounts from queued jobs may be using the balance you thought was free.

Finally, log the 402 body. It tells you the request was understood and priced, which separates it from a validation error (400) or a capacity error (429). Three different failures, three different fixes: correct the request, wait for capacity, or add funds. Treating them as one generic retry loop is how a script ends up hammering an endpoint without ever succeeding.