github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-08 21:09:41 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #22578] issue: OpenRouter model enable/disable state becomes stale or inverted after switching between restricted model_ids and full catalog #35283

New Issue
Open
opened 2026-04-25 09:30:48 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-25 09:30:48 -05:00
Owner
Copy Link

Originally created by @random42 on GitHub (Mar 11, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/22578

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • I have also searched in the CLOSED issues AND CLOSED discussions and found no exact match for this combined behavior.
  • I am using the latest version of Open WebUI.

Related but not equivalent:

  • #21959 "Enable/Disable All Models in the Admin Panel not working"
  • #11293 "disabling a model persists all details"

This issue appears to be the combination of both behaviors and can leave the admin Models page in a stale or apparently inverted state for OpenRouter-discovered models.

Installation Method

Other

Open WebUI Version

Not provided

Ollama Version (if applicable)

Not applicable

Operating System

macOS

Browser (if applicable)

Not provided

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup to the extent currently available.
  • I have clearly listed the relevant configuration and exact timeline below.
  • I have documented precise reproduction steps based on the observed timeline.

Expected Behavior

When using OpenRouter without specifying model_ids, then disabling/enabling models in Admin > Settings > Models, the saved enabled/disabled state should remain consistent.

Changing the OpenRouter connection between:

  • a restricted model_ids list, and
  • the full discovered model catalog

should not resurrect stale per-model state from an older catalog in a way that makes the current model set appear inverted or inconsistent.

Bulk Enable All / Disable All should persist reliably for discovered provider models, not just update the UI optimistically.

Actual Behavior

After switching back and forth between restricted model_ids and the full discovered OpenRouter catalog, the Models admin page can end up in a stale or effectively inverted state.

Observed symptom from the reporter:

  • A previous state from an earlier day reappears.
  • Models that should now be enabled are disabled, and vice versa.
  • Older model variants such as GPT 5.2 or other earlier OpenRouter models may reappear with their previous saved disabled state, while newly selected models do not reflect the most recent bulk action.

This makes the model enable/disable state look random or inverted, but it appears to be deterministic reuse of stale saved model records by exact model ID, combined with bulk actions not persisting for many discovered models.

Steps to Reproduce

Reporter timeline, reproduced as a sequential scenario:

  1. Configure an OpenRouter connection in Open WebUI.
  2. In the connection settings, do not set specific model_ids, so Open WebUI discovers the full catalog from OpenRouter.
  3. Go to Admin > Settings > Models.
  4. Use the models page to disable all models, then enable only the ones you want.
  5. Change the OpenRouter connection settings to use a specific restricted model_ids list.
  6. Later, remove model_ids again so Open WebUI discovers the full catalog once more.
  7. On the models page, again disable all and enable only the currently desired models. At this point the desired set may be different from before, for example GPT 5.4 instead of GPT 5.2.
  8. Revisit the next day or after the catalog/settings have refreshed.
  9. Observe that the effective state resembles an older prior configuration, with enabled/disabled status apparently flipped or stale.

Concrete user report:

  1. enabled all OpenRouter models by not setting specific model ids in connection settings
  2. disabled all, enabled only the ones wanted
  3. switched to specific model ids from connection settings
  4. removed all model ids and switched back to getting every model again
  5. disabled all, enabled only the ones wanted again, but this time the desired set was slightly different, e.g. GPT 5.4 instead of GPT 5.2
  6. later, the state matched the older setup from step 2, but enabled models were disabled and vice versa, e.g. older models like GPT 5.2, Gemini 3.0, etc. showed the old saved state instead of the current intended one

Logs & Screenshots

No logs or screenshots available yet.

Code-level findings from local inspection of main branch:

  1. Base/provider models default to enabled when there is no saved DB row.

    • src/lib/components/admin/Settings/Models.svelte initializes discovered models with is_active: true if no workspace model row exists.

  2. Bulk Enable All / Disable All only call the toggle endpoint.

    • src/lib/components/admin/Settings/Models.svelte
    • They optimistically flip the UI and then call /api/v1/models/model/toggle?id=... for each model.

  3. The toggle endpoint only works for models that already have a DB row.

    • backend/open_webui/routers/models.py
    • If a model row does not already exist, /model/toggle returns NOT_FOUND.

  4. Individual toggles do create a DB row on first toggle.

    • src/lib/components/admin/Settings/Models.svelte
    • If the model does not yet have a persisted row, the single-model toggle path calls /api/v1/models/create with the current is_active value.

  5. Saved model rows are later reapplied by exact model ID when provider models are rediscovered.

    • backend/open_webui/utils/models.py
    • All saved custom/base-model rows are loaded via Models.get_all_models() and overlaid onto discovered provider models by matching custom_model.id.
    • If the saved row has is_active == false, the discovered model is removed from the merged model list.

Taken together, this means:

  • bulk actions may not persist for many discovered OpenRouter models because those models have no DB row yet,
  • single toggles do persist for some exact IDs,
  • later, when OpenRouter exposes a different or previously seen catalog again, old saved rows are reapplied by exact model ID,
  • the resulting state can look inverted or stale after switching between restricted model_ids and the full catalog.

Additional Information

Possible fixes:

  1. Fix bulk persistence for discovered provider models.

    • Enable All / Disable All should create missing model rows before toggling, or use an upsert/set-active endpoint instead of a pure toggle endpoint.

  2. Replace toggle semantics with explicit set semantics.

    • A set model active = true/false endpoint is safer than repeatedly calling toggle, especially for optimistic UI flows.

  3. Do not persist unrelated model metadata on first disable/enable unless needed.

    • Persist only the fields that were intentionally changed, or keep a dedicated per-model state record for visibility/active flags.

  4. Consider cleanup or invalidation of stale saved rows for provider-discovered models when the upstream model catalog changes materially.

    • At minimum, avoid surprising reuse of old state after switching between restricted model_ids and the full discovered list.

  5. Revisit issue #21959.

    • It was closed as "Unable to reproduce", but this report provides a scenario where the failure is not just a no-op UI bug; it combines with stale persisted rows and produces long-lived inconsistent state.

A practical workaround today seems to be deleting the offending rows from the model table, similar to the workaround mentioned in #11293, then reconfiguring models from scratch.

Originally created by @random42 on GitHub (Mar 11, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/22578 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no exact match for this combined behavior. - [x] I am using the latest version of Open WebUI. Related but not equivalent: - #21959 "Enable/Disable All Models in the Admin Panel not working" - #11293 "disabling a model persists all details" This issue appears to be the combination of both behaviors and can leave the admin Models page in a stale or apparently inverted state for OpenRouter-discovered models. ### Installation Method Other ### Open WebUI Version _Not provided_ ### Ollama Version (if applicable) _Not applicable_ ### Operating System macOS ### Browser (if applicable) _Not provided_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [ ] I am using the latest version of **both** Open WebUI and Ollama. - [ ] I have included the browser console logs. - [ ] I have included the Docker container logs. - [x] I have provided every relevant configuration, setting, and environment variable used in my setup to the extent currently available. - [x] I have clearly listed the relevant configuration and exact timeline below. - [x] I have documented precise reproduction steps based on the observed timeline. ### Expected Behavior When using OpenRouter without specifying `model_ids`, then disabling/enabling models in Admin > Settings > Models, the saved enabled/disabled state should remain consistent. Changing the OpenRouter connection between: - a restricted `model_ids` list, and - the full discovered model catalog should not resurrect stale per-model state from an older catalog in a way that makes the current model set appear inverted or inconsistent. Bulk `Enable All` / `Disable All` should persist reliably for discovered provider models, not just update the UI optimistically. ### Actual Behavior After switching back and forth between restricted `model_ids` and the full discovered OpenRouter catalog, the Models admin page can end up in a stale or effectively inverted state. Observed symptom from the reporter: - A previous state from an earlier day reappears. - Models that should now be enabled are disabled, and vice versa. - Older model variants such as `GPT 5.2` or other earlier OpenRouter models may reappear with their previous saved disabled state, while newly selected models do not reflect the most recent bulk action. This makes the model enable/disable state look random or inverted, but it appears to be deterministic reuse of stale saved model records by exact model ID, combined with bulk actions not persisting for many discovered models. ### Steps to Reproduce Reporter timeline, reproduced as a sequential scenario: 1. Configure an OpenRouter connection in Open WebUI. 2. In the connection settings, do **not** set specific `model_ids`, so Open WebUI discovers the full catalog from OpenRouter. 3. Go to Admin > Settings > Models. 4. Use the models page to disable all models, then enable only the ones you want. 5. Change the OpenRouter connection settings to use a specific restricted `model_ids` list. 6. Later, remove `model_ids` again so Open WebUI discovers the full catalog once more. 7. On the models page, again disable all and enable only the currently desired models. At this point the desired set may be different from before, for example `GPT 5.4` instead of `GPT 5.2`. 8. Revisit the next day or after the catalog/settings have refreshed. 9. Observe that the effective state resembles an older prior configuration, with enabled/disabled status apparently flipped or stale. Concrete user report: 1. enabled all OpenRouter models by not setting specific model ids in connection settings 2. disabled all, enabled only the ones wanted 3. switched to specific model ids from connection settings 4. removed all model ids and switched back to getting every model again 5. disabled all, enabled only the ones wanted again, but this time the desired set was slightly different, e.g. GPT 5.4 instead of GPT 5.2 6. later, the state matched the older setup from step 2, but enabled models were disabled and vice versa, e.g. older models like GPT 5.2, Gemini 3.0, etc. showed the old saved state instead of the current intended one ### Logs & Screenshots No logs or screenshots available yet. Code-level findings from local inspection of `main` branch: 1. Base/provider models default to enabled when there is no saved DB row. - `src/lib/components/admin/Settings/Models.svelte` initializes discovered models with `is_active: true` if no workspace model row exists. 2. Bulk `Enable All` / `Disable All` only call the toggle endpoint. - `src/lib/components/admin/Settings/Models.svelte` - They optimistically flip the UI and then call `/api/v1/models/model/toggle?id=...` for each model. 3. The toggle endpoint only works for models that already have a DB row. - `backend/open_webui/routers/models.py` - If a model row does not already exist, `/model/toggle` returns `NOT_FOUND`. 4. Individual toggles do create a DB row on first toggle. - `src/lib/components/admin/Settings/Models.svelte` - If the model does not yet have a persisted row, the single-model toggle path calls `/api/v1/models/create` with the current `is_active` value. 5. Saved model rows are later reapplied by exact model ID when provider models are rediscovered. - `backend/open_webui/utils/models.py` - All saved custom/base-model rows are loaded via `Models.get_all_models()` and overlaid onto discovered provider models by matching `custom_model.id`. - If the saved row has `is_active == false`, the discovered model is removed from the merged model list. Taken together, this means: - bulk actions may not persist for many discovered OpenRouter models because those models have no DB row yet, - single toggles do persist for some exact IDs, - later, when OpenRouter exposes a different or previously seen catalog again, old saved rows are reapplied by exact model ID, - the resulting state can look inverted or stale after switching between restricted `model_ids` and the full catalog. ### Additional Information Possible fixes: 1. Fix bulk persistence for discovered provider models. - `Enable All` / `Disable All` should create missing model rows before toggling, or use an upsert/set-active endpoint instead of a pure toggle endpoint. 2. Replace toggle semantics with explicit set semantics. - A `set model active = true/false` endpoint is safer than repeatedly calling `toggle`, especially for optimistic UI flows. 3. Do not persist unrelated model metadata on first disable/enable unless needed. - Persist only the fields that were intentionally changed, or keep a dedicated per-model state record for visibility/active flags. 4. Consider cleanup or invalidation of stale saved rows for provider-discovered models when the upstream model catalog changes materially. - At minimum, avoid surprising reuse of old state after switching between restricted `model_ids` and the full discovered list. 5. Revisit issue #21959. - It was closed as "Unable to reproduce", but this report provides a scenario where the failure is not just a no-op UI bug; it combines with stale persisted rows and produces long-lived inconsistent state. A practical workaround today seems to be deleting the offending rows from the `model` table, similar to the workaround mentioned in #11293, then reconfiguring models from scratch.
GiteaMirror added the bug label 2026-04-25 09:30:48 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#35283
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?