Runware bills only successful requests: how Sume handles failures

Runware's pricing FAQ says you are only charged for successful API requests that generate outputs, and that a rate-limited request does not count. Sume takes a different route to a similar result: it reserves the estimated cost when a job is accepted, captures it on success, and releases or refunds it on a failed job or a failed queue admission. The difference shows up in what your balance looks like while a job is running.

What does Runware's page promise?

The FAQ answers three billing questions that matter for a retry loop. Does usage count if you are rate-limited? No: you are only charged for successful API requests that generate outputs. Are the listed rates final? The page says rates are published example prices per generation at the named configuration, assume default settings unless a row says otherwise, and that exact cost depends on your parameters, with the Playground used to estimate a specific request. Is there a trial? New users who sign up with a business email receive $2 in free credits.

The page also says its rate sheet lists models with published pricing tiers, currently 300+ of them, across image, video, audio, text and 3D, and that this is not every model in its registry.

What does Sume do with a failed job?

On Sume the money moves in steps. When a paid job is accepted, the estimate is reserved from the workspace USD balance. Successful completion captures the reserved usage. Failed jobs and failed queue admission release or refund the reservation where applicable, and cancel succeeds only before generation starts; after that the API returns 409 job_generation_already_started.

Video is reserved at provider list times 1.25 for every catalog model, and usage.cost on the poll response is the Sume billable amount. Because the hold is taken at submit, a request that cannot be covered fails immediately with 402 insufficient_credits before provider work starts.

What differs for a retry loop?

Both designs end with no charge for a failed generation, but the retry advice differs. Sume tells clients to send an Idempotency-Key on every paid submit that may be retried and not to resubmit just because a local worker timed out, since the original job may still be running. A replay with the same key and the same payload returns the original job; reusing a key for a different payload returns 409 idempotency_conflict.

Rate limits are a separate matter. Sume returns 429 rate_limited for request volume and 429 queue_full when concurrency plus queue capacity is exhausted, and in both cases the docs say to back off and retry with the same key, using retry-after when present.

What should you check before relying on either?

Read the terms on the live page for edge cases the FAQ does not spell out, such as an output that succeeds but is filtered or unwanted. For Sume, poll the job and read usage.cost once it is terminal rather than assuming the reserved amount was the final charge.