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

Potential Duplicate PRs Found

Based on the search results, there are two PRs that appear to be related to or potentially addressing similar functionality:

1. PR Fetch from model list from /v1/models/ from OpenAI Compatible APIs #3427: "Fetch from model list from /v1/models/ from OpenAI Compatible APIs"

   • Fetch from model list from /v1/models/ from OpenAI Compatible APIs #3427
   • This PR directly addresses fetching models from the OpenAI-compatible /v1/models/ endpoint, which is the core feature of PR feat(opencode): add model detection for local providers #8359.

2. PR Adding the auto-detection of ollama local with a variable for baseURL #3726: "Adding the auto-detection of ollama local with a variable for baseURL"

   • Adding the auto-detection of ollama local with a variable for baseURL #3726
   • This PR adds auto-detection for Ollama (another local provider), which is related to the automatic model detection feature being added for local providers in PR feat(opencode): add model detection for local providers #8359.

Recommendation: You should review these PRs to check if they have been merged, closed, or superseded, and whether PR #8359 builds upon or duplicates their work.

I was going to add this this week, some notes:

• ideally no extra config option
• models SHOULD be sourced from the provider models endpoint to a degree for all openai compat, like say models.dev says they have N models but the provider endpoint returns N-2, we should drop those 2 models because normally those aren't supported by that persons subscription or they disabled them or something (if this makes sense),
• Does the lmstudio endpoint not return any info about the model? Context size? Supported Attachments? Etc?

• The LMStudio endpoint only returns the model ID, effectively... Here is an example:

  - curl http://192.168.10.203:1234/v1/models
  {
    "data": [
      {
        "id": "zai-org/glm-4.6v-flash",
        "object": "model",
        "owned_by": "organization_owner"
      },
      {
        "id": "qwen/qwen3-vl-8b",
        "object": "model",
        "owned_by": "organization_owner"
      },
      {
        "id": "google/gemma-3-12b",
        "object": "model",
        "owned_by": "organization_owner"
      },
      {
        "id": "openai/gpt-oss-20b",
        "object": "model",
        "owned_by": "organization_owner"
      },
      {
        "id": "text-embedding-nomic-embed-text-v1.5",
        "object": "model",
        "owned_by": "organization_owner"
      }
    ],
    "object": "list"
  }
  

• I believe using LM Studio's CLI or SDK we can have access to more information about the models. But that'll be provider-specific (like it won't work for Ollama).
• Agree with no extra config option. I tried to still honor the config file because it allows the user to provide a prettier name to the model, and replace the model ID. To achieve this, I put my logic in a early stage of the state initialization, before collecting the auth info. This means that I won't be able to retrieve model list from cloud provider that use @ai-sdk/openai-compatible (they usually require auth). So, I have to introduce a extra config option such that this feature won't cause troubles for cloud providers.
• Agree that the model info from Models.dev should be completely dropped when OpenAI-compatible API is returning the model list. I thought the same way when I drafted this PR.

I wanted to add this as well!
I use some python scripts to generate opencode.json configs from LMStudio/ ollama apis.

LMStudio does have api to fetch each model info with context length etc

Agree that the model info from Models.dev should be completely dropped when OpenAI-compatible API is returning the model list. I thought the same way when I drafted this PR.

It's not like "completely dropped" it should be like any model that exists in models.dev that isnt in models endpoint should be dropped but that doesnt mean drop all the useful metadata it's more to filter potentially unsupported models

LMStudio does have api to fetch each model info with context length etc

Then we should defo use that, wanna do the same for ollama but that can be separate

@rekram1-node I would love to help out on this if possible

Yeah up to yall I'd really like to ship this week so @tomzhu1024 if you aren't going to be available I think @goniz or myself will take care of this.

Ig we can build off this PR easily

It's not like "completely dropped" it should be like any model that exists in models.dev that isnt in models endpoint should be dropped but that doesnt mean drop all the useful metadata it's more to filter potentially unsupported models

Got it. This is definitely the optimal way. Thanks for the clarification!

I was planning to iterate this PR later today -- I'm planning to 1) remove the extra config option, 2) still honor the model info from Models.dev (if they do exist according to the endpoint), 3) leave some space for provider-specific model info retrieval (like @goniz mentioned). I'm a little unsure about expanding this feature to all @ai-sdk/openai-compatible providers, as some of them requires auth and brings some uncertainty (There are many auth methods, and maybe it's not API key...). Any thoughts or suggestions?

But feel free to take it over; just let me know so I can shift to something else.

I'm a little unsure about expanding this feature to all @ai-sdk/openai-compatible providers, as some of them requires auth and brings some uncertainty (There are many auth methods, and maybe it's not API key...). Any thoughts or suggestions?

All the providers should work, I can test and iterate to make sure it works but ik u would use your github token from oauth exchange for copilot, and an api key for zen, etc so i think most things will be pretty standard.

I see. That sounds good. I'll then try to 4) expand it to all @ai-sdk/openai-compatible providers.