FEBatchGenStringBCDocker

If you're generating prompts one at a time against a local LLM, a queue of ten prompts means ten sequential round-trips, each blocking your graph. FEBatchGenStringBCDocker fixes that by taking a batch of generation requests and running them in parallel threads, then handing you back the completed prompts as a list. You feed it one user_prompts input (of type BCD_GEN_CTX), you get a prompt output that's a list of strings.

The intended pairing is with FEGenStringBCDocker set to async_infer = YES. In that mode, the single node doesn't wait for the LLM - it immediately returns an empty string plus a generate_ctx holding all the request parameters (user prompt, temperature, top_p, and so on). Collect several of those contexts, bundle them into a list (the pack's FEDataPacker is made for exactly this), and hand the list to FEBatchGenStringBCDocker. The batch node spins up a thread per request, runs them concurrently, and shows a ComfyUI progress bar while it waits.

The inputs and outputs

• user_prompts - BCD_GEN_CTX, the list of request contexts from the single generator. The node reads each context's user_prompt (or its prompt_list) and replays the request against the BC docker API.
• prompt - STRING, and it's a list: one generated prompt per request, in order.

It does multi-turn too - if a context carries a prompt_list conversation from FEBCPrompt, the batch node uses that as the message history.

Now the honest part, because this is the node in the pack most likely to disappoint. "BC docker" is the author's own local LLM container - the code POSTs to the API in bc_docker_api (default http://127.0.0.1:8009/generate) using HuggingFace TGI's streaming format, with <C_Q>/<C_A> chat markers in the input. That is not a standard endpoint you already have running. Unless you run that exact inference container, this node has nothing to talk to, and the errors (connection refused, tracebacks) print to the ComfyUI console rather than the UI.

So the review splits cleanly: as infrastructure it's a decent idea - parallel batch prompt generation with a progress bar, exactly what you want when local-LLM prompt expansion is the bottleneck. As a drop-in tool, it's useless to anyone who doesn't have the author's BC setup, and you can't tell from the outside what "BC" is supposed to stand for. If you're on a more standard local-LLM path (an OpenAI-compatible server, say), the sibling FEGenStringGPT node is the one that actually works with what you already run. Batch-prompt generation is a great pattern worth copying into a node that talks to your own backend.