Retry AI generation jobs without submitting twice

Separate submission from observation

A local tool can stop while the remote job continues. Treat submitting work and observing its state as different operations. Keep a durable record of what was sent and which provider job belongs to it before deciding whether another submission is necessary.

In our production in October 2026, generation uses submit-and-poll state files, and an existing request is checked before another submission. claude for ads provides the Claude context. Anthropic’s MCP guide describes external tool access and its permissions guide describes execution controls. The retry ledger below is a recommended design for preserving job identity, separate from a local render queue.

Suppose a hypothetical garden scene request loses its network response. That event tells the operator what happened locally, but does not establish whether the provider accepted the job. Preserve the original request identity and check the documented recovery route. If the provider offers no way to resolve the uncertainty, record it for an operator decision. Do not label the request failed merely to make another submission appear routine.

Create an internal request ID and record the operation, model identifier, input hashes and output role. Keep the intended request immutable once submitted. If the prompt changes, create another request revision rather than silently reusing the old identity.

The ledger should distinguish prepared, submission uncertain, accepted, running, complete and failed states as appropriate to the chosen provider. These are local design states, not a claim that every API returns those names. A prepared record establishes intent. A returned provider ID establishes an accepted request that can be queried. Do not collapse those two kinds of evidence into a single “started” label.

Source: Turntake editorial checklist (proposed), October 2026.

1. Submitted
2. Returned

Persist the provider ID before polling

When submission returns a request identifier, save it durably with the input record. Poll that identifier rather than submitting the prompt again. Record non-secret status information and timestamps so another worker can continue observation after an interruption.

In our October 2026 production method, a killed local call is not treated as cancellation of the remote job. If the response is lost before the identifier is stored, mark submission uncertain and inspect the provider’s supported request history or idempotency mechanism. Do not invent a recovery endpoint. The correct next step depends on the service’s documentation and the evidence available for that particular request.

1. 01Persist intended requestFix inputs and internal ID
2. 02Submit onceSave provider request ID
3. 03Poll recorded requestDistinguish uncertainty and failure
4. 04Retrieve verified assetBind local hash to request

Distinguish network uncertainty from provider failure

A network timeout says the client did not receive an answer in time. A provider’s explicit failed status says something else. Record the category and available evidence before deciding whether another submission is justified.

If a completed job is reported but the download fails, retry retrieval rather than generation. If the provider reports a failed request, inspect whether it is terminal and what changes are required before another attempt. A revised input is a new production decision. Keep the failed request ID with its reason so the operator can distinguish a legitimate new attempt from an accidental duplicate of work that was already accepted.

Use idempotency only where it is supported

When the provider documents an idempotency key, persist the key with the intended request and follow its documented scope and lifetime. Do not assume a locally generated identifier makes a remote operation idempotent by itself.

For a hypothetical uncertain submission, a supported repeated key may help recover the accepted request. Without that support, the ledger should retain uncertainty rather than claim a duplicate cannot happen. This distinction is the core design question. Local state tracking makes evidence visible, while provider behavior determines whether repeating a submission is safe. Keep those two responsibilities separate in both code and operator notes.

Observed failureRecovery question

• Observed failurePolling response lostRecovery questionCan the same request be queried?
• Observed failureSubmission response lostRecovery questionCan accepted work be reconciled?
• Observed failureDownload failedRecovery questionCan retrieval be repeated?
• Observed failureProvider reports failureRecovery questionIs a new request justified?

Download and verify the completed asset

In our production in October 2026, returned outputs are retrieved promptly because access links can be temporary. Treat the URL as a retrieval location, not the permanent asset identity. Save the file under a local ID and verify the expected media type, duration and streams.

Record the downloaded content hash and its relationship to the provider request. A completed provider status is not proof that the local copy is usable. Connect ElevenLabs to Claude for ad voiceovers covers the voice setup and sample approval that may precede a batch. Keep pronunciation and creative review separate from job completion; a technically retrieved audio file can still say the wrong word.

Keep recovery authority narrow

Can Claude edit video ads? Render from an edit file covers Claude editing an existing cut. That local job should receive the accepted asset and remain separate from the external generation ledger. Can Claude run Meta ads? Our read-only boundary covers the read-only Meta boundary. Recovering a provider request does not authorize changes to an ad account or release the resulting creative.

Turntake’s model plans describes Turntake’s model plans. This is a studio state-management method, not a promise that a planned connection already handles every provider’s retry semantics.

For a proposed acceptance exercise, simulate losing a polling response after a provider ID is stored. The next worker should resume querying the same request. Then simulate losing the submission response before an ID is known. The record should remain uncertain and require the documented reconciliation path. These two fixtures test different failure boundaries. A design that turns both into “submit again” loses the identity discipline the ledger was meant to provide.

1. Run 1
2. Run 2

Keep retrieval attempts separate from submissions

A hypothetical job can complete remotely while the local download is interrupted. Record another retrieval attempt under the same provider request instead of creating another generation request. Verify the downloaded media before marking the local asset complete. If the output link has expired, use only the provider’s documented recovery route and retain the request record. This distinction preserves the evidence that generation already succeeded, even when the deliverable is not yet present in the studio’s asset library.

Who wrote this We made the ads first, for SmartSolar in Denmark, Sweden and Ireland. Then we built Turntake. Where Turntake comes from