Retried a request and got two videos: avoiding duplicate tasks and double spending

Retrying a video request can create duplicate tasks because each POST to /v1/video/generations submits a new job, but you are not exposed to double spending on genuine failures: 「Failed or errored requests are never billed」据 relaydance.com 官方文档. To avoid paying twice, poll the original task_id before retrying, treat network timeouts as pending rather than failed, and only resubmit when the first task returns a definitive failed status. Successful duplicates are billed per generated video.

Why retries can produce duplicate videos

Duplicate videos happen when a retry submits a second task that also succeeds, since RelayDance billing is pay-as-you-go per generated video. Submitting a video task uses POST /v1/video/generations with model, prompt, seconds, and metadata. A client-side timeout does not mean the server rejected the job; the first task may still be running or already succeeded. If you resubmit, you now have two accepted tasks. Both count toward usage if both reach the succeeded state. The safe pattern is to poll GET /v1/video/generations/{task_id} until status is succeeded or failed before deciding whether a retry is warranted. See live rates at relaydance.com/models.

What you are billed for on a failed request

You are billed nothing for a failed or errored request, so a true failure carries no cost even after retries. According to the official relaydance.com docs, 「Failed or errored requests are never billed」. This means the risk from retrying is not paying for the failed attempt; the risk is paying for two successful outputs. For reference, Seedance 2.0 720p costs about $0.190 per second and 1080p costs about $0.470 per second, so a duplicated 5-second 1080p clip would add about $2.35 in avoidable spend. Seedance Fast is about $0.152 per second, and native 4K is about $4.90 per 5-second clip. Distinguishing failed from pending states is what prevents double spending.

A safe retry procedure

Use a poll-first procedure so a retry never runs alongside a still-active task:

1. On timeout, do not resubmit immediately; keep the returned task_id.
2. Call GET /v1/video/generations/{task_id} to read the current status.
3. If status is succeeded, use the video url in the result and stop.
4. If status is still processing, continue polling; do not resubmit.
5. If status is failed, then submit a new task, knowing the failed attempt was not billed.

For long-running jobs, set metadata.callback_url so the final state is POSTed to your server, which removes the need to poll and reduces accidental retries. Clips run up to 15 seconds per request. Read the flow at relaydance.com/docs.

Cost of an accidental duplicate by model

The cost of a duplicate depends on the model and clip length, as shown below.

The retry itself is protected on failure, so these amounts apply only when both the original and the retry reach succeeded. Because the API is OpenAI-compatible, 「Set base_url to https://relaydance.com/v1 and keep your OpenAI SDK」据 relaydance.com 官方文档, and you can add idempotency logic in your own client wrapper.

FAQ

Does a retry ever charge me for the failed attempt? No. Failed or errored requests are never billed, so only successful outputs incur cost.

How do I check whether the first task already succeeded? Call GET /v1/video/generations/{task_id} and read the status; if it is succeeded, use the returned video url instead of resubmitting.

Can I avoid polling to reduce accidental retries? Yes. Set metadata.callback_url and the final state is POSTed to your server, so you do not need to poll manually.