LLM Provider: OAI Compatible

LLM Provider: OAI Compatible is the pack's generic gateway: point it at a URL, and it figures out what kind of server is sitting there. It's the default provider for anything that speaks the OpenAI chat dialect over HTTP - LM Studio (the default http://localhost:1234), oobabooga Textgen, llama.cpp's server, even the real OpenAI API - and it auto-detects which one you're talking to by fingerprinting the endpoint. One node, most of the local-LLM world.

Why this exists in the first place: the pack's whole architecture is "talk to an external server, never run a model in the graph" (the pattern external-api-nodes.md describes as an HTTP client wearing a node costume). Your model lives in LM Studio or whatever you're running; this node is just how ComfyUI gets a handle on it. The local-vs-API decision from llm-in-comfyui.md applies here directly - you choose the backend by choosing the URL, and the node doesn't care whether that URL is a localhost port or api.openai.com.

The inputs that matter

• url - the server's base URL. It tolerates you pasting http://localhost:1234/v1 (it strips trailing /v1 segments so you don't end up with /v1/v1/models), and it reads the timeout from config.yaml per detected backend, falling back to oai_compat and then 120s.
• model - a dropdown populated live from the backend by the pack's frontend JS (a PromptServer endpoint, debounced ~600ms so creating several nodes fast doesn't spam a dead server). If the backend is offline, the list stays at "(refresh to load)".
• model_fallback - a plain STRING input that overrides the dropdown when connected. This is the escape hatch for when your backend is down but you want the workflow to keep validating, or you know the model name by heart.
• lifecycle - optional, takes an LLM_LIFECYCLE object from the two lifecycle nodes. Connect LLM Lifecycle: LM Studio here when the backend is LM Studio, or LLM Lifecycle: Textgen for the legacy VRAM path.

The output is a single provider socket of type LLM_PROVIDER, which wires straight into any generation node's provider input. One provider can feed many generation nodes.

Keys, done right

This is where the pack behaves better than a lot of LLM node packs, and it's worth a sentence given the security history of this category (the LLMVISION incident is the cautionary tale in llm-in-comfyui.md). There is no key widget on the node. API keys come from config.yaml or environment variables (LLM_BIKESHED_<PROVIDER>_API_KEY), resolved at request time and matched to the backend that detection found. Your workflow JSON never carries a credential.

The honest caveats

Detection is fingerprinting, so it's not magic: the label can still report "Ollama" when the URL shape matches Ollama's /api/version, but this pack removed native Ollama generation back in 0.3.0 - you can't actually generate through it. Use a dedicated Ollama pack, or an OpenAI-compatible gateway that exposes /v1/chat/completions. And if the node tells you your URL is Textgen, it logs a hint to prefer the dedicated Textgen provider - same behavior, better defaults, and integrated VRAM controls. For new Textgen workflows, that node is the better choice; this one shines when you're mixing backends or running LM Studio.

Install

Standard for the pack: ComfyUI Manager search "comfyui-llm-bikeshed", or clone into custom_nodes/, pip install -r requirements.txt, restart. Dependencies are only pyyaml and requests (already in ComfyUI core), no model downloads. Copy config.example.yaml to config.yaml and set your backend URLs and any keys there.