🌀 BV Remote LLM Provider

The name undersells it. BV Remote LLM Provider isn't just "the remote one" - it's the one-stop BV_LLM_PROVIDER factory for the BV Node Pack prompt-enhancer pipeline. Pick a provider profile, type a model ID, and you've got an LLM to feed the BV Regional Prompt Enhancer. It's remote by default, but the local profiles (Ollama, LM Studio, llama.cpp, vLLM, LocalAI) quietly turn it into an HTTP client for your own loopback server. The architecture is the same either way; only the endpoint and the auth change.

What it actually does

Every profile talks to an OpenAI-compatible Chat Completions endpoint with strict JSON-schema output and no tools, no web search. The provider catalog ships in the pack's data files (remote_llm_providers_v1.json) with the fixed endpoints for OpenAI, Venice, and Abacus.AI; the local profiles point at the standard loopback ports (11434 for Ollama, 1234 for LM Studio, 8080 for llama.cpp/LocalAI, 8000 for vLLM). HTTPS is enforced everywhere except loopback, which is a genuinely thoughtful default.

The two inputs you'll actually touch on every workflow:

• provider_profile - the 10-way dropdown. OpenAI Compatible is the generic default and the only one that lets you edit custom_endpoint; the named profiles lock their endpoints so you can't fat-finger a paid request somewhere weird.
• model - free text, so anything your endpoint exposes works, from gpt-5-mini to hf.co/Qwen/Qwen3-8B-GGUF:Q4_K_M on Ollama.

reasoning_effort (none/low/medium/high) and timeout_seconds are there too; for the recommended local Qwen setup, medium reasoning is what the pack's own tests used. Output is a single provider connection into the enhancer.

The API key handling is the actual selling point

Keys never live in the workflow JSON - this is the big one, because a workflow is something you share as a PNG and paste into Discord. The node has a Configure <Provider> API Key button that stores your key in user/default/bv_nodepack/remote_llm_secrets.json, and the node only ever reports whether a key is configured, never the key itself. There's also a user settings file (remote_llm_settings.json) for a default profile, so new provider nodes start with your preferred model instead of a fresh default.

Two behaviors worth understanding before you queue something:

• Responses are cached. Successful calls are cached under user/default/bv_nodepack/cache/remote_llm/v1, keyed on payload, provider, endpoint, and model - never the key. Edit an unrelated widget and re-run, and you don't get re-billed. Change the prompt or the model and it's a new (paid) call.
• Imported workflows send their secrets to their configured host. The README calls out reviewing custom_endpoint before queuing a shared workflow, because the generic profile will happily send the key it has to whatever host that field says.

The recommended starting points

The pack's tested model ladder is worth taking seriously because it's grounded in real regional-prompt runs, not a marketing table:

• Local default: hf.co/Qwen/Qwen3-8B-GGUF:Q4_K_M via Ollama - best local balance of strict JSON output and natural wording. Install with ollama run hf.co/Qwen/Qwen3-8B-GGUF:Q4_K_M.
• Low-resource fallback: qwen3:4b.
• Paid baseline: gpt-5-mini - strong without frontier pricing.

Installing

Same path as every BV node - search BV Node Pack in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/BlackVortexAI/bv_nodepack.git

Restart and hard-refresh (Ctrl + F5); the pack's frontend extension won't appear otherwise. There are no heavyweight Python dependencies - this node is stdlib HTTP plus JSON, which is refreshing in a category (API wrapper nodes) with a real security history in this ecosystem. The key being stored outside the workflow and outside the code is the right instinct, and the pack is transparent about exactly where everything lives.