How to change openai model list?

[imrefazekas]

Hello,

I understand with OPENAI_API_BASE we can change the open API URL ... but in our case, that would be a Bifrost system so not the OpenAI models behind it. Is there a way to give a list of models to Langflow to be used? Especially in the "flow launcher chat UI"?

Thanks!

[false200]

@imrefazekas good question, and the short answer is yes you can use Bifrost models in Langflow, but OPENAI_API_BASE and the model dropdown are two separate things.

OPENAI_API_BASE only changes where requests go. The model list in the UI still comes from Langflow's own catalog (Settings, static constants, and the models.dev snapshot). Langflow does not automatically call Bifrost's /v1/models and populate the dropdown today. So pointing at Bifrost fixes routing, not the picker.

What actually works with Bifrost today

1. Per-component setup (most reliable)

In your flow's OpenAI or Language Model component (Advanced settings):

• OpenAI API Base → your Bifrost OpenAI-compatible endpoint, e.g. http://your-bifrost-host:8080/openai/v1
• API key → your Bifrost virtual key (often sk-bf-...)
• Model name → type the exact model id Bifrost expects

Since Langflow 1.5+, the chat model field is a combobox. You can click it and type a model name even if it is not in the list. That is the main escape hatch for Bifrost, where models are often provider/model format like anthropic/claude-sonnet-4 or openai/gpt-4o-mini, not plain OpenAI names.

2. Global Settings → Model Providers

Profile icon → Settings → Model Providers → configure OpenAI, add your key, enable models you want available app-wide.

This controls what shows up in Agent / Language Model dropdowns across flows, including launcher-style chat UIs that use the unified model picker. But the list is still Langflow's built-in catalog, not a live pull from Bifrost. You enable what you need, or type custom names in the combobox where supported.

3. Agent flows with a custom model port

If the global dropdown does not fit, wire a standalone OpenAI component (with Bifrost base URL + model name) into the Agent's Language Model input port. That bypasses the global provider list entirely and is the pattern people use for Ollama, vLLM, LocalAI, and gateways like Bifrost.

Flow launcher chat UI specifically

The launcher chat uses whatever model is configured in the flow itself (Agent or Language Model component). It does not magically discover Bifrost models on its own.

Practical approach:

1. Open the flow, set the model component to your Bifrost base URL + model name, save the flow.
2. Optionally enable the same model names in Settings → Model Providers so they appear in global pickers.
3. If the launcher exposes a model switcher, it will only show models you have enabled globally, not everything Bifrost serves.

So for launcher UX, you either pre-configure the model in the flow, or enable the models you want in global settings.

Is there a way to "give Langflow a list"?

Not as a single env var like OPENAI_MODELS=... in the current spec. Options today:

Approach	Works for chat models	Works for embeddings
Type model name in combobox	Yes	No (dropdown only)
Settings → Model Providers → enable models	Yes	Yes
OPENAI_API_BASE globally / per component	Routes requests	Routes requests
Self-hosted fork, add names to openai_constants.py	Yes	Yes (must be in list)
Custom OpenAI component wired to Agent	Yes	N/A

There is no built-in "point Langflow at Bifrost /v1/models and sync the dropdown" feature yet. That would be a reasonable feature request.

Bifrost-specific tips

• Use the OpenAI-compatible path (/openai/v1), not the LangChain path, for Langflow's OpenAI components.
• Model ids must match what Bifrost returns from GET /v1/models on your instance.
• If Bifrost uses virtual keys, put that key in the component or in global OpenAI provider settings.
• Test one model in the Playground first before worrying about the launcher list.

Minimal example config

In your flow's OpenAI / Agent model settings:

OpenAI API Base:  http://bifrost.internal:8080/openai/v1
API Key:          sk-bf-your-virtual-key
Model:            anthropic/claude-sonnet-4   (type it manually if not in dropdown)

Globally you can also set:

OPENAI_API_BASE=http://bifrost.internal:8080/openai/v1

But you still pick or type the model name per component.

Hope that helps.

[imrefazekas]

@false200 thank you for the quick answer.

The motivation behind my question: we have a provisioned on prem AI system so behind Bifrost, we have local LLMs.
and Im puzzled to see the models used by Langflow. We have 6+ models in play today.

[false200]

@imrefazekas yeah that's the annoying part. Langflow shows its own model catalog (models.dev + built-in OpenAI/Anthropic/Google lists). It doesn't know what's actually running behind your Bifrost. You can have 6 local models and the UI still shows a bunch of cloud gpt-* names you'll never hit.

What I'd do on-prem:

Point everything at Bifrost once:

OPENAI_API_BASE=http://bifrost.internal:8080/openai/v1

Put the Bifrost virtual key in Settings → Model Providers as the OpenAI key.

Get the real model names from Bifrost, not from Langflow:

curl -s http://bifrost.internal:8080/openai/v1/models \
  -H "Authorization: Bearer sk-bf-your-key"

Whatever is in data[].id is what you type in the flow. On-prem it's often stuff like ollama/llama-3.1-70b, not gpt-4o.

Then go to Settings → Model Providers, kill the providers you don't use, and under OpenAI only enable the names that match your fleet. If one isn't in the dropdown, just type it in the model field — chat components accept arbitrary names since 1.5.

For the flow launcher with 6 models, simplest is either one flow per model (model baked into each flow) or enable exactly those 6 in Model Providers if the launcher has a model switcher. It won't pull from Bifrost automatically.

If you need the dropdown to always list your 6 without typing: patch openai_constants.py in a custom image, or file a feature request for syncing from /v1/models. There's no env var for that today.

Quick test: grab one model id from that curl, set base URL + key + model in Playground, send a message. If that works you're fine and it's just UI cleanup.

[imrefazekas]

In the background Ollama is running .
We could do this: alias to internal models. So "gpt5.5" from Langflow perspective and Ollama will know it means qwen3.6 ...
but that is highly misleading...

I can get the ids but not sure where I can enter ...
in Settings → Model Providers I see OpenAI with 51 models, but I can not enter "ollama/qwen3.5" ...

[false200]

Settings → Model Providers isn't where you type model names. That screen is just toggles on Langflow's baked-in catalog. You can't add ollama/qwen3.5 there because it's not in their list, you're only enabling/disabling what's already there. That's why you're stuck.

The place you enter Bifrost model ids is in the flow, on the OpenAI or Language Model component. Click the model field and type ollama/qwen3.5 (or whatever curl .../openai/v1/models returned). Combobox since 1.5, doesn't need to be in the dropdown. Save the flow. Launcher uses whatever's saved in the flow.

Quick path:

1. Settings → Model Providers: set OpenAI API key to your Bifrost vk, base URL if there's a field for it (or set OPENAI_API_BASE env on the Langflow deployment)
2. Open your flow → Agent or Language Model component → model field → type ollama/qwen3.5
3. Playground, one message, confirm it hits Bifrost/Ollama

On the alias idea (gpt5.5 → qwen internally): yeah I'd skip it. Confusing for anyone debugging flows later, and Langflow will still show the fake name in the UI. Just use the real Bifrost ids in the flow. Cleaner.

Since Ollama is running locally you also have two other options:

Bifrost path (what you're doing): OpenAI component, Bifrost base URL, type ollama/... model id manually. Good when everything goes through the gateway.

Direct Ollama path: Agent component → Language Model dropdown → Custom → drag in an Ollama component, point base URL at Ollama (http://localhost:11434 or wherever), hit refresh, pick from the list. That one actually pulls from Ollama /api/tags. Wire Ollama output into Agent's Language Model port. Bypasses Bifrost but models show up properly in the component.

For 6 models in the launcher without typing every time: one flow per model with the id baked in, or patch openai_constants.py in a custom Langflow image so your Bifrost ids appear in dropdowns globally. Settings alone won't add new names.

If you tell me whether your flows use the Agent component or standalone Language Model I can be more specific on where exactly to click.

[imrefazekas]

I was able to edit the code, overwriting the URL and model. That works, just highly uncomfortable.
Thank you for your kind support.

Also made a feature request ticket.

I guess for the time being we need to investigate other solutions which support custom LLMs.

[false200]

Glad it works at least, patching url/model in code is annoying tho. ticket's probably the only real fix; if the launcher picker matters now, Flowise/Open WebUI handle custom gateways without this mess.

[imrefazekas]

my Dockerfile:

FROM langflowai/langflow:1.10.0
COPY openai_constants.py /app/.venv/lib/python3.14/site-packages/lfx/base/models/openai_constants.py

and my modified py file attached ... I build, deployed but list of models did not change at ...
openai_constants.py

Hmmm maybe its a different file we should manipulate ...

[richardchen874-sys]

This is a very real problem for on-prem / gateway-based setups.

If Langflow is pointed at Bifrost, LiteLLM, vLLM, Ollama-through-gateway, or any internal model router, then the model picker should ideally reflect the gateway’s real model fleet, not only Langflow’s built-in catalog.

Aliasing internal models as fake OpenAI names like gpt5.5 may work technically, but I agree it becomes misleading very quickly. It makes debugging harder because the UI no longer shows what model actually ran.

A cleaner design might be:

• allow a provider to define a custom /v1/models discovery endpoint
• sync model IDs from the gateway into Langflow’s model picker
• keep the real gateway model IDs visible in the flow
• optionally allow friendly display names, but preserve the real backend ID
• include capability metadata where available: chat, embeddings, vision, tools, context window, streaming, reasoning support
• allow admins to hide irrelevant built-in catalog models for on-prem deployments

For local/on-prem fleets with 6+ models, the model list is not just a UI detail. It affects correctness, debugging, cost tracking, and whether users know which model handled a workflow.

The current workaround of editing code or baking custom constants into an image works, but it is not ideal for teams that change model fleets over time.

I think this would be a useful feature request: gateway-backed model discovery for OpenAI-compatible providers, with optional admin-controlled model visibility.