#14771·langflow

Proposal: AnyLLM component — one OpenAI-compatible bundle for 24+ Chinese & international models, with dynamic model discovery

Author: JetragonRiderCreated Aug 26, 2026Updated Sep 11, 2026
Labelsenhancement

Hi langflow team I've been building flows with langflow since the Python-based component system landed, and the Model Providers pane + bundle ecosystem is honestly the cleanest "bring your own LLM" story in the visual-flow space. One thing I keep running into, though (and Issue #6505 shows I'm not alone): reaching models across providers is more fragmented than it needs to be. To use DeepSeek and GPT-5 and Gemini in the same flow today, you need to: Register three separate provider keys in the Model Providers pane (only one key per provider) Use different components for each (OpenAI component, DeepSeek bundle, Gemini component) — each with its own parameter surface Know in advance that the "OpenAI Compatible" provider exists at all — #6505 got 5+ from users asking for exactly this capability before discovering it was already there I'd like to propose an AnyLLM bundle that collapses this into one component. AnyLLM is a unified OpenAI-compatible API gateway — one API key, one Base URL, 24+ leading models from both sides of the firewall: Chinese: DeepSeek V4 Flash/Pro, Qwen3.7-Plus, GLM-5.2/5.1 (up to 2M context), Kimi K2.5/K2.6, MiniMax M3/M2.7, Xiaomi MiMo v2.5 Pro/v2 Pro International: GPT-5.6 Luna, GPT-5.4 Mini/Nano, Gemini 3.5 Flash (multimodal) Pass-through pricing, no markup; international cards and crypto accepted — so langflow users outside China can finally reach DeepSeek / Qwen / GLM / Kimi without a Chinese phone number or Alipay, and don't need separate OpenAI or Google accounts either. What I'd contribute: A bundle following the existing DeepSeek bundle pattern (api_base + api_key params, defaults pointing at the gateway), with: model_name as a combobox populated dynamically from GET /v1/models — the Ollama component already proved this pattern works great in langflow, and it means the model list stays in sync as the gateway adds models, zero maintenance for you LanguageModel output type (like the DeepSeek bundle) so it drops straight into Agent / Smart Transform components as the LLM driver JSON mode, streaming, and max_tokens / temperature / model_kwargs params matching the existing component conventions A docs PR for the "My preferred provider or model isn't listed" section of the Language Model docs — showing the zero-code path too: point the OpenAI component's Base URL (or the OpenAI Compatible provider) at AnyLLM and type any model ID, for users who prefer built-in components over bundles Before opening a PR, a few questions: Bundle vs. Model Providers preset — is a bundle component the right form factor, or would you rather see AnyLLM listed as a preset in the Model Providers pane (one click → base URL + key fields pre-filled)? Happy to do either; the bundle gives us the dynamic model picker, the preset is lower-friction for existing users. Dynamic model discovery — the Ollama component fetches its model list automatically; is a GET /v1/models call at component-load time for a remote gateway acceptable (caching behavior, error handling when the endpoint is unreachable), or is there a convention I should follow? Bundle hosting — should this live in the main langflow repo's bundle collection, or as a separate community bundle repo that users install? I see both patterns in the wild and will follow your preference. Happy to follow CONTRIBUTING.md, match the Python component conventions (LanguageModelComponent), pass lint/build, maintain it long-term, and provide free API credits for any maintainer who wants to test the integration. More about AnyLLM: [URL] Thanks for building langflow — the component architecture is a joy to extend. — Leo Bennett [email protected]