BytePlus Progress Test

Here's the situation this exists for. A Seedance job takes two to five minutes. The node sits there with a progress bar crawling across it, and you want to know whether that bar is correct - whether it tracks real time, whether it resets, whether it survives a batch of four videos. Waiting five minutes per test to find out is miserable. So the pack ships a node that emits progress events on a timer and nothing else.

It is not a generation node. It spends no money, calls no model (unless you ask it to), and produces no media. It's a test rig for the pack's own frontend, and the pack's docs generator skips it entirely - you won't find it in the normal node search, since its schema is marked dev-only. The one you'd use it to debug is web/js/byteplus_progress.js, which listens for ComfyUI's progress websocket event and paints a 183s / 300s-style bar on any node whose class starts with BytePlus.

What it does

Two modes, decided by test_model.

With test_model on None (the default) it simulates progress locally: it walks from 0 to duration_seconds in steps increments, firing the same progress event a real Seedance run fires, then finishes the node's progress state. Set duration_seconds to 300 and steps to 20 and you've reproduced the shape of a five-minute Seedance job in a few seconds - well, in 300 seconds of wall clock, but with no API cost. It returns the string BytePlus Progress Test Finished on the response output.

With test_model set to one of the Seedance models, it stops simulating and does something more interesting, and cheaper than you'd guess: it makes a free ModelArk call (content_generation.tasks.list) to pull your succeeded tasks of that model, filters them by test_resolution, and returns a JSON report - estimated_time, how the estimate was derived, how many history samples it found, and the top 20 samples with their task ID, requested duration and actual wall-clock time. That's the pack's own time-estimation path, exercised against your real account history. test_resolution (480p, 720p, 1080p, 4k) is what gets matched.

The node is an output node, so it runs when you press Run. There's exactly one output, response, a string.

Should you install the pack for this?

No, obviously - but if you're already running the pack, this is a useful little thing to keep around.

cd ComfyUI/custom_nodes
git clone https://github.com/byteplus-sa/ComfyUI-BytePlus-ModelArk
pip install -r ComfyUI-BytePlus-ModelArk/requirements.txt

Restart ComfyUI (0.31.0 or newer), or install from Manager by searching BytePlus ModelArk. For the None mode you don't even need an API key. For a test_model run the pack needs the ModelArk key saved in Settings → BytePlus (or BYTEPLUS_API_KEY in user/.env); with no key it quietly falls back to simulating.

Where people get burned

The first surprise is simply that the node isn't in the menu. Its schema is dev-only, and the pack's own documentation generator skips it by name - so if you went looking because you saw it in the node list of some wiki, that's why. Add it to a workflow you got from elsewhere, or enable dev nodes.

The second is subtler and specific to this node: test_model isn't free because it's harmless, it's free because listing tasks is cheaper than generating video. It still needs a working key and a region that matches it, and a 401 here tells you your key/region pair is wrong - same as every other node in the pack.

Third, and worth internalising while you're poking at progress: ComfyUI only re-runs a node whose inputs changed. A test that "repeats" identical settings is hitting the cache, which is exactly why the generation nodes use seed as a re-run trigger rather than as a reproducibility control.