p-image

The name is honest: this is a node that calls an API. PrunaTextToImage (shown as p-image) sends your prompt to Pruna AI's hosted servers, waits, and downloads the result back into your graph as a normal IMAGE. No checkpoint to download, no VAE to get wrong, no VRAM budget to respect - the only thing you need is a Pruna API key and a few cents per image.

Pruna is the model-compression company behind it, the kind that makes FLUX run 2.6x faster on weaker hardware. Their whole pitch is speed, and p-image is the fast closed-source model they now sell as a service. The community's take on it is muted but real: people who tried it called it genuinely quick and "very solid" for prototyping, and several commenters noticed outputs suspiciously close to Tongyi's Z-Image under the hood. It is not going to dethrone your local FLUX on detail - think of it as a clean, reliable image from a model you never have to run.

What you actually set

Only four inputs, and two of them barely count:

• prompt - multiline string. Plain descriptive English works; this is not a tags-only model. Worth knowing: people report it starts writing nonsense into the image if you feed it structured or JSON-style prompting.
• aspect_ratio - a dropdown: 1:1, 16:9, 9:16, 4:3, 3:4, 3:2, 2:3. Default 1:1.
• model - one choice, p-image. It's a dropdown so the API can grow new models without you reinstalling.
• api_key - your Pruna key. Leave it blank and the node falls back to the PRUNA_API_KEY environment variable, which is the better habit anyway.

Output is a single image socket, type IMAGE, so it plugs straight into any Preview or Save node. That's it - one node replaces your whole load-checkpoint / CLIP-encode / sample / decode stack.

How it works

Under the hood the node builds a tiny JSON payload (prompt + aspect_ratio), POSTs it to https://api.pruna.ai/v1/predictions with your key in the header, and asks for a synchronous result. If the model isn't done yet it polls the job's status every three seconds, up to a five-minute cap, then downloads the finished image and converts it to a ComfyUI tensor. All that waiting is why a cold generation can feel slow even though the model itself is fast - you're paying for round-trips, not local compute.

Install

ComfyUI Manager → search ComfyUI Pruna API → Install → restart. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/PrunaAI/comfyui-pruna-api
pip install -r comfyui-pruna-api/requirements.txt

The requirements are just requests and Pillow - there are no weights to download and nothing heavy, which is the one unambiguous win of an API wrapper. Get a key from the Pruna developer portal, then either paste it into the node or export PRUNA_API_KEY before launching ComfyUI (if you set both, the node field wins).

Where people get burned

• It's paid per image. Cheap per run, but "cheap" × twenty batched variations is real money. Set a budget in your head before you queue a big grid.
• No key, no run. The node raises "No Pruna API key provided" if both the field and env var are empty, and a 401/403 from the API means the key itself is wrong. Both are the first thing to check when nothing comes back.
• Five-minute timeout. Slow jobs die with "Pruna job did not complete within 300s." On their end, not yours - check the job status in the Pruna portal.
• No offline fallback. If Pruna's servers are down, so is this node. It's a complement to your local stack, not a replacement for it.

The verdict: if you're on a machine that can't run a modern model at all, or you want a second opinion from a different model family without installing anything, this is the node. Otherwise it's a neat toy with a credit card attached.