Replace your Sora spend view: log usage.cost per video job

After Sora, the cheapest way to keep a spend view is to write it yourself. Sume's poll response for a completed video job includes usage.cost, which the video generation docs describe as the Sume billable amount, and Sume reserves list price times 1.25 on submit. Log the job id, model, duration, resolution and usage.cost for every job into one table, then group by feature and customer. Reconcile monthly against GET /v1/usage.

What to record per job

The poll response carries the job id, model and usage. Your own request carries the feature and customer. Together they answer the questions a Sora dashboard used to.

Estimate before you spend, record after

Two numbers matter. The reservation happens at submit: the docs say the workspace USD balance is reserved at provider list times 1.25 for every model. The captured amount is what usage.cost shows on completion. A failed job releases the reservation where applicable, per the errors guide, so log failures with zero cost rather than dropping the row; failure rate per model is a useful column.

Reconcile with the ledger

GET /v1/usage returns ledger entries such as reservations, captures and refunds, and GET /v1/balance returns the USD balance. A nightly job that sums your usage.cost column per day and compares it with captures in the ledger will catch missed callbacks, jobs you never polled, and retries that created a second job because the idempotency key changed.

Limits of this approach

Your table only sees jobs your code submitted. Jobs created from the dashboard or by an agent are in the ledger but not in your table. Treat the ledger as the total and your table as the explanation for the part you control. Unknown remains unknown: if the totals differ, report the gap rather than allocating it.

For pricing inputs, read pricing_skus from the model list, per the API reference catalog routes, and avoid copying numbers into code.