Groq Chat

Groq's whole thing is speed. Their LPU hardware runs Llama 3.3 70B at roughly 280 tokens per second and the smaller 8B model at over twice that - so an in-workflow LLM stops feeling like a waiting room and starts feeling like part of the graph. If you're generating prompts per-image in a batch or rewriting a caption on every run, Groq Chat is the node that makes that loop tolerable. The OpenRouter Chat node in the same pack is the generalist; this one is the specialist for "I want it fast, from a single provider, for free-ish."

The other real difference: Groq's model list is fetched live from their API (cached for five minutes, same Refresh-to-update dance as its sibling), and it's categorized into Featured, Production, and Preview tiers. That matters because Groq ships preview models that can vanish on short notice - the node's own docs tell you to treat anything not labeled Production as evaluation-only. Don't build a workflow you depend on around a preview.

How it works

Same architecture as OpenRouter Chat, different phone number: it POSTs to Groq's OpenAI-compatible endpoint at https://api.groq.com/openai/v1/chat/completions. Messages are assembled in the standard OpenAI format, vision images get base64-encoded into the user message, and the response comes back as plain text or JSON. There's an automatic retry loop with exponential backoff for rate limits and transient 5xx errors (max_retries, 0–5), plus a debug_mode that surfaces the actual request error instead of a shrug.

One genuine Groq quirk: vision models in this node (Llama-4 Scout and Maverick) reject system prompts. The README and the tooltips both say it, and it bites everyone once - if your request 400s on a vision run, flip send_system to "no" and it'll go through.

The inputs that matter

• api_key - from console.groq.com/keys. Required, and - same warning as its sibling - plain-text visible in the workflow. Clean it out of anything you share.
• model - dropdown fetched live from Groq, defaulting to llama-3.3-70b-versatile. "Manual Input" + manual_model for custom ids.
• user_prompt - required; for vision, this is the question about your image.
• send_system - yes/no toggle. Set to "no" for vision models (see above).
• max_completion_tokens - caps response length; Groq models differ wildly here, check the model card rather than trusting the 131,072 ceiling.
• response_format - text or json_object.
• temperature - 0.7 default; 0.0–0.3 for deterministic, 0.7–2.0 for variety.

Outputs are response (the generated text/JSON), status (model used, seed, token counts - this is how you watch cost on the free tier), and help (static usage text).

Installing it

It ships in the same pack as OpenRouter Chat, so it's the same one-time install. ComfyUI Manager: search ComfyUI-EACloudNodes. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/EnragedAntelope/ComfyUI-EACloudNodes
cd ComfyUI-EACloudNodes
pip install -r requirements.txt

Restart, and both chat nodes plus OpenRouter Models appear. The dependencies (Pillow, requests, torch, torchvision) are things every ComfyUI install already has, and there are no model files to fetch. It works in cloud-hosted ComfyUI too, which is the pack's stated design goal - the node only needs outbound HTTPS and a key.

Common issues

• Vision 400 errors - almost always the system prompt. send_system to "no".
• "Model not found" on the dropdown - a preview model got pulled. Switch to a Production-tier model.
• Rate limits on the free tier - Groq throttles hard. max_retries will retry recoverable ones; for the rest, wait or pick a faster (smaller) model.
• Key hygiene - as with any of these cloud nodes, the key lives in the workflow. It's a third-party pack running unsandboxed Python; check the source before you trust it with a key, the way you should with every custom node.