A team builds a support bot on OpenAI’s API, ships it, and moves on.
Then the monthly bill starts hurting, or a customer in a regulated industry asks where their data actually goes, or a faster model shows up from a different provider. The instinct is to brace for a rewrite: a new SDK, a new request format, and new error handling scattered across the codebase. But that rewrite almost never happens. One string changes. That string is the base URL, and most of what makes modern AI infrastructure feel interchangeable comes down to that one line.
Key Takeaways
- A base URL is the root address every API request gets sent to. OpenAI’s default is https://api.openai.com/v1, and most developers never even see it because the SDK sets it automatically.
- “OpenAI-compatible” means another server accepts the same request shape, authentication pattern, and response format, so pointing an SDK at it is a one-line change, not a rewrite.
- Teams override the default for three practical reasons: cutting inference cost, keeping sensitive data on infrastructure they control, and choice of provider.
- Real examples already run this way: Ollama and LM Studio serve local models through their own base URLs, Google’s Gemini accepts standard OpenAI client libraries directly, and developer tools like Cline let a user set one from a settings screen.
- It’s set two ways: a base_url argument passed when the client is created, or the OPENAI_BASE_URL environment variable, though some older libraries still expect a different variable name.
- The same swap that makes switching providers painless for a developer makes it nearly impossible for anyone else, security, finance, or compliance, to see which provider a given call is actually reaching.
What is an OpenAI-compatible base URL?
An OpenAI-compatible base URL is the root endpoint address that an OpenAI SDK, or any tool built to OpenAI’s request format, sends its calls to. By default, that address is https://api.openai.com/v1. When another service implements the same request structure, authentication pattern, and response shape, pointing the client at that address instead is enough. The code that builds the request and reads the response never needs to know the difference.
The default OpenAI base URL vs. a custom one
Every official OpenAI SDK ships with https://api.openai.com/v1 baked in as the default, confirmed in OpenAI’s own API reference, so a standard integration never has to think about it. The moment a base_url is supplied explicitly, every request the client would have sent to OpenAI (chat completions, embeddings, model listings) goes there instead, with the same payload. Only the destination changes.
Why the /v1 pattern matters
That trailing /v1 isn’t decoration. It’s a versioned contract: the routes underneath it (/chat/completions, /embeddings, /models) and the JSON going in and out have to match what the client expects. A server that merely accepts text and returns text isn’t OpenAI-compatible in any useful sense. Compatibility means the same code, calling the same method with the same parameters, works without modification, exactly what OpenAI’s own Python SDK repository documents about the base_url argument.
Examples of OpenAI-compatible base URLs
The definition is abstract until you see where it points. A few real ones, confirmed against each provider’s own documentation:
| Where it routes | Base URL | Source |
| OpenAI’s own servers (the default) | https://api.openai.com/v1 | OpenAI |
| A local model served by Ollama | http://localhost:11434/v1 | Ollama |
| A local model served by LM Studio | http://localhost:1234/v1 | LM Studio |
| Google’s Gemini models | https://generativelanguage.googleapis.com/v1beta/openai/ | Google AI for Developers |
Two of those run on the same machine as the application calling them, the whole appeal for a team that can’t let data leave its own infrastructure. The other two are cloud endpoints, reached exactly the way a request to api.openai.com would be.
The same trick isn’t limited to backend services and chatbots. Developer tools use it too: Cline, the AI coding agent extension, lets a developer pick “OpenAI Compatible” as a provider and fill in three fields: base URL, API key, and model ID. Cline then talks to whatever sits behind that URL exactly as it would talk to OpenAI, the same base_url mechanic from OpenAI’s own SDK repository, exposed through a settings screen instead of a line of code.
Why the OpenAI-compatible base URL matters
The obvious benefit is that switching providers doesn’t force a rewrite. Google makes this almost a selling point. Google’s own developer document walks through pointing the OpenAI Python client at Gemini using nothing more than an API key, a base URL, and a model name.
That claim holds up. What doesn’t always hold up is the assumption that every OpenAI-compatible endpoint behaves identically past the basics: function-calling schemas, streaming behavior, and how a server handles an unsupported parameter can all vary, even when the base request format matches. “Compatible” does not mean “interchangeable” in every detail, and teams that assume otherwise find it out at an inconvenient moment.
Where the pattern earns its keep is cost and control. Running inference locally through Ollama or LM Studio means a document never leaves the machine it started on, which matters to a legal team, a hospital, or a bank. Routing to a different cloud provider for the same model class can mean a materially lower bill without touching a line of application code. The same mechanism that lets a support bot swap backends is what lets a developer inside a coding agent pick a different underlying model without rewriting the tool itself.
How to set an OpenAI-compatible base URL
There are two ways to do it, and most tools support both.
In the SDK client
The most direct way is passing a base_url argument when the client object is created, right alongside the API key. From that point on, every request that client sends goes to the specified address instead of OpenAI’s own, as per OpenAI’s own Python client documentation.
As an environment variable
The current official variable, as per the same repository, is OPENAI_BASE_URL. Set it once in the environment and any OpenAI SDK that reads it picks up the new address automatically, without touching a line of code.
Worth knowing before debugging a config that “isn’t working”: some other libraries still read the older OPENAI_API_BASE name instead, a holdover from earlier SDK conventions. The two aren’t interchangeable everywhere, so check which one a specific library actually expects rather than assuming.
Governance blind spot this flexibility creates
None of this shows up on a spend dashboard or a security review. A request routed through a custom base URL still looks, from the application’s point of view, like a normal call to a chat completions endpoint. What actually changed, the destination, is invisible unless someone reads the code or inspects network traffic directly.
That gap isn’t hypothetical. IBM’s 2025 Cost of a Data Breach Report found that 63% of organizations have no AI governance policy at all, and where a high level of unsanctioned “shadow AI” was present, breaches cost $670,000 more on average. Among organizations already hit by an AI-related security incident, 97% lacked proper AI access controls.
Scale makes the problem worse. Gartner projects that a typical Fortune 500 company will run more than 150,000 AI agents by 2028, up from fewer than 15 in 2025, and only 13% of organizations currently believe their own agent governance is adequate. A single repointed base URL looks small next to numbers like that. It’s also exactly the kind of small, well-intentioned change that adds up to them, one integration at a time, with nobody outside the engineer who made it any wiser.
If you don’t currently know how many of your organization’s AI calls are actually reaching an approved destination, Lyzr’s AI agent sprawl audit is a reasonable place to find out before it turns into a line item in a report like IBM’s.
How Lyzr OpenController closes the gap
Lyzr OpenController exists because of exactly this gap: a base URL swap happens inside application code, below anything that tracks spend or usage by model name, so it stays invisible to everyone except the person who typed it.
Opencontroller’s control runs on four capabilities. Find discovers agents, models, tools, and workflows across the environment, including ones pointed at endpoints nobody explicitly reviewed. Ship evaluates and validates a provider or endpoint before it’s allowed into a live workflow. Run enforces that decision in the request path itself, in real time, rather than after the fact in a log. Improve turns what actually happened, cost, performance, and security signals alike, into the next round of policy. Every decision stays attributable and traceable.
None of that requires giving up the flexibility that made OpenAI-compatible routing worth adopting in the first place. It just means someone can answer, with a straight face, exactly where every one of those requests is actually going. If that’s a question your team can’t currently answer, booking a demo is a reasonable next step.
FAQ
The default is https://api.openai.com/v1. Every official OpenAI SDK uses this automatically unless a different base_url or environment variable is set, as per OpenAI’s own API reference.
It’s the root web address an API client sends requests to, before appending specific paths like /chat/completions or /models. Changing it redirects every request to a different server, without changing how those requests are built.
https://api.openai.com/v1 is OpenAI’s own. A local model served through Ollama uses http://localhost:11434/v1, and one served through LM Studio uses http://localhost:1234/v1, per each tool’s own docs.
It means a service implements the same request format, authentication pattern, and response structure as OpenAI’s API, so an existing SDK can call it by changing only the base URL and model name; no other code changes are required.
Google’s Gemini models are reachable at https://generativelanguage.googleapis.com/v1beta/openai/ using standard OpenAI client libraries, per Google’s own developer docs.
Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here
