model_picker_enabled filter in GitHub Copilot model picker — strict or permissive?

[LoackyBit]

Following the work in #897, we need to settle a design decision before the PR can be merged.

The GitHub Copilot /models endpoint returns a model_picker_enabled field for each model. The current implementation filters only by policy.state !== "disabled" and ignores model_picker_enabled entirely. The field is parsed but never applied as a condition.

The question: should the /model picker enforce model_picker_enabled === true?

Option	Pros	Cons
Enforce model_picker_enabled	Aligns with GitHub's schema; hides models not intended for end-user selection; safer long-term	Some working models may disappear from the picker
Ignore model_picker_enabled	More permissive; users see every model that works today; embedding and search/retrieval models remain visible and available for sub-agent configurations (e.g. a dedicated search or embedding sub-agent); OpenClaude targets developers who benefit from full catalog visibility, including models not intended for the standard chat picker	Exposes models GitHub doesn't intend to surface; those could be restricted or break later

GitHub itself uses this field to control what appears in its own UI, so ignoring it feels inconsistent with the API contract, but there is a real trade-off around user-visible model coverage.

Happy to implement whichever direction the maintainers prefer. Tagging @Meetpatel006 and @jatmn since both have been involved in the review.

[Meetpatel006]

Following the work in #897, we need to settle a design decision before the PR can be merged.

The GitHub Copilot /models endpoint returns a model_picker_enabled field for each model. The current implementation filters only by policy.state !== "disabled" and ignores model_picker_enabled entirely — the field is parsed but never applied as a condition.

The question: should the /model picker enforce model_picker_enabled === true?

Option	Pros	Cons
Enforce model_picker_enabled	Aligns with GitHub's schema; hides models not intended for end-user selection; safer long-term	Some working models may disappear from the picker
Ignore model_picker_enabled	More permissive; users see every model that works today	Exposes models GitHub doesn't intend to surface; those could be restricted or break later

GitHub itself uses this field to control what appears in its own UI, so ignoring it feels inconsistent with the API contract — but there is a real trade-off around user-visible model coverage.

Happy to implement whichever direction the maintainers prefer. Tagging @Meetpatel006 and @jatmn since both have been involved in the review.

Let me check which is better

[LoackyBit]

I think ignore is better because you can use hidden models and if you don't want them you just don't select them

[Meetpatel006]

sorry for that but you need to enforce it so the new code is looks like below snippet in models.ts

.filter(model => model.model_picker_enabled && model.policy?.state !== 'disabled')

And also, you need to modify the test file accordingly.

[LoackyBit]

vote and we will decide whether to keep it or remove it. after 5 or plus votes I'll implement the pool result

[jatmn]

I would probably say wait for #910 to merge. The changes in #897 will be impacted quite a lot.

There is a considerable framework change that touches most of the same source in #910 .

[LoackyBit]

please can you vote on the poll?

[jatmn]

im not against it.. but i also dont use that provider either.
but /model is changed quite a bit as well as the source of models in general n #910 im being serious when i say it changes ALOT about how the system works currently.

I would recommend rebasing on the 910 PR and trying your change ontop of it and seeing the results.

[LoackyBit]

yeah I saw #910. I'll try to make my change ontop of it when the PR will be merged.

[jatmn]

the current framework for models and providers has multiple duplicative sources of truth or "master" lists
910 changes that and removes a few of them.. there is a few left after, but followup will be changing that as well.
No reason to have so many "master" duplicates.