[GH-ISSUE #5186] Model selection from previous provider persists when switching backends #4959

Closed
opened 2026-06-05 14:51:08 -04:00 by yindo · 5 comments
Owner

Originally created by @shanevcantwell on GitHub (Mar 10, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5186

Summary

When switching the LLM provider (e.g., from LM Studio to Generic OpenAI), the model selected in the previous provider's dropdown is used for requests instead of the model specified in the new provider's input field. This causes requests to fail because the model name doesn't exist on the new backend.

Reproduction

  1. Configure LM Studio as the LLM provider
  2. Select a model from the LM Studio dropdown (e.g., qwen3.5-35b-a3b@iq4_nl)
  3. Switch the provider to Generic OpenAI (llama-server)
  4. Enter the correct model name in the Generic OpenAI text field (e.g., Qwen3.5-35B-A3B-UD-Q4_K_XL)
  5. Send a message — the request uses the LM Studio model name, not the Generic OpenAI model name

Expected behavior

When the provider is switched, the model selection should come from the active provider's control — either the dropdown (for providers that enumerate models) or the text field (for generic OpenAI-compatible endpoints).

Actual behavior

The model name from the previously selected provider's dropdown leaks into the new provider's requests. The logic appears to prefer the dropdown value if populated, regardless of which provider is active.

Impact

This makes it impossible to switch between providers without the stale model name causing failures. The user sees connection errors or model-not-found responses and may incorrectly conclude the new backend is incompatible.

Environment

  • AnythingLLM (current Docker build)
  • Switching between: LM Studio → Generic OpenAI (llama-server)
  • Linux host
Originally created by @shanevcantwell on GitHub (Mar 10, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5186 ## Summary When switching the LLM provider (e.g., from LM Studio to Generic OpenAI), the model selected in the previous provider's dropdown is used for requests instead of the model specified in the new provider's input field. This causes requests to fail because the model name doesn't exist on the new backend. ## Reproduction 1. Configure LM Studio as the LLM provider 2. Select a model from the LM Studio dropdown (e.g., `qwen3.5-35b-a3b@iq4_nl`) 3. Switch the provider to Generic OpenAI (llama-server) 4. Enter the correct model name in the Generic OpenAI text field (e.g., `Qwen3.5-35B-A3B-UD-Q4_K_XL`) 5. Send a message — the request uses the LM Studio model name, not the Generic OpenAI model name ## Expected behavior When the provider is switched, the model selection should come from the active provider's control — either the dropdown (for providers that enumerate models) or the text field (for generic OpenAI-compatible endpoints). ## Actual behavior The model name from the previously selected provider's dropdown leaks into the new provider's requests. The logic appears to prefer the dropdown value if populated, regardless of which provider is active. ## Impact This makes it impossible to switch between providers without the stale model name causing failures. The user sees connection errors or model-not-found responses and may incorrectly conclude the new backend is incompatible. ## Environment - AnythingLLM (current Docker build) - Switching between: LM Studio → Generic OpenAI (llama-server) - Linux host
yindo added the needs info / can't replicate label 2026-06-05 14:51:08 -04:00
yindo closed this issue 2026-06-05 14:51:08 -04:00
Author
Owner

@shanevcantwell commented on GitHub (Mar 10, 2026):

Correction: this only triggers when using @agent functionality. Normal chat with the Generic OpenAI provider uses the correct model from the text field. The stale model name from the previous provider (LM Studio dropdown) only leaks into agent requests.

This suggests the agent code path has a separate model resolution logic that prefers the dropdown value over the text input, while the normal chat path correctly reads from the active provider's control.

<!-- gh-comment-id:4031136829 --> @shanevcantwell commented on GitHub (Mar 10, 2026): Correction: this only triggers when using `@agent` functionality. Normal chat with the Generic OpenAI provider uses the correct model from the text field. The stale model name from the previous provider (LM Studio dropdown) only leaks into agent requests. This suggests the agent code path has a separate model resolution logic that prefers the dropdown value over the text input, while the normal chat path correctly reads from the active provider's control.
Author
Owner

@timothycarambat commented on GitHub (Mar 10, 2026):

You almost certainly have a model set in the workspaces settings for the chat model or Agent model tabs that is taking precedence over the system model - which is intended. Check the workspaces Chat Settings and Agent Settings tabs after clicking on the gear icon on the workspace - you probably have something set for one or both of those properties which is why a change does not apply.

<!-- gh-comment-id:4031947358 --> @timothycarambat commented on GitHub (Mar 10, 2026): You almost certainly have a model set in the _workspaces_ settings for the chat model or Agent model tabs that is taking precedence over the system model - which is intended. Check the workspaces Chat Settings and Agent Settings tabs after clicking on the gear icon on the workspace - you probably have something set for one or both of those properties which is why a change does not apply.
Author
Owner

@shanevcantwell commented on GitHub (Mar 10, 2026):

It's likely super edge case, but it's actually gotten into a state that I think is going to require external intervention. Since I'm currently stuck, I went ahead and grabbed screenshots. Notice the error is pointing to a model that no longer exists in the UI. I double checked to see if my idea that it was getting picked up by the LM Studio settings is not the case, although I think switching between the two is it got in there.

Error

Image

Instance LLM configuration (dummy name right now):

Image

Workspace Chat settings:

Image

Workspace Agent settings:

Image

Generic OpenAI custom settings. Populated through Instance LLM config but to verify:

Image

LM Studio settings to confirm the error model is no longer anywhere in the UI:

Image
<!-- gh-comment-id:4033426319 --> @shanevcantwell commented on GitHub (Mar 10, 2026): It's likely super edge case, but it's actually gotten into a state that I think is going to require external intervention. Since I'm currently stuck, I went ahead and grabbed screenshots. Notice the error is pointing to a model that no longer exists in the UI. I double checked to see if my idea that it was getting picked up by the LM Studio settings is not the case, although I think switching between the two is it got in there. # Error <img width="1657" height="1157" alt="Image" src="https://github.com/user-attachments/assets/3399122e-7f73-4ed6-9917-14eab5898cd4" /> ## Instance LLM configuration (dummy name right now): <img width="2264" height="849" alt="Image" src="https://github.com/user-attachments/assets/6d091783-7774-4c7f-8711-24addd669af2" /> ## Workspace Chat settings: <img width="902" height="733" alt="Image" src="https://github.com/user-attachments/assets/f1d08109-c90c-463b-8894-5c9328a1e2a2" /> ## Workspace Agent settings: <img width="1606" height="575" alt="Image" src="https://github.com/user-attachments/assets/6d2868b8-2f5d-40e8-a65f-1a43e672a9ab" /> ## Generic OpenAI custom settings. Populated through Instance LLM config but to verify: <img width="1089" height="1157" alt="Image" src="https://github.com/user-attachments/assets/76100366-61ef-444f-9b98-84cd3531e0ff" /> ## LM Studio settings to confirm the error model is no longer anywhere in the UI: <img width="979" height="685" alt="Image" src="https://github.com/user-attachments/assets/2e7ffece-db0b-4e79-9489-c0f80375efa4" />
Author
Owner

@timothycarambat commented on GitHub (Mar 10, 2026):

Swap the workspace LLM provider to System Default and it will set the field to null and then it will use your System model. You can then set it to a different provider and model and it will use those going forward if it seems stuck on an old config.

<!-- gh-comment-id:4033527400 --> @timothycarambat commented on GitHub (Mar 10, 2026): Swap the workspace LLM provider to `System Default` and it will set the field to `null` and then it will use your System model. You can then set it to a different provider and model and it will use those going forward if it seems stuck on an old config.
Author
Owner

@shanevcantwell commented on GitHub (Mar 10, 2026):

Thanks much for quick replies. System Default works, and I realized that although the bad model entry still didn't clear, just deleting and moving into a new workspace worked too. Cheers

<!-- gh-comment-id:4033774260 --> @shanevcantwell commented on GitHub (Mar 10, 2026): Thanks much for quick replies. System Default works, and I realized that although the bad model entry still didn't clear, just deleting and moving into a new workspace worked too. Cheers
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#4959