Sume balance is in dollars: the credits field is rounded cents

Short answer

Sume's wallet is a USD balance, not a pool of abstract credits. The usage docs state that the balance is in USD and that compatibility fields can show rounded cent values as credits. If a dashboard or client shows you a credits figure, treat it as dollars rounded to cents, and do not budget small per-second rates from it (Usage).

Why rounding matters on video

Video rates are fractions of a cent per second. At Sume's rate table, Gemini Omni Flash 1.1 at 360p is $0.0375 a second and Wan 3.0 at 480p is $0.0625 a second. Rounded to cents, those become $0.04 and $0.06, a difference of 6.7 and 4 percent. Over a batch of a thousand 5-second clips, either row is off by about $12.50.

Use micros

The usage summary reports amounts in USD micros, millionths of a dollar. Fields such as debited_usd_micros, held_usd_micros and refunded_usd_micros carry them, and debited_usd is given for convenience. The docs example puts one dollar at 1000000 micros. Divide by 1,000,000 to convert, and do it with integers or decimals rather than floats if you sum many rows. The docs also say never to sum the rows yourself when a summary is available.

def usd(micros: int) -> str:
    whole, frac = divmod(micros, 1_000_000)
    return f"${whole}.{frac:06d}"

print(usd(37_500))     # $0.037500
print(usd(1_250_000))  # $1.250000

Rules

• Read GET /v1/balance for the wallet and GET /v1/usage for rows; do not infer one from the other.
• Quote debited_usd from the usage summary, not a reserve.
• Check the balance against the sum of reserves for a batch before you submit.

A worked rounding error

A 10-second Omni 360p clip is $0.375. In cents that is 37.5, which cannot be shown exactly, so a rounded field shows 38 or 37 cents. Over 500 such clips the difference between $187.50 and $190.00 or $185.00 is $2.50 or more. For larger batches and finer rates the gap grows. Micros avoid the problem entirely: 375,000 micros times 500 is 187,500,000 exactly.

Use integer micros from the usage summary and convert to dollars only for display.

Where each figure lives

The wallet comes from GET /v1/balance, the history from GET /v1/usage, and per-job summaries from GET /v1/usage?job_id=. Those summary values include debited_usd for a ready-to-display dollar figure. Do not sum the rows yourself, since a refunded row keeps its hold amount in billable_amount_usd_micros and would be counted as spend.

A good habit is to keep your own accounting in micros end to end and convert at the edge. Store the integers you read, add and subtract them as integers, and format dollars only in the UI or the report. That way a total over thousands of jobs matches the ledger to the last digit, and a reconciliation that disagrees points at a real difference rather than at rounding.

If you need to tell a customer what a batch cost, quote the debited figure from the usage summary with the final flag set, since it is computed from captured rows and excludes holds.

One more place this bites is automated alerts. If you alert when a balance falls under a threshold, compare in micros, because a rounded figure can sit on the wrong side of the threshold by a cent. The same applies to per-job cost limits in a script: compute the expected micros from the rate and duration, and compare against the reserve you read back.