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.

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.

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.

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.

it's still relevant because people have been asking for this for months or years

have anyone checked if this is available/working in opencode2/beta ? I even cannot tell/find where is source code of the beta
https://opencode.ai/v2/docs