Built-in and custom model providers

[ksze]

Continue.dev has a built-in list of supported model providers (deepseek, openai, etc.) for whom some properties Continue.dev knows by default.

However, there are two issues:

• The full list of providers with built-in support is not in the documentation. I had to clone the git repo and dive into the code to tell which providers have built-in support.
• New inference providers pop up on the market every few weeks, but there's no clear pathway to cleanly add custom providers short of modifying the Continue.dev code base and creating a PR. E.g., I want to add GLM 4.6 from Z.ai, but Z.ai is not one of the built-in providers. I could specify the provider as "openai" and then override the apiBase with Z.ai's API base URL, but that's dirty because if I then publish the model config to hub.continue.dev, it shows the model as coming from openai when it really doesn't. I wish you would have a way to explicitly specify OpenAI-compatible or Anthropic-compatible as a separate property from the provider's actual name

[Mte90]

I see here a list https://docs.continue.dev/customize/model-providers/overview but is not possible to use a custom one specifying the host as example.

I see here for a custom host https://docs.continue.dev/customize/model-providers/top-level/openai

[bdougie]

@ksze we did this for Tetrate recently. There are many providers and it is not possible for us to add all of them, but we welcome contributions from contributors if they have a need for one we don't already support.

My suggestion is opening a PR and we can go from there.

#7136
#7736

[Mte90]

It is not more simple to add a way to define the host (that is compatible with openai)?
Because with alternative providers it is just needed that and nothing else.

[Patrick-Erichsen]

@ksze is this your primary concern?

If I then publish the model config to hub.continue.dev, it shows the model as coming from openai when it really doesn't

If so then I think that's definitely something we can solve on the Hub.

As for the actual codebase though, we try to be permissive when allowing providers to add support in the extension but generally leave it up to the provider to update our docs for their service.