x-fal-billable-units header: WebSocket billing vs Sume receipts
fal bills WebSocket sessions via x-fal-billable-units headers. Sume has no such header: cost is a per-job ledger row you read back by job or run.
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.
| Question | fal WebSocket endpoint | Sume |
|---|---|---|
| Who states the unit count? | The endpoint, via header or end-of-session report | Not a caller input; the ledger records reserve, capture, refund |
| Where do I read the cost? | Per the changelog, reported to /requests/billable-units/{request_id} | GET /v1/usage and GET /v1/balance |
| What if the work fails? | Not stated in the entry | 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.
Sources
Related posts
More in Developers
- Fix lens distortion in video by API with lenscorrection
Sume's video filter allowlists ffmpeg's lenscorrection, so barrel distortion from a wide action-cam clip can be corrected by coefficients you choose and test.
- FLUX.2 JSON prompt: on Sume it is text in the prompt field
BFL says FLUX.2 accepts JSON-structured prompts. On Sume, prompt is a plain string, so JSON goes in as text; other fields are typed.
- FLUX.2 LoRA API: finetune_id on BFL, not on Sume
BFL serves klein LoRAs through -finetuned endpoints with finetune_id. Sume rejects provider-specific parameters, so use reference images instead.
- FLUX Request Moderated vs Content Moderated, and Sume's reason
BFL separates input moderation from output moderation and adds a Moderation Reasons array. Sume groups refusals under content_policy_rejected.
Written by Sume