Zura · Record Draft and Source Shot

If you've only ever run local models, the economics of a hosted video API are easy to miss: every call is metered, the video jobs are the expensive ones, and there is no undo. The pack's Seedance route is built around that fact - a cheap draft first, then a separately billed 1080p final - and GenjRecordDraft ("Zura · Record Draft and Source Shot") is the node that writes the receipt.

What it does

Required inputs: draft_task_id (STRING, and note it's a forced input, so it must be wired rather than typed) and clip_details (GENJ_CLIP).

The Seedance reference node returns a task ID alongside its video, which is how you ask the provider for the final render later. This node takes that ID, pairs it with the reviewed shot ID from clip_details, and writes both to output/genj/drafts/<sha256(draft_task_id)>.json. It then pushes a UI message naming the draft task and the source shot, with the instruction to inspect the draft before authorising a final render, and returns the task ID as a STRING.

That JSON file is the whole point. It's the record that says this draft belongs to that approved shot, and without it the acceptance node in the next graph has nothing to check against.

Two details in the schema that matter:

• draft_task_id is forceInput. You can't paste a string into a widget - it has to come from the API node that produced it. That's deliberate: the node's job is to capture a real provider response, not a fact you typed from memory.
• clip_details carries review_shot_id. That means the record is bound to the specific reviewed shot, not just to "the project". Generate a new draft from a different shot and you get a different record.

It's an output node, so it always evaluates - which is what you want for a leaf that writes a file.

Where it sits in the graph

The pack ships two Seedance stages as separate graphs. In the draft stage: GenjLoadReviewedShot → the ByteDance reference node (which returns video and a task ID) → GenjRestoreSoundtrack for the draft take → GenjRecordDraft. The published graph's prompt is worth reading as an example of how you brief a hosted editor: keep the original RGB background, framing, camera movement, action timing and mouth movements, and follow the audio embedded in the video.

In the final stage: GenjApproveDraft → the draft-to-final node → GenjRestoreSoundtrack under a seedance_final take name. The two graphs are intentionally separate so that paying for the 1080p final is a decision you make after watching the draft, not a side effect of one long run.

No output folder for the render - this node only writes the record. Give it the details from the same reviewed shot the draft was generated from, or the acceptance node will reject its own receipt.

Install

ComfyUI Manager → search Zura Nodes → install → restart ComfyUI.

cd ComfyUI/custom_nodes
git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes
python -m pip install -r ComfyUI/custom_nodes/ComfyUI_zura_nodes/requirements.txt

Nothing heavyweight here - but the Seedance nodes it partners with are ComfyUI's official API (partner) nodes, which need a logged-in Comfy account and prepaid credits, and they run on the provider's queue, not your GPU. The pack is explicit that this route is optional and paid, and that its clip length and price are whatever the provider displays.

Gotchas

• Seedance did not return a draft task ID. - the API call didn't come back with an ID, usually because it failed or the node returned an empty string. Check the API node's own status before blaming this one.
• Recording the wrong shot. If you re-prepare the reviewed shot after making the draft (new mask, new audio), the recorded shot ID no longer matches the one you're about to accept against, and the final stage will refuse. Re-draft rather than working around it - the whole gate exists to stop you paying for a final on a shot that changed.
• Deleting output/genj/drafts/. It's a few kilobytes of JSON and it's the audit trail for a paid render. Clear genj/final and genj/studio_intermediate first.