Feat #6231 - automatic discovery of models from providers

[jakubsuchy]

Issue for this PR

Closes #6231

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Fixes issue #6231 to provide a generic way that providers can pull /v1/models, and therefore automatically update their model list at any time.

Updates documentation with information how providers can use this functionality

How did you verify your code works?

Testing + Automated testing

Screenshots / recordings

none

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Hey! Your PR title Fixes #6231 - automatic discovery of models from providers doesn't follow conventional commit format.

Please update it to start with one of:

• feat: or feat(scope): new feature
• fix: or fix(scope): bug fix
• docs: or docs(scope): documentation changes
• chore: or chore(scope): maintenance tasks
• refactor: or refactor(scope): code refactoring
• test: or test(scope): adding or updating tests

Where scope is the package name (e.g., app, desktop, opencode).

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search results, I found several potentially related PRs that address similar model discovery functionality:

Most Relevant:

• PR feat(opencode): auto-discover models from OpenAI-compatible providers #32731 - feat(opencode): auto-discover models from OpenAI-compatible providers - Directly addresses auto-discovery from OpenAI-compatible providers using their API endpoints
• PR feat(opencode): local LAN provider discovery + auto-discover models #27554 - feat(opencode): local LAN provider discovery + auto-discover models - Implements both LAN provider discovery and auto-model discovery
• PR feat(opencode): discover abacus models from /v1/models endpoint #34563 - feat(opencode): discover abacus models from /v1/models endpoint - Specifically implements discovery from the /v1/models endpoint

Related Features:

• PR feat: discover Modal models #39066 - feat: discover Modal models - Recent PR with similar model discovery pattern
• PR feat(opencode): add local server provider with auto model discovery #19959 - feat(opencode): add local server provider with auto model discovery - Earlier implementation of auto model discovery for local servers

These PRs are not exact duplicates of PR #39176, but they address overlapping concerns around automatic model discovery from various provider types. You may want to review these to ensure consistency in implementation approach and avoid duplicate logic.

[Hotragn]

I implemented this same feature independently before I found your PR — yours is further along (docs, config schema, SDK types), so I'm standing down and would rather help this one land. Four things from digging through the earlier attempt in #8359 that I think are the actual blockers worth pre-empting:

1. The new config options. @rekram1-node's notes there start with "ideally no extra config option" (comment), and that author dropped theirs in response — "1. No extra config option" (comment). This PR adds enable_model_discovery and disable_model_discovery, so it will probably hit the same objection. Your code comment has a fair rationale (it's an outbound request to a user-supplied URL) — might be worth making that argument up front, or keying off "provider is config-declared/authed" rather than a new flag.

2. Union vs. filter. The same note asks discovery to remove models too: if models.dev lists N and the endpoint returns N-2, the missing 2 should be dropped as unsupported. Right now discovery only adds ids that aren't already known, so stale models.dev entries stick around. (My version had this same gap.)

3. Timeout. AbortSignal.timeout(5_000) vs. the "1-3 sec tops" ask in that review. This runs on the provider-load path, so an unreachable endpoint adds the full delay to startup.

4. Minor: discovered models that models.dev doesn't know get limit.context: 0 / limit.output: 0 via buildConfigModel(..., {}, ...). That's fine for config-declared models where the user omitted limits, but with discovery it becomes the common case — probably worth confirming nothing downstream (compaction/context math) depends on a real context limit.

Reusing buildConfigModel for discovered models is nicer than what I did (I hand-rolled a minimal Model) — this way anything models.dev already knows keeps its real metadata and variants.