Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5084] [FEAT]:Support Multiple Generic OpenAI Configuration Presets #4905

New Issue
Closed
opened 2026-06-05 14:50:47 -04:00 by yindo · 3 comments
yindo commented 2026-06-05 14:50:47 -04:00
Owner
Copy Link
Copy Source

Originally created by @yangcai0731 on GitHub (Feb 27, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5084

What would you like to see?

Currently, the Generic OpenAI provider only supports saving a single set of configuration (including Base URL, API Key, Model Name and other related parameters). For users who need to connect to multiple OpenAI-compatible API services (such as regional large model APIs, different third-party OpenAI-format endpoints), we have to re-fill and modify all configuration parameters every time we switch between services, which is very inefficient and error-prone.

Add support for multiple Generic OpenAI configuration presets:

  1. Allow users to save multiple named Generic OpenAI configuration sets, each containing independent Base URL, API Key, default model name, context window and other core parameters
  2. Add a preset selector dropdown in both the global LLM settings and per-workspace Chat Settings, to switch between saved configurations in one click
  3. Support adding, editing, deleting and renaming these presets directly in the settings interface

The current workaround is to create separate workspaces for each API service, but this is not ideal: it forces users to split their workflow across multiple workspaces just to switch models, and cannot share the same document/embedding context between different models smoothly.
Another alternative is to use a local proxy service like LiteLLM, but this adds extra setup and maintenance overhead, which is not friendly for non-technical users.

This feature will greatly improve the experience for users who rely on multiple OpenAI-compatible LLM services, especially for users who need to connect to non-US regional API providers. It will also make the Generic OpenAI integration much more flexible without breaking any existing functionality.

“Thank you so much for your hard work on this project and for reviewing this feature request! We really appreciate your consideration of this improvement!”

Originally created by @yangcai0731 on GitHub (Feb 27, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5084 ### What would you like to see? Currently, the Generic OpenAI provider only supports saving a single set of configuration (including Base URL, API Key, Model Name and other related parameters). For users who need to connect to multiple OpenAI-compatible API services (such as regional large model APIs, different third-party OpenAI-format endpoints), we have to re-fill and modify all configuration parameters every time we switch between services, which is very inefficient and error-prone. Add support for multiple Generic OpenAI configuration presets: 1. Allow users to save multiple named Generic OpenAI configuration sets, each containing independent Base URL, API Key, default model name, context window and other core parameters 2. Add a preset selector dropdown in both the global LLM settings and per-workspace Chat Settings, to switch between saved configurations in one click 3. Support adding, editing, deleting and renaming these presets directly in the settings interface The current workaround is to create separate workspaces for each API service, but this is not ideal: it forces users to split their workflow across multiple workspaces just to switch models, and cannot share the same document/embedding context between different models smoothly. Another alternative is to use a local proxy service like LiteLLM, but this adds extra setup and maintenance overhead, which is not friendly for non-technical users. This feature will greatly improve the experience for users who rely on multiple OpenAI-compatible LLM services, especially for users who need to connect to non-US regional API providers. It will also make the Generic OpenAI integration much more flexible without breaking any existing functionality. “Thank you so much for your hard work on this project and for reviewing this feature request! We really appreciate your consideration of this improvement!”
yindo added the enhancementfeature request labels 2026-06-05 14:50:47 -04:00
yindo closed this issue 2026-06-05 14:50:47 -04:00
yindo commented 2026-06-05 14:50:48 -04:00
Author
Owner
Copy Link
Copy Source

@dandawg commented on GitHub (Feb 27, 2026):

The current workaround is to create separate workspaces for each API service

As far as I can tell, if you use the generic openai provider in two different workspaces, you can select a different named model, but it still assumes you are using the same endpoint (you can't have multiple endpoints).

This is issue represents a very important use case. To be able to compare different open-source models (at different endpoints), we need this implemented right away. I may wish to switch between a multi-modal model and a reasoning model that I have access to. Or between a large and small version of the same model that I have spun up and would like to compare. It is burdensome to have to re-enter endpoint and token details each time in the one available slot.

<!-- gh-comment-id:3975147188 --> @dandawg commented on GitHub (Feb 27, 2026): > The current workaround is to create separate workspaces for each API service As far as I can tell, if you use the generic openai provider in two different workspaces, you can select a different named model, but it still assumes you are using the same endpoint (you can't have multiple endpoints). This is issue represents a very important use case. To be able to compare different open-source models (at different endpoints), we need this implemented right away. I may wish to switch between a multi-modal model and a reasoning model that I have access to. Or between a large and small version of the same model that I have spun up and would like to compare. It is burdensome to have to re-enter endpoint and token details each time in the one available slot.
yindo commented 2026-06-05 14:50:48 -04:00
Author
Owner
Copy Link
Copy Source

@dandawg commented on GitHub (Mar 2, 2026):

Another use case of this is for spinning up/testing different versions of the same model (at differrent sizes/quantizations etc.) to compare the experience. For example, how small/fast do I need vs. how much thinking/tool calling?

It would be super cool to be able to enter a prompt, run it against one model version, then toggle to another model version, and run the same prompt again to compare. (This assumes I have multiple open-source models running at separate endpoints, which is something I do every day in my work.)

<!-- gh-comment-id:3985596697 --> @dandawg commented on GitHub (Mar 2, 2026): Another use case of this is for spinning up/testing different versions of the same model (at differrent sizes/quantizations etc.) to compare the experience. For example, how small/fast do I need vs. how much thinking/tool calling? It would be super cool to be able to enter a prompt, run it against one model version, then toggle to another model version, and run the same prompt again to compare. (This assumes I have multiple open-source models running at separate endpoints, which is something I do every day in my work.)
yindo commented 2026-06-05 14:50:48 -04:00
Author
Owner
Copy Link
Copy Source

@iggy commented on GitHub (Mar 5, 2026):

related to #4493 ?

<!-- gh-comment-id:4002481400 --> @iggy commented on GitHub (Mar 5, 2026): related to #4493 ?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label enhancement feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#4905
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?