KIE • Task Board
Find out what happened to the job that vanished
- config
- tasks_json
- status_summary
You queue a KIE generation. ComfyUI errors out, or you cancel it, or the browser tab reloads mid-run. Was the job submitted? Did it finish? Did you just pay for something you never saw?
KIE • Task Board answers that. You give it task IDs - or nothing at all - and it asks KIE what happened to each one, then prints a status line. It never resubmits anything and never downloads media, so the worst case is a few API reads.
This is the recovery node in the pack, and on a paid model it's the difference between "I'll just run it again" and not paying twice for the same image.
How it gets its IDs
Leave task_ids empty and it pulls the last 20 task IDs from a local journal the pack keeps in ComfyUI's user config directory. That journal is written every time a KIE Next generation node submits a job - task ID, model name, state, and spend. It does not store your prompts and it does not store your API key.
Paste IDs in (comma- or newline-separated, up to 20) and it looks up exactly those instead. That's the useful mode when someone hands you a task ID from another machine, or you're hunting a job from a workflow you've since deleted.
Then for each ID it calls KIE's record info endpoint and reports the state, a progress percentage where the provider gives one, any failure message, the result URLs, and the credits consumed.
Inputs and outputs
- task_ids - multiline string, default empty. Empty means "use the local journal".
- config (optional) - a
KIE_CONFIGsocket, for overriding the connection. Most people never touch it.
Outputs:
- tasks_json - a structured record per task:
task_id,state,progress,result_urls,failure,credits_consumed. Feed it anywhere you like; it's plain JSON. - status_summary - the human-readable one-liner per task, shown on the node as well:
abc123: success - 2 result(s).
That shape is on purpose. A task that fails to look up doesn't take the board down with it - it comes back as state: lookup_error with the exception text in failure, and the other nineteen rows still render. One typo'd ID won't cost you the view.
Installing it
cd ComfyUI/custom_nodes
git clone https://github.com/felipederosilva/ComfyUI-KIE-Nodes-Next
cd ComfyUI-KIE-Nodes-Next
pip install -r requirements.txt
Restart. Find it under KIE Next / Utility / Tasks. You need a saved API key - set it once under Settings → KIE.ai Nodes Next → Connection, paste it in, and the pack validates it against KIE before saving. The key lives in ComfyUI's user config area, never in the workflow JSON, and the frontend only ever sees a masked fingerprint.
There's a faster version for the common case: the same settings page has a Tasks section showing the last five locally recorded IDs. And if you want the task's actual media instead of its status, that's KIE • Reuse Completed Image / Video / Audio, which retrieves a finished task by ID without resubmitting.
Where people get burned
"No local task IDs yet. Enter 1–20 KIE task IDs." The journal only knows about jobs submitted by this ComfyUI profile since the feature was installed. It is explicitly not KIE's account-wide history - other machines, the KIE web UI, and older runs aren't in it. Paste IDs manually for those.
A job shows submitted forever. The board is read-only; it reports whatever KIE reports at the moment you queue. It doesn't poll in the background. Queue again to refresh.
Credits look odd. Task-level spend comes from KIE when the provider reports it. Where it doesn't, the pack labels the number an estimate derived from a before/after balance difference, and doesn't add it to the confirmed total - concurrent jobs can skew that, so trust the node's own labelling.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| task_ids | STRING | — | |
| configopt | KIE_CONFIG | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| tasks_json | STRING | — |
| status_summary | STRING | — |