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 #2514] [BUG/FEAT]: Workspace Agent fallback waterfall #1625

New Issue
Closed
opened 2026-02-22 18:25:45 -05:00 by yindo · 0 comments
yindo commented 2026-02-22 18:25:45 -05:00
Owner
Copy Link
Copy Source

Originally created by @timothycarambat on GitHub (Oct 21, 2024).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/2514

How are you running AnythingLLM?

All versions

What happened?

When we implemented https://github.com/Mintplex-Labs/anything-llm/issues/2353 this was an incomplete implementation of the fallback logic for agent selection.

If I am a user and I create a workspace and send an @agent invocation the logic for provider/model selection for agent execution should be:

  1. use the explicitly set agentProvider and agentModel combination. No verification is done to confirm the pairing is valid, just that it exists. The API will return any errors anyway.

  2. Fallback to the workspaces chatProvider and chatModel overrides, this at least keeps answers within the same model preference the user-defined for a workspace.

  3. Lastly, attempt to use the LLM_PROVIDER env and its ENV default model. If no ENV preference can be found - assume a static model string that is generally available for the provider. If that cannot be determined - return null and probably exit since most LLM providers do not accept null for model.

This covers every case of agent invocation without the user needing to specify anything to unlock agents since our coverage is mostly complete now anyway. The user should not have to set an agent provider to use agents, just like how chatting works. You can define a model for a per-workspace preference, but it is not required.

TODO: we may have fallback procedure not failover to chatprovider/model since that can be confusing, but we can revist

Are there known steps to reproduce?

No response

Originally created by @timothycarambat on GitHub (Oct 21, 2024). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/2514 ### How are you running AnythingLLM? All versions ### What happened? When we implemented https://github.com/Mintplex-Labs/anything-llm/issues/2353 this was an incomplete implementation of the fallback logic for agent selection. If I am a user and I create a workspace and send an `@agent` invocation the logic for provider/model selection for agent execution should be: 1. use the explicitly set `agentProvider` and `agentModel` combination. No verification is done to confirm the pairing is valid, just that it exists. The API will return any errors anyway. 2. Fallback to the workspaces `chatProvider` and `chatModel` overrides, this at least keeps answers within the same model preference the user-defined for a workspace. 3. Lastly, attempt to use the `LLM_PROVIDER` env and its ENV default model. If no ENV preference can be found - assume a static model string that is generally available for the provider. If that cannot be determined - return null and probably exit since most LLM providers do not accept `null` for model. This covers every case of agent invocation without the user needing to specify anything to unlock agents since our coverage is mostly complete now anyway. The user should not _have_ to set an agent provider to use agents, just like how chatting works. You can define a model for a per-workspace preference, but it is not required. TODO: we may have fallback procedure not failover to chatprovider/model since that can be confusing, but we can revist ### Are there known steps to reproduce? _No response_
yindo added the enhancement label 2026-02-22 18:25:45 -05:00
yindo closed this issue 2026-02-22 18:25:45 -05:00
yindo changed title from [BUG/FEAT]: Workspace Agent fallback waterfall to [GH-ISSUE #2514] [BUG/FEAT]: Workspace Agent fallback waterfall 2026-06-05 14:41:48 -04:00
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
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#1625
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?