Allow custom base url for OpenAI compatible endpoints (other providers)

[johnnyasantoss]

Describe the feature

I would like to use other providers that have a OpenAI compatible endpoint. Changing the base url would suffice (I believe)

Use cases

With this I could test other providers for LLMs with better privacy, throughput or latency

Anything else?

No response

[mitrokun]

There are many custom components that allow you to use third-party endpoints. However, maintaining functionality can be problematic, as providers may have differences in request formats. The AI_task functionality adds additional complexity.
The best option is to create specialized integrations (such as openrouter) that strictly follow the documentation.

[mik-laj]

AWS S3 has a similar situation where users want to leverage these integrations with other S3-compatible services.
Here is final response from development team:
home-assistant/core#144518 (comment)

[mik-laj]

Here is community discussion on forum about this problem: https://community.home-assistant.io/t/wth-there-is-not-a-conversation-integration-that-let-you-use-any-openai-compatible-api/803855/7

[mitrokun]

I can modestly promote my fork of the fork. I made it for myself to work with Mistral, but I also tested it on all popular providers. So far, it works without any problems, tool calls and streaming responses are supported. Everything runs on the OpenAI system library.
https://github.com/mitrokun/openai-compatible-conversation
AI_task was not added, as text data processing is not particularly necessary, and image processing may vary between different providers. However, everyone can modify the component to suit their needs.

It is also worth paying attention to https://github.com/michelle-avery/custom-conversation
extended_openai_conversation still doesn't have streaming output.
A search on GitHub will also show many conversation agents, for example, for grok, azure, n8n...

[geryduyck]

I hear the feedback, but would still disagree. Being able to change the base url is a feature the official open python package supports.
It could be done for all sorts of reasons, like using an openAI proxy API. that's why I would insist on having at least the (advanced) option to change the base url. if only to uphold the open philosophy of HA, as a user, you should always have the choice. The only bad option is not having any option at all.

I did forked the openAI component myself, added the parameter, but that's not sustainable, as I do not wish to follow up on every new development.

[GeoMaciolek]

I agree with other folks here: the OpenAI API format has become the defacto industry standard. Home Assistant is one of the first things I've run into recently that doesn't support custom OpenAI endpoints.

It's A Standard (Evidence)

Some examples of common tools that allow you to change the API endpoint (with links to the specific documentation of the feature):

• OpenAI's Own Codex Tool (60k GH stars)
  • In their own docs, they explain how to set up "custom model providers" with OPENAI_BASE_URL
• VSCode's Copilot Functionality
• Open-WebUI (124k)
• Cline (58k)
• Roo Code (22k)
• OpenClaw (197k)
• Crush (20k)

Also, tools like [Speaches.ai(https://speaches.ai/) (3k) and the widely usedLiteLLM (36k GH Stars) are themselves proxies that implement the OpenAI Standard, to allow broader interoperability for clients that only support the OpenAI standard (but that do support custom URLs.)

It might not have been as clear in mid/late 2025 that the OpenAI API standard was going to be implemented as widely as it has been, but it's pretty clear now; there's an entire ecosystem of stuff using this. (It's akin to many things that support "Cloud Storage" letting you use "Amazon S3 but with a custom URL.")

Compatibility Concerns

There's a risk of compatibility issues, but they're ultimately the responsibility of the API being called, or the person going out of their way to add a custom endpoint. And, the risk of opt-in compatibility issues seemed worth it for the companies above and many more.

OpenAI actively publishes details of the standard, notifying developers in advance of changes - relevant for both people using the API as a client, and also for those reimplementing on their own LLM platform.