Luma GET /credits in USD cents vs Sume GET /v1/balance

Luma's GET /credits returns one field, credit_balance, described as the available balance in USD cents, so 2500 means $25.00. Sume's GET /v1/balance returns a USD-denominated available balance, and GET /v1/usage lists the ledger entries behind it: reservations, captures, refunds and top-ups.

Luma's facts are from the Get Credits reference and FAQ; Sume's are from the API reference, all read or checked on 2026-10-02. Luma's FAQ page says the current API docs are the Luma Agents API, so the endpoints on the older Dream Machine reference pages may not match what you call today.

What does Luma return from /credits?

The call is GET /credits on the base URL https://api.lumalabs.ai/dream-machine/v1, authenticated with a bearer token. The success body is a credits object whose credit_balance is a float. Errors return an object with a detail string.

The unit is the thing to get right. Because it is cents, dividing by 100 gives dollars. The FAQ adds the billing rule that matters for reading the number: the account is pre-charged for a generation and the amount is fully refunded to the credit balance if the generation fails.

What does Sume return?

GET /v1/balance returns the available balance in USD. GET /v1/usage returns ledger entries. The video docs describe the billing model: the balance is reserved on submit at provider list times 1.25, and usage.cost on a job is the billable amount. When a submit would overdraw the balance, the API answers 402 insufficient_credits.

So a Sume pre-flight is the same shape as Luma's: read the number, compare it with the job's expected cost, submit. The difference is that you can also read the ledger to reconcile a reservation against its capture or refund.

curl https://api.sume.com/v1/balance \
  -H "Authorization: Bearer $SUME_API_KEY"

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

How do you guard a batch against running dry?

Read the balance once before queueing, and sum the expected cost of the batch. On Sume, reserve is per job at submit, so a large batch can pass the balance check and still hit 402 partway if several reservations land at once. Treat 402 as a stop signal, not a retry.

Do not resubmit a paid request because your client timed out. Use an Idempotency-Key so a replay returns the original job, and poll GET /v1/jobs/{id}/status as in Jobs and results.

Which unit mistake is most common?

Mixing cents and dollars. A Luma balance of 5000 is $50, not $5,000. A Sume balance is already dollars. If a dashboard shows both providers side by side, convert Luma's value once at the edge and store dollars everywhere else.

Also keep estimates honest: neither page here gives a universal per-clip price, so take costs from the model's own pricing data (pricing_skus on Sume's /v1/videos/models) and from the vendor's current page for Luma.

How often should you poll the balance?

Once before a batch and once after is enough for most pipelines. Polling in a tight loop adds requests without adding information, and on Sume it can bring you toward the rate limit, which answers 429 rate_limited with retry-after when present. Back off when you see it.

For an audit trail, prefer the ledger over repeated balance reads. Sume's GET /v1/usage gives reservations, captures, refunds and top-ups as separate entries, so the difference between two balances can be explained line by line instead of guessed.