VELVET VICE KREA — Ollama Release Barrier

Here's the problem this node exists to solve: the Velvet Vice Krea workflow can run an Ollama-hosted LLM (the Prompt Director's Qwen) and a 12B Krea 2 diffusion model on the same GPU. Both want VRAM, and they want it at different times. If the Qwen model is still sitting in memory when Krea's UNET tries to load, you get an OOM or a thrashy, slow render. "VELVET VICE KREA - Ollama Release Barrier" is the traffic light between the two: it confirms Ollama has actually dropped the LLM before the prompt is allowed to move into the Krea render gate.

What "release" means here

The node takes the prompt_package that the Prompt Director emits - a bundle containing the final prompt and metadata about whether Ollama was even used - plus two settings:

• strict_release - boolean, default on. If true and the release can't be confirmed, execution fails with a clear error. If you set it false, it logs a warning and proceeds anyway. That's the "I know what I'm doing, just try" mode.
• timeout_seconds - default 20, from 3 up to 120. How long it polls before giving up.

Its only output is prompt (STRING) - the same prompt that came in the package, passed through once the barrier clears.

Here's the part that keeps the whole thing sane: if the Prompt Director ran in MANUAL mode (no Ollama calls), the package marks release_required: false, and the barrier bypasses itself entirely - no unnecessary polling, no extra latency. It only does real work when an ASSISTED prompt actually loaded a model into Ollama.

The mechanism, in plain terms

When release is required, the node talks to Ollama's HTTP API directly (no pip packages involved - it uses Python's stdlib urllib). It checks /api/ps to see if the Qwen model is still resident, sends an unload request with keep_alive: 0, then polls /api/ps every quarter second until the model is gone or the timeout hits. If the model refuses to leave - which happens when another client is holding it - and strict_release is on, execution stops with a "could not confirm Ollama release before Krea rendering" error.

This is the "prompt-first" architecture in action: the diffusion model never even starts loading until the LLM is confirmed out of VRAM. It's the same handoff pattern the community converged on for running a local LLM and a diffusion model on one card - the KB's LLM-in-ComfyUI notes call out automatic unload/reload as the load-bearing trick of every good local-prompt node.

Where it sits and what it wires into

In the workflow, the Prompt Director's prompt_package output feeds this barrier, and the barrier's prompt output feeds the Prompt-First Gate, which then releases the Krea render inputs. If you're wiring this by hand (rather than loading the stock workflow), that's the chain: Director → Release Barrier → Prompt-First Gate.

Installing and troubleshooting

Same pack install as everything else here:

cd ComfyUI/custom_nodes
git clone https://github.com/Velvet-Vice/velvet-vice-krea

Restart ComfyUI, or search "VELVET VICE - KREA" in ComfyUI Manager. No pip dependencies.

The most common failure is "Cannot reach Ollama" - Ollama isn't running, or ollama_url points at a remote box that's unreachable. The default URL is http://127.0.0.1:11434, which assumes local Ollama. If you're using MANUAL prompts you'll never see these errors, which is itself the tell: a release error only happens after an ASSISTED prompt that actually invoked the LLM. And if a release genuinely times out with strict_release on, you have two honest choices - unload the model yourself in Ollama (ollama stop <model>) or flip strict_release off and accept the risk of a tight-VRAM render.