x-fal-billable-units header: WebSocket billing vs Sume receipts

x-fal-billable-units is a header a fal WebSocket endpoint sets on its upgrade response to say how many units a session should be billed for. Sume has no equivalent header: you do not declare units, and cost is read back from the usage ledger per job or per run.

The fal side is from its changelog; the Sume side is from the API reference and core workflow, read 2026-10-01.

What does the fal changelog say about the header?

The entry is titled "Billing Headers for WebSocket Endpoints". Shared WebSocket endpoints can declare billing on their upgrade response. Set x-fal-billable-units when the unit count is known at connect time. Set x-fal-billable-units-webhook to 1 when the count is only known at the end of the session, then report the total with POST /requests/billable-units/{request_id}. Sessions without either header are still charged by duration.

Is there a billing header on Sume?

No header is documented. Sume jobs are submitted over HTTP, and the docs describe cost as ledger activity: provider-backed generation can reserve an estimated USD amount, capture the actual cost on success, and refund on failure or cancellation before capture.

How do I read what a Sume job cost?

GET /v1/usage returns ledger entries such as reservations, captures, refunds and top-ups. Each public row carries a job_id, and the endpoint can be scoped by thread_id, run_id or job_id; the scoped answer sums every ledger row that scope caused. For Format runs, the receipt's usage.debited_usd_micros is the same fold, so the receipt and the ledger agree.

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

What should I change when porting fal billing code?

Drop the unit-reporting step. Keep the job id from the create response, and reconcile spend by reading the ledger with that id. If you need a roll-up, see per-run usage or export usage to CSV.