Short answer: Ollama and LM Studio both run an OpenAI-compatible server on your machine: http://localhost:11434/v1 for Ollama and http://localhost:1234/v1 for LM Studio. Point a chat app's custom OpenAI-compatible connection at either URL, use any non-empty string as the API key for Ollama, and your pulled models show up in the app. Two things break most attempts: a cloud-hosted app cannot reach your localhost without a tunnel, and Ollama serves models at a default context length far below what the model can handle unless you set num_ctx yourself.

Local models used to mean a separate app and a separate history. Both runtimes now expose the same API shape the hosted providers use, so running one locally is a connection setting, not a second tool to learn.

This guide covers the endpoint details the docs bury, the failures behind most broken setups, and an honest cost comparison.

1. Start the local server

Ollama. Install it, then pull a model and make sure the server is running:

ollama pull gpt-oss:20b
ollama serve          # the desktop app already runs this for you

The OpenAI-compatible API lives on port 11434. Ollama's examples use gpt-oss:20b, qwen3:8b, and the vision model qwen3-vl:8b.

LM Studio. Load a model, open the Developer tab, and start the server. The default port is 1234, and the app prints the base URL to use (http://localhost:1234/v1).

Both serve the same three endpoints you need: list models, chat completions, and streaming chat completions.

2. The OpenAI-compatible endpoint: what each server supports

This is where the two runtimes differ, and where the docs are worth reading before you file a bug against your chat app.

Feature	Ollama (`:11434`)	LM Studio (`:1234`)
`/v1/chat/completions`	yes (streaming, JSON mode, seed, logprobs)	yes, text and images
`/v1/completions`	yes	yes
`/v1/models`	yes	yes
`/v1/embeddings`	yes	yes
`/v1/responses`	yes, non-stateful (added in v0.13.3)	yes
Vision input	base64 images only	base64 and image URLs
Tool calling	yes	yes
Reasoning control	`reasoning_effort`: high, medium, low, max, none	varies by model
Stateful responses	not supported	not supported by the OpenAI spec here
Default base URL	`http://localhost:11434/v1`	`http://localhost:1234/v1`
API key	any string, ignored by the server	any string

Two rows deserve a second look.

Ollama's /v1/responses support is the non-stateful flavor. Requests that reference a previous response with previous_response_id or conversation will not work, so an app built around the stateful Responses API needs the chat completions path instead.

Ollama ignores the API key, but the field is not optional in most clients. The OpenAI SDKs refuse to send a request without one, so a placeholder like ollama is standard practice. LM Studio behaves the same way.

3. Add the endpoint to your chat app

In a chat app that supports custom OpenAI-compatible providers, this is three fields:

Field	What to enter
Base URL	`http://localhost:11434/v1` (Ollama) or `http://localhost:1234/v1` (LM Studio)
API key	`ollama` or any placeholder string
Model	the model tag you pulled, for example `gpt-oss:20b`

Save it, then switch the conversation to that model. Multimodel Chat's custom endpoint setup guide walks through the same three steps for its connection form, and the mechanics of this API shape are covered in what an OpenAI-compatible API actually is.

Two wrinkles you will meet:

Some apps only accept official OpenAI model names. Ollama handles this with a local alias: ollama cp llama3.2 gpt-3.5-turbo creates a model name the app recognises, backed by the model you actually want.

Your model list may come back empty. That usually means the app called /v1/models and got nothing, either because no model is loaded (LM Studio) or the server is not running. Type the model tag into the app by hand and it will still work.

4. Fix CORS, context size, and the localhost problem

CORS. Browsers block cross-origin requests to localhost by default, and the fix is an environment variable on the server rather than a setting in your app. Ollama reads OLLAMA_ORIGINS. Its FAQ notes that browser extensions are their own origins: allowing all extensions means including chrome-extension://*, moz-extension://*, and safari-web-extension://*. The server must be restarted after the variable changes, which is why people set it, see the same error, and conclude the fix does not work.

Context size. This is the one that quietly ruins long chats. The OpenAI API has no field for context length, so Ollama uses the model default, which is often far below what the model can handle. The documented fix is a Modelfile:

# Modelfile
FROM gpt-oss:20b
PARAMETER num_ctx 32768

Then ollama create mymodel and call mymodel from your app. LM Studio exposes the context length as a load-time setting instead, and it costs VRAM: a bigger window means more memory per conversation.

The localhost problem. A hosted chat app runs on someone else's server, so localhost points at that server, not your desk. Connecting a local model to a hosted app means exposing the port through a tunnel and pasting the public URL. That works, and it turns your machine into an internet-reachable API, so use a tunnel that supports authentication and remember the model is only up when your machine is.

What local models cost (and what they don't)

Local inference has no per-token price, so the honest comparison is electricity and hardware against provider rates. Using 150 watts for two hours a day at $0.17 per kWh, that is roughly $1.55 a month in power:

Usage level	Local (power only)	GPT-5.6 Sol	GPT-5.6 Luna	DeepSeek V4.1 Flash
~500K tokens/month	~$1.55	$5.20	$0.30	$0.16
~5M tokens/month	~$1.55	$52.00	$3.00	$1.65
~20M tokens/month	~$1.55	$208.00	$12.00	$6.60

Hosted figures use published rates ($4/$20 for Sol, $0.20/$1.20 for Luna, $0.15/$0.60 for DeepSeek V4.1 Flash) with a 60/40 input/output split. The power figure is an assumption, not a measurement: adjust the wattage and your electricity price and the number moves.

The table makes an uncomfortable point. Against a cheap hosted model, local inference never pays for itself in dollars: DeepSeek V4.1 Flash at 20M tokens a month costs $6.60, so a $2,000 machine would take about 25 years to break even on power alone. Local wins on heavy frontier-model usage instead. At 20M tokens a month on Sol, $208, a $2,000 machine pays itself off in about ten months.

So the reason to run local models is privacy, offline access, and models that are not sold as an API at all. Cost is a side effect, not the argument.

What You Give Up with Local Models

Quality. A 20B open-weight model is not a frontier model. For writing, hard reasoning, and long multi-file work the gap is visible, and it shows up exactly where mistakes are expensive.

Context. The window is bounded by your memory, not by what the model advertises. A quantized 20B model with a 32K window on a laptop is realistic; 1M tokens is not.

Your machine is the uptime. No server, no model. Sleep, reboot, and a closed laptop lid all count as downtime, and a tunnel adds a public surface you now have to think about.

The ecosystem. No app-funded web search, no hosted file handling, and no cross-device history unless you build the sync yourself. Your chat app can connect to a local model, but it cannot lend it cloud features.

Maintenance. Model pulls, runtime updates, quantization choices, and the occasional broken Metal or CUDA build. Small, but it never fully goes away.

Which Setup Fits You?

If you	Use
Want models to keep working offline, on your own hardware	Ollama locally
Prefer a desktop UI plus an API for other apps	LM Studio locally
Want one workspace for local and hosted models	A chat app with a custom OpenAI-compatible connection
Need the cheapest tokens at high volume, and do not mind remote inference	Hosted rates, not local hardware
Work with sensitive text and cannot send it out	Local models, or a hosted provider with a residency option

FAQ

Can I use Ollama with any OpenAI-compatible app?

Yes. Any app that lets you set a base URL can talk to Ollama at http://localhost:11434/v1, as long as it uses chat completions, completions, embeddings, or the non-stateful Responses API. Apps that require stateful Responses calls need a different path.

What API key do I use for a local model?

Any string. Ollama ignores the key entirely but the field is required by most clients, so ollama or local is the usual filler.

Why does my local model forget the beginning of a long conversation?

Almost always the context window. Ollama uses a modest default, and the documented way to change it is a Modelfile with PARAMETER num_ctx, followed by ollama create. Raising it costs memory, so pick a number your machine can actually hold.

Can a hosted chat app connect to a local model?

Only if the app can reach your machine. Since a hosted app resolves localhost to its own server, you have to expose the port through an authenticated tunnel and paste the public URL. If the app runs on your own computer, localhost works directly.

Is running models locally cheaper than using an API?

Not usually, and the money is not the reason to do it. Power costs about $1.55 a month, but cheap hosted models still cost less at light and moderate volume, and the hardware buy-in takes years to recoup even against $200-a-month frontier usage. Local earns its place on privacy, offline access, and models that have no API at all.

One workspace for local endpoints, OpenAI, Anthropic, Google, xAI, and OpenRouter. Bring your own key and point a custom connection at your own server; the workspace is $4/month or $39 once and providers bill you directly. If you are adding a hosted provider next, how to use an OpenRouter key in a chat app covers the same three-field flow, and whether it is safe to give an AI app your key covers what the app can do with a credential once you paste it.

Start your free trial → — 7 days, all providers, no credit card required.

Connect Ollama & LM Studio to Any Chat App (2026)