boogu / editTurbo / editImage

Boogu was the surprise drop of mid-2026: a roughly 10B open-weights image model nobody saw coming, with genuinely fast turbo variants and unusually good text rendering inside images. This node is its editTurbo variant, and it runs on Civitai's cloud, not your machine. You wire in a picture, type "change her dress to blue," and a few seconds later an IMAGE tensor comes back - no checkpoint download, no GGUF, no VRAM spent.

If you're already running ComfyUI locally and have the VRAM for Boogu's GGUFs, you probably don't need this node. This one is for when you want the edit model right now without juggling a multi-gigabyte download, or when your own card can't fit it. The trade, same as every Civitai Orchestration node, is that the job runs on Civitai's fleet and costs Buzz per generation.

How it works

This is one of the ~160 generated nodes in the civitai-comfy-nodes pack. Under the hood it's not doing any local diffusion - it builds a workflow payload, submits it to the Civitai Orchestration API, long-polls until the job succeeds, then downloads the result and hands it back to your graph as a normal IMAGE tensor. The "comfy" in the node's name means Boogu runs through Civitai's Comfy engine on their servers, not that anything Comfy-related happens locally.

editTurbo is the fast distilled variant of Boogu's edit model: 4 steps at CFG 1.0 by default. That's the whole appeal - instruction edits in a handful of steps, which is why this variant exists as its own node instead of a checkbox.

The inputs that matter

Only prompt is required. The rest are worth knowing:

• prompt - your edit instruction, in plain language. Boogu's edit models are strong on text rendering, so quoted strings inside the image work well.
• images - the image you're editing. Wire any IMAGE (Load Image, a prior gen node, whatever).
• steps / cfg_scale - defaults 4 and 1.0. This is a turbo model; leave them near the default. Crank CFG and you'll fight the distillation rather than help it.
• diffusion_model and loras - typed sockets (CIVITAI_AIR / CIVITAI_LORAS). Fill them by wiring a Civitai Model Selector / LoRA Selector from the pack's Loaders menu. Leave them unwired and the node just uses the boogu editTurbo model baked into it.
• sampler / scheduler / seed / width / height / quantity - familiar sampler knobs plus how many variants to generate (max 4).

Outputs

images (an IMAGE batch) is the thing you actually use - wire it into Preview Image or Save Image like any generator output. errors, workflow_id, and raw_json are diagnostics: raw_json is the full workflow result, handy when you want to see what the orchestrator actually did or how much it cost.

Installing and authenticating

The whole pack installs together - these nodes ship in civitai-comfy-nodes, not separately:

cd ComfyUI/custom_nodes
git clone https://github.com/civitai/civitai-comfy-nodes.git
pip install -r civitai-comfy-nodes/requirements.txt

or, easier, ComfyUI Manager → Custom Nodes Manager → search "Civitai Comfy Nodes" → Install, then restart. The only real dependency is requests plus python-socketio[client].

You'll need a Civitai account with Buzz and a way to authenticate. The pack resolves credentials in order: a wired Civitai Auth node, the CIVITAI_API_TOKEN environment variable, a stored key/OAuth in ~/.civitai/, or an interactive browser login. For a headless box, set the env var:

export CIVITAI_API_TOKEN=your_token

Where people get burned

• It's billed per job. A 4-step edit is cheap in Buzz, but this is metered cloud inference, not your electricity. Check the cost line the node displays after running.
• Your image leaves the machine. That's the mechanism, not a bug - the reference image and prompt go to Civitai's servers. Don't feed it anything you wouldn't upload to civitai.com.
• Keep the turbo settings turbo. At 4 steps this is tuned to be fast; if you push steps to 30 looking for quality, you're paying for a slower version of the wrong model. Use the non-turbo boogu edit node if you want the full-fidelity path.
• Don't forget the node needs some image input to edit - with only a prompt it behaves like a text-to-image call, which isn't what the edit model is optimized for.