[Bug? 3.8.50] Hidden models still show up in v1/models list

[asully22]

When I hide models on the provider settings, they are still showing up in my v1/models list making any provider with a large number of models explode my list. Is this expected?

[MLuc24]

Not expected — the filtering is there and it is applied broadly, so something specific is failing rather than the feature being absent.

In src/app/api/v1/models/catalog.ts on release/v3.8.50 the catalog loads the hidden map once:

const hiddenModelsByProvider = getHiddenModelsByProvider();

and then runs isModelHiddenBulk(...) at roughly fifteen call sites — static provider models, synced models, OpenRouter, combos, and each of the embedding, image, rerank, audio, moderation, video and music registries. So a model you hid should be dropped from the list on essentially every path.

The interesting part is the comment sitting directly above that helper, because it describes exactly the symptom you are reporting as a bug that was already hit once:

...a node UUID, an alias like cc/gh/cx, or a canonical provider id — see PATCH /api/provider-models. The catalog loops below each key their own lookup differently (raw connection provider, canonical id, or alias), so a single-key lookup missed the override whenever the write key and the read key diverged.

In other words, the settings UI records "this model is hidden" under one key, the catalog looks it up under another, the lookup misses, and the model reappears in /v1/models while still showing as hidden in the UI. The current helper compensates by checking four keys rather than one:

const keysToCheck = [providerKey, canonical, alias, nodePrefix].filter(
  (k): k is string => Boolean(k)
);

Which means a hide written under some fifth key — or under a key that does not resolve to any of those four for your particular provider — still leaks through. That is the shape of what you are seeing.

So the detail worth adding to your report is which provider. You mention "any provider with a large number of models", which suggests OpenRouter or a compatible/custom node, and those are precisely the cases where the raw connection key, the canonical id and the alias are most likely to diverge. With the provider named, whoever picks this up can check what PATCH /api/provider-models actually stored for you against what the catalog looks up, which is a much shorter path than reproducing from scratch.

[diegosouzapw]

Hey @asully22! Confirmed -- real bug, not expected behavior. On the current release/v3.8.50 tree the unified /v1/models builder (src/app/api/v1/models/catalog.ts) never applies getHiddenModelsByProvider(); the hidden flag is honored in auto-combo candidate building but not in the public list (the isHidden field exists in the helper type and nothing consumes it).

Opened #11475 to track it.

(@MLuc24 thanks for digging in -- note the catalog.ts snippet quoted isn't present at the current tip, which matches the repro.)