Supporting specific, common providers

[JasonTheAdams]

During the AI Chat in Slack, we discussed two questions surrounding support for specific providers (e.g. Google, Anthropic):

1. Which providers should be supported as part of the project and how do we determine that?
2. Where should the modules for said providers live?

It was proposed that we consider Google, Anthropic, and OpenAI. The criteria was mostly popularity, though there was admitted not to be much hard data around that.

As to where, @felixarntz laid out three possible scenarios (quoting from Slack):

• No providers are bundled, and all providers are separate packages.
• All providers are bundled, and there are clear requirements that a provider needs to meet to be considered.
• Only providers that meet a set of clear requirements are bundled, while other providers may live in separate packages.

Creating this issue so we can continue the discussion!

[Jameswlepage]

The criteria was mostly popularity, though there was admitted not to be much hard data around that.

I don't think we'll really get hard data for this outside of OpenRouter popularity. I think it's okay to start off with "the big three" and then grow from there.

Only providers that meet a set of clear requirements are bundled, while other providers may live in separate packages.

This to me sounds like a happy medium. We have the core providers starting with the big three bundled and then the remainder easily extensible so folks can use whatever makes sense to them.

I'll also note that OpenAI is a relatively well used pattern from other providers (ie DeepSeek). Even Google and Anthropic support the OpenAI API spec.

[felixarntz]

Let's continue this discussion to make a long-term decision, but just chiming in here in regards to the MVP (also see #8 and #20):

• I think for the MVP we can go with implementing "the big three" providers and putting them right into the SDK. This will keep things simple for the initial implementation, where it's most important to have the provider code and the API it's based on close together.
• I envision the MVP getting a version like 0.1.0 (i.e. not 1.0.0), so it is okay if we later decided to remove them from the SDK and have them in separate packages instead.

[JasonTheAdams]

I'm down with "the big three". I think we may find ourselves pulling those out into separate packages/plugins sooner than later because their SDKs require a version of PHP higher than we want.

[justlevine]

Been rethinking the "big three" approach after a talk with some junior engineers I work with and a few freelance "hobbyists" i know, and the implications if the models we're starting with / offering "officially" are all pay-to-play.

I think it's important we launch with support for a self-hosted model. I'm happy to own this task if that's what it takes.
(I've personally never self-hosted so even if I'm doing it I'd love consensus on which to choose .)

[JasonTheAdams]

From my vantage point the "big three" is more about providing a common way for folks to test this out once we start releasing things in the experimental plugin. From there, some folks may choose to use them, while others (perhaps like yourself) will want to go about it in a more advanced way. The majority of the WP market, however, will ideally use it as part of their hosting, having no concept what models are or how to connect one.

All that to say, I think you're more than welcome to ultimately add a module for self-hosted models! That would be cool!

[justlevine]

@JasonTheAdams yes that was my original thinking too until it was pointed out that those models are due for another price hike that will likely coincide with launch (assuming the 6.9 target), and there's not much easier way to test AI than having you(/r host) run a docker compose up -d, especially considering the demographic ( as I understand it: developers composer requireing this lib or npm run plugin-zipping one of the experiments).

The majority of the WP market, however, will ideally use it as part of their hosting, having no concept what models are or how to connect one.

Agreed but I think I'm missing the relevance here? I understood us to be talking about what providers to "bundle" (official package vs plugin notwithstanding), so the demographic we're discussing isn't end users it's:

• hosts (who are the primary use case for self-hosting)
• developers building those last mile experiences for End Users (who are historically price sensitive and scared of usage-based anything - especially in the current economy.)

Like I said I'm happy to handle this if the concern is effort, but I'm raising this here because I think there is both strategic value to making it an official part of the roadmap, as well as a strong reflection of WordPress/FOSS ethos and the democratization of the web

[chubes4]

All providers are bundled, and there are clear requirements that a provider needs to meet to be considered.

To me, bundling support for as many providers as possible from the start makes sense. When you look at an open source project like Roo Code, they support a ton of different providers. You can choose any model you want, but that doesn't guarantee all the features will work.

When I think about who will actually be using this client, it’s going to be developers. If we’re not enforcing any UI constraints or providing strict functionality beyond a drop-in backend, I think we should favor flexibility: support as many providers/models as possible, and let developers decide what’s right for their use case.

Developers will know which provider(s) they want to use. And if they want to provide flexibility to end users, we should leave it up to the devs to filter the list, but make it easy to do so. For example, by building in a filter that accepts model and provider parameters.

This is also relevant to the discussion in Issue #4.

By taking this approach, we may not even need to track provider metadata internally. The plugin or integration developer could handle that based on their use case. The client could simply fetch all available models dynamically from each provider, and fail gracefully when certain features (e.g., function calling) aren't supported.

This could also include support for a local model. Only the most advanced users will want to use that at first, but it will likely become more popular over time.

Only providers that meet a set of clear requirements are bundled, while other providers may live in separate packages.

I think this third point would be a great way to set a standard for which providers are added. For example, having at least one flagship model that supports:

1. Stable API
2. Reponses
3. Streaming
4. Continuation
5. Function Calling

...would allow us to offer both advanced agentic use cases and simple chatbot integrations, depending on what the developer is building.

Happy to be part of this discussion, and hope to contribute!

[Jameswlepage]

Something to consider is that OpenAI's API shape is almost a standard in and of itself. Many providers already support it, including OLLAMA and LMStudio, two of the easiest ways to self-host and run OSS models. It may be a matter of documenting that this is supported or having another provider that is almost a duplicate of the OpenAI one, but intended for the self-hosted crowd.

Additionally, I can see future work that isn't a part of this core project, looking at how Transformers PHP could be leveraged.