Why your Sume balance dropped for a job that is still queued

Short answer

A queued job is already paid for in the sense that matters for your balance: Sume reserves the estimated amount when it accepts the request, before the job reaches processing. If you submit six jobs on a plan that runs one at a time, the wallet holds the estimate for all six at once. The money is not spent yet. A completed job captures the reserve; a failed job, or a cancel before generation starts, releases it (Generation admission).

A worked example

The Free plan processes 1 job at a time with a queue of 5, so 6 jobs are accepted. Take six Wan 3.0 jobs of 10 seconds at 720p. At Sume's rate of $0.125 a second, each job is $1.25, and the six together hold $7.50 as soon as the last one is accepted. Only the first one is running. The other five sit in queued, each with a reserve held.

If your balance was $7.00, the sixth submit would have failed with 402 insufficient_credits rather than queueing, because Sume could not reserve its estimate.

How to see it

The usage ledger separates the stages. reserved means Sume reserved the estimated usage before provider execution, captured means the billable usage was captured after success, and refunded means the reserve was released after a failure or a cancel (Usage). Read the whole workspace, or one job:

curl "https://api.sume.com/v1/usage?job_id=job_123" \
  -H "Authorization: Bearer $SUME_API_KEY"

# summary.held_usd_micros   = holds still open (not spend yet)
# summary.debited_usd_micros = what the wallet deducted
# summary.final              = true when no hold is open

What to do about it

• Quote debited_usd, never the reserve, as the cost of a job.
• Cancel queued jobs you no longer need; they release their reserve. Once a job is processing, cancel returns 409 job_generation_already_started.
• Size a batch by balance as well as by queue capacity: jobs x estimate must fit in the wallet.
• Do not resubmit a job because it is slow; a second submit holds a second reserve unless it carries the same Idempotency-Key.

Reading the ledger during a batch

While the batch is in flight, the summary from the usage endpoint is the quickest check. held_usd_micros shows holds that are still open, including parked pending rows, and the docs are explicit that this is not spend yet. debited_usd_micros is the amount the wallet has deducted, captured rows of every operation type. final: true means no hold is open, which is the signal that a run's cost can be quoted.

If you only read the raw balance, you see reserve and spend added together and may conclude the job cost more than it did. The summary separates them.

Common mistakes

The usual error is to treat the balance drop as a charge and to submit the batch again after a timeout. Sume's guidance is the opposite: do not submit a paid request again only because your local worker timed out. Poll the job id with backoff instead. If you must retry a submit, reuse the same Idempotency-Key, so the replay returns the original job rather than creating a second hold.

A second mistake is sizing a batch by queue capacity alone. The Free plan accepts six jobs, but accepting is not the same as being able to pay for them. Check the wallet against the sum of reserves first.

If the drop looks larger than you expected, compare it with your own estimate for the request. Multiply the per-second rate for the model and resolution by the seconds you asked for. For a 10-second Wan 720p job that is $1.25, and a queued job should hold exactly that until it runs. A bigger hold usually means a longer duration, a higher resolution or a different default than you intended, and the fix is in the request, not the wallet.

When the job reaches a final state the picture settles: a success captures the amount, and a failure or a cancel before start refunds it. Nothing about a queued wait makes the job more expensive.