Grok Video Retrieve Task (Ace Data Cloud)

Generating a Grok video costs credits. Looking at one you already paid for costs nothing. That asymmetry is the entire reason this node exists, and it's also why it's the node I'd leave sitting in a saved workflow: submissions are the expensive, irreversible half of this pack, and this one is the safe half.

It POSTs {"action": "retrieve", "id": "<your task id>"} to /grok/tasks on the Ace Data Cloud API. The client classifies that as a read-only request, which has two consequences worth knowing. It's safe to spam. And it gets retried - three attempts with short backoff, where a paid write gets exactly one attempt.

The three inputs

• task_id - the string from a generation node's task_id output, or from your request history on the platform. Leave it empty and the node refuses to guess: A task ID or supported trace ID is required.
• wait_seconds - an INT from 0 to 240, default 0. This is the interesting one.
• parameters_json - {} unless you're doing something exotic.

wait_seconds: 0 means ask once and return. The node hands you back status: pending and exits, and you re-queue when you feel like checking. Set it to 120 or 240 and the node polls inside the run: submit the retrieve, look at the status, and if it's still pending sleep a few seconds and ask again, up to the deadline. The sleep is capped at 5 seconds, so a 240-second wait is roughly fifty round trips. It also bails early the moment the task comes back finished - or when the response carries a finished_at: null, which the client reads as "not done yet" regardless of what any status string says.

The catch: the deadline blocks the ComfyUI queue. A 240-second wait is 240 seconds of a stalled workflow, which is fine if you're standing there and miserable if you're not. My habit is 0 for the first pass, and a long wait only when the graph can't usefully continue without the clip.

What comes out

Six STRING outputs, same shape on every tool node in the pack:

• status - pending, succeeded, or partial. You will not see failed here; a genuinely failed task makes the node raise Task failed. Use its task or trace ID to inspect the service request. That's deliberate - the pack never prints raw service payloads or credentials - but it means your debugging lives in the platform's request history, not in the ComfyUI console.
• task_id - echoes what you asked for.
• media_urls_json - every URL the client could find in the response, collected by walking the JSON for media-shaped fields (video_url, image_url, url, and friends). Empty while pending.
• first_media_url - the one you wire into the loader. This is the handoff.
• result_json - the normalized payload, with the client's own redaction applied: request bodies, supplier and upstream routing fields, and anything credential-shaped are stripped before you ever see them. Pleasant when you're pasting output into an issue.
• trace_id - from the response header or body. Keep it; it's what support asks for.

Because this is an output node, the useful bits are also drawn as status text on the node itself: the status line, the task ID, and how many media URLs came back. For the full payload, wire result_json into a Show Text node.

Typical wiring:

AceGrokGrokGenerateVideo ── task_id ──► AceGrokGrokTaskRetrieve ── first_media_url ──► AceGrokLoadVideo

Note the thing missing from that diagram: a way to hand the task ID around the node automatically. A retrieve node polls a task ID you give it, so in practice you paste the ID and re-run. The pack's bundled example workflow is exactly this shape - a retrieve node with a PASTE_YOUR_TASK_ID_HERE placeholder feeding a preview.

Install

Manager → search Grok → publisher acedatacloud, package "Grok by Ace Data Cloud" (registry ID grok), then restart. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/AceDataCloud/GrokComfyUI
cd GrokComfyUI && python -m pip install -r requirements.txt
export ACEDATACLOUD_API_KEY=your_key_here   # then restart the ComfyUI process

requests and jsonschema are the only dependencies. No models, no GPU. The bundled example at examples/01-configure-and-run.json is a read-only template you can open with File → Open; it does not submit anything paid.

Where people get burned

Querying while the task is pending then wiring the loader anyway. first_media_url is an empty string, and the loader's failure message tells you exactly what happened: Task is pending; retrieve the same task ID again. Retrieve again, don't resubmit.

Reading a pending as a failure. Long video jobs just take a while. Query the same ID until it says succeeded.

Assuming the key is optional. Task lookups are read-only but not anonymous: no key in the process environment means Set ACEDATACLOUD_API_KEY in the ComfyUI process environment and restart., and an invalid key means an HTTP 401. Both happen at run time, and both need a ComfyUI process restart after you fix the environment - not a browser refresh.

Credentials leaking into a screenshot. The pack doesn't put your key in the graph, but result_json and your own parameters_json are visible on canvas. Blur before you post.