API429 · Image Queue

Generating one closed-model image at a time in a UI is a novelty. Generating thirty product concepts overnight is a job. API429ImageQueue is the node that turns the first into the second: paste one prompt per line, hit Queue, and it works through them sequentially, saving each result before it asks for the next. Yes, this is the metered-API-node category people complain about - but these models have no downloadable weights, so a paid call is the only door, and at volume you want a loop rather than thirty clicks.

The inputs

prompts is the field that defines the node: a multiline box, one prompt per non-empty line, blank lines skipped. There's no singular prompt field here - that's the generate node's.

max_images (INT, 1–100, default 2) is a count cap, not a spend cap. A 30-line list at 2048x2048 is thirty charges, and nothing in that number protects your balance. The only real brake in the pack is allow_paid_generation.

run_id here is a batch ID (default batch-001), and it's capped in practice: the node appends a numeric suffix to each prompt's request, so anything over 70 characters is rejected.

model, size and quality apply to the whole batch. Note quality is a required field here where it's optional on the generate node - same options (default/low/medium/high), different widget.

Output is an IMAGE list, not a single image. Wire it to Save Image and you get one PNG per prompt; nothing reaches downstream until the entire queue finishes. On a long batch that looks like a freeze. It isn't - but read the console before you kill it.

How it works, and why the IDs are deterministic

The node validates first: no non-empty lines, more lines than max_images, or max_images outside 1–100, and it raises and sends no requests at all. A typo in your settings costs you nothing.

Then it loops. Prompt 1 gets request ID batch-001-001, prompt 2 gets batch-001-002, and so on - one POST at a time, each response written into the state store in ~/.api429-comfyui before the next request goes out. That ordering is the point: the queue's whole recovery story rests on it. If prompt 7 fails, re-queue the same batch ID with the same list and prompts 1–6 replay from the local store without new charges while the run continues where it stopped.

Which leads to the trap nobody reads about until it costs them: the index is the identity. Prompt 7 always maps to batch-001-007. Append lines and everything already generated replays free. Insert a line at the top, or reorder the list, and every prompt below shifts to a different ID - which either errors on a digest mismatch or, on IDs you've never used, submits as a fresh paid request. Treat the finished part of the list as frozen and append only.

Install

ComfyUI Manager → search "api429", or:

cd ComfyUI/custom_nodes
git clone https://github.com/veresk06/comfyui-api429
cd comfyui-api429 && pip install -r requirements.txt

Two dependencies, numpy and Pillow; torch comes from ComfyUI. No model weights. Then the key on the server process, and a restart:

export API429_API_KEY="your-key-here"
python main.py

Windows portable users: set it in the launcher environment before ComfyUI starts and pip-install with the bundled Python. Keep the key out of the workflow file - the pack reads it from the environment so a shared graph can't leak it.

example_workflows/image-queue.json is the working starting point: queue → Save Image, paid generation off.

Where people get burned

• "Prompt count must be between 1 and max_images (maximum 100). No requests sent." More lines than the cap, or a cap of 0. Trim the list or raise max_images - knowing that raising it also raises what you'll spend.
• Run ID too long. The -001 suffix eats into the 70-character limit, and each per-item ID still has to pass the letters/digits/hyphens/underscores rule.
• Sequential means slow. Each request waits for the previous, plus up to five minutes of polling per deferred job. A batch of 20 is a lunch break, not a coffee break.
• A failed prompt stops the loop at that index - the exception propagates and the batch ends there. Your completed images are already saved, and re-queueing the same list and ID resumes rather than re-bills.
• A crash or an orphaned .lock. Reconcile that run before deleting anything; the state folder is your receipts, not a cache.
• Expecting a partial batch downstream. Nothing reaches Save Image until the last prompt lands.

One caveat that applies to the whole pack: the README says queue behavior was tested locally without paid calls, and the Reddit corpus through September 2026 has zero threads about API429 - no community track record to check your experience against. Your first real batch is the test.