Using any OpenAI-compatible model provider in Xcode 26

Xcode 26's Coding Intelligence isn't limited to the providers Apple ships with it. You can point it at any OpenAI-compatible endpoint — a hosted API, or a model running on your own machine. The setup takes about a minute, and there are two quirks that will make your first attempt fail.

Where the setting lives

Xcode → Settings → Intelligence → Add a Model Provider. You get two options: Internet Hosted for a remote API, and Locally Hosted for something running on your machine, such as Ollama or LM Studio.

Pick Internet Hosted and you're asked for a URL, an API key and a description. That's the whole form, which is exactly why the two quirks below are so easy to trip over: there is nowhere for the UI to warn you.

Quirk one: leave off the /v1

Almost every OpenAI-compatible provider documents a base URL that ends in /v1. That is what you paste into an SDK, into Cline, into Continue. It is not what you paste into Xcode.

Xcode appends the version segment itself. Give it a URL ending in /v1 and your requests go to /v1/v1/chat/completions, which every provider will answer with a 404. Nothing in the interface tells you this; you just get a model that never responds.

If you're debugging a provider that returns a helpful body rather than a bare 404, this is easy to confirm — the error will name a path with the version segment twice.

Quirk two: no Bearer prefix on the key

HTTP authorisation headers look like Authorization: Bearer sk-…, and if you've been working with curl all day it's natural to type the prefix into the key field.

Xcode adds it for you. Type it yourself and the header goes out as Bearer Bearer sk-…, and you get a 401 that looks exactly like a bad key — which sends most people off regenerating credentials that were fine all along.

Paste the key alone.

The settings, together

Running a local model instead

Choose Locally Hosted and point Xcode at whatever is serving on your machine — Ollama's OpenAI-compatible endpoint on localhost:11434, or LM Studio's server. No key is needed, and nothing leaves the machine, which matters if you're under an NDA that makes pasting client code into a remote API a conversation you'd rather not have.

The trade is the obvious one: a model small enough to run on a laptop is not a model that will reason well across a large Swift project. It's a reasonable fit for completions and a poor one for agentic refactors.

Checking that it works

Before wiring anything into Xcode, confirm the endpoint answers. A GET on the models list is the cheapest test, and note that here you do use the full base URL with /v1 — the truncation is Xcode's quirk, not the provider's:

curl https://api.example.com/v1/models \
  -H "Authorization: Bearer $YOUR_KEY"

A JSON list of model IDs means the key and the host are good, and anything that fails afterwards is Xcode configuration. A 401 means the key; a 404 means the path.

Why bother

Two reasons, in practice. The first is cost: Coding Intelligence is used in a loop — describe, look, adjust, look again — and on a metered API each of those turns resends the file and the conversation so far. The second is where your code goes. Choosing the provider means choosing the jurisdiction, the retention policy and whether your prompts can end up as training data.