LM Studio vs Ollama (Oct 2026): MLX, MCP and Agent Backends

Last month I watched a teammate spend 45 minutes trying to work out why his local LLM wasn't responding. He'd installed LM Studio, downloaded a 70B model, and started chatting. Worked perfectly. Then he tried to connect it to our agent pipeline.

He needed an API endpoint. LM Studio has one, but at the time he was hunting for a toggle in a settings panel rather than typing a command. I opened a terminal, typed ollama pull llama3 then ollama run llama3, pointed the pipeline at localhost:11434/v1/chat/completions, and we were working in under two minutes.

That story is the reason half the internet still says LM Studio can't serve. It's a story about discoverability, not capability - and in 2026 it isn't even a good story about discoverability any more. Both projects have moved, in opposite directions, and almost every "LM Studio vs Ollama" article you'll find is describing a world that no longer exists.

So let's fix that.

What actually changed in 2026

Two things, and they matter more than any tokens-per-second benchmark.

1. LM Studio got a real daemon

LM Studio 0.4.0 landed on 28 January 2026. The headline is llmster, which LM Studio describes as "the core of the LM Studio desktop app, but packaged to be server-native, without reliance on the GUI." You install it with a shell script on Linux and macOS (curl -fsSL https://lmstudio.ai/install.sh | bash) or PowerShell on Windows, and start it with lms daemon up. No desktop environment, no display, no logged-in user.

LM Studio's own docs walk you through running it as a systemd unit on Linux: create /etc/systemd/system/lmstudio.service with ExecStartPre=.../lms daemon up, ExecStart=.../lms server start and ExecStop=.../lms daemon down, then systemctl enable. That is the exact deployment shape people have been recommending Ollama for since 2023. One caveat: the desktop app and llmster manage overlapping runtime resources and are not meant to run on the same machine at the same time. Pick one per machine.

0.4.0 also brought concurrent inference requests to the same model - continuous batching, with a "Max Concurrent Predictions" setting and a unified KV cache that's on by default - replacing the old behaviour where requests queued. And a new stateful /v1/chat REST endpoint that returns a response_id you pass back as previous_response_id, which can also expose your locally configured MCP servers, gated by permission keys. (Parallel requests on the MLX engine were still listed as in progress at release.)

Two corrections to the version history, because the internet has garbled this too: headless mode and JIT model loading are not new in 0.4.0. They shipped in LM Studio 0.3.5 back in October 2024, as "Local LLM Service". And MCP support arrived in 0.3.17 in mid-2025. What 0.4.0 changed is that you no longer need the desktop app installed at all.

Don't confuse any of this with LM Studio Bionic, which launched on 16 July 2026. Bionic is an agent app for open models (coding, documents, optional paid cloud inference), and LM Studio is explicit that it is "a new, separate app from LM Studio." The LM Studio app, lms CLI and llmster daemon compared here carry on alongside it.

2. Ollama stopped being a llama.cpp wrapper

The other half of the old comparison - "they both use llama.cpp, so speed is identical" - is also out of date.

In May 2025, Ollama announced its own engine for multimodal models, built directly on the GGML tensor library rather than on llama.cpp. The post is explicit that Ollama "has so far relied on the ggml-org/llama.cpp project for model support" - past tense - and that the new engine makes each model self-contained with its own projection layer.

Then on 30 March 2026, Ollama went further on Apple hardware: Ollama on Apple Silicon is now built on MLX, previewed in 0.19, to use the unified memory architecture directly. After a pre-release in late September, Ollama 0.40.0 shipped on 6 October 2026 and made MLX the automatic runtime on Apple Silicon for supported architectures. More on that below.

So "same engine, same speed" is no longer a safe assumption. Ollama runs its own GGML-based engine (plus MLX on Macs). LM Studio runs llama.cpp and Apple MLX. Jan runs llama.cpp. If you benchmark, benchmark - don't assume.

What changed in October: Ollama now uses MLX on Macs

Ollama 0.40.0 landed on 6 October 2026. On Apple Silicon, any model whose architecture the MLX runtime supports now runs on MLX automatically. You don't pull a separate -mlx tag or flip a setting. At release that covered:

• qwen3.8
• gemma4
• qwen3.6
• qwen3.5
• decision models
• embeddinggemma-2

Models outside that list keep running on Ollama's GGML-based engine. The current stable release is 0.40.3 (11 October).

This changes one line in the old comparison. "LM Studio has native MLX, Ollama doesn't" was a fair reason to pick LM Studio on a Mac. For the model families above, both runners now use MLX on Apple Silicon. LM Studio's real Mac advantage is back to what it always was: the model browser and the MCP client, not the engine.

LM Studio shipped too. LM Studio 0.4.26 (13 October) added /v1/systemone and /v1/decisions endpoints, CUDA 13 on Windows ARM and llama.cpp runtime 2.50.0. Ollama has served "decision models" through /v1/systemone since 0.35.0 (28 September), and since 0.35.1 those models report only a decision capability, so agent clients won't offer them for tool calls. If you're building an agent, keep using a normal tool-capable chat model as the backend.

On Windows: both LM Studio and OpenClaw are already integrated with Microsoft Execution Containers, which reached general availability on 7 October 2026 and provide policy-driven containment for AI agents.

The "Friends Don't Let Friends Use Ollama" argument

You will run into this piece if you spend any time in local-LLM communities, and it's worth reading before you commit to a stack.

"Friends Don't Let Friends Use Ollama" was published by Zetaphor on Sleeping Robots on 15 April 2026. It is an opinion piece, and an unambiguously hostile one - but its factual spine is checkable, which is why it landed so hard. The argument, in summary:

• Ollama's README went a long time without crediting llama.cpp, and an MIT licence-notice compliance issue sat open for more than 400 days.
• The mid-2025 move to a custom GGML backend reintroduced bugs llama.cpp had already fixed, and the author cites benchmarks showing llama.cpp running roughly 1.8x faster than Ollama on the same hardware.
• Ollama listed DeepSeek's R1 distillations as "DeepSeek-R1", which confused a lot of people about what they were actually running.
• The July 2025 desktop app was developed privately without public source or clear licensing.
• The late-2025 pivot to cloud-hosted models came with unclear data handling, and a token-exfiltration vulnerability (CVE-2025-51471).

The author's recommended alternatives are llama.cpp directly, llamafile, LM Studio, Jan, koboldcpp and ramalama.

My honest read: the licensing and attribution history is a genuine governance criticism and you should weigh it. The performance claim is one benchmark on one configuration, not a law of nature - and Ollama has shipped a lot of engine work since. The model-naming complaint is fair and still worth knowing when you ollama pull anything with a familiar name. None of it means Ollama stops working on your machine tomorrow. It does mean "Ollama is the obvious default" deserves a second look, which is more or less the point of this article.

Where Jan fits

Jan is the third name that keeps coming up, and it earns its place on a different axis.

Jan is a desktop app - chat, models, MCP connectors, and a local API server - released under AGPLv3, so the whole codebase is auditable. It runs models through a built-in llama.cpp engine with no internet connection required, and its local API server is OpenAI-compatible at http://127.0.0.1:1337/v1/chat/completions, with an optional bearer-token API key. You start it from Settings → Local API Server → Start Server.

One thing I need to correct, because we got it wrong in an earlier version of this comparison and so does most of the internet: the telemetry story is not "Jan has none and LM Studio has some." Read the primary sources and it's closer to the reverse of how it's usually told.

• Jan's privacy docs say Jan collects zero data until you opt in, that you choose tracking preferences at first launch, and that analytics are handled by PostHog EU. Chats, chat settings and model choices are never collected either way.
• LM Studio's privacy policy states the app "does not include telemetry or user-specific tracking" and that what little it processes is anonymous and short-lived.

Both are strong positions. The real difference is verifiability: Jan's claim is checkable because the source is AGPLv3, and LM Studio's is a policy you have to take on trust because the app is proprietary. If your compliance reviewer wants to read the code, that distinction is the whole ballgame. If they want a signed policy, it isn't.

The caveat on Jan, unchanged: if your workload leans hard on OpenAI-style function calling, test that path before you commit. Ollama and LM Studio are the better-trodden ground for tool-heavy work.

The comparison table

Every cell here is from primary documentation, re-checked on 28 September 2026 (LM Studio 0.4.25, Ollama 0.34.4, Jan 0.8.4). The inference-engine row was updated on 13 October 2026 for Ollama 0.40.3 and LM Studio 0.4.26.

The row that used to decide this argument - "headless: Ollama yes, LM Studio no" - is now a tie. The rows that actually separate them in 2026 are the Docker image, multi-model routing, concurrency and the MCP client.

So which one do you actually install?

Scenario 1: You're wiring a local model into VS Code, an agent framework, or a RAG pipeline. Still Ollama, but for ecosystem reasons rather than architectural ones. If a project says "works with local models", it almost certainly tested against Ollama first. That self-reinforcing default is worth real money in debugging time. Our full Ollama setup guide walks through wiring it into an agent runtime end to end.

Scenario 2: You're deciding which model to run at all. LM Studio. In-app Hugging Face search, visible quant sizes, parameter sliders, side-by-side comparison. Nothing else is close, and now you don't have to abandon it when you move to serving.

Scenario 3: You're standing up a shared inference node on a GPU server. Ollama is still the smoother path, because its Docker image does GPU on Linux and WSL2 and LM Studio's official container image is an x86 CPU-only technical preview. If you're installing on the metal rather than in a container, llmster plus a systemd unit is now genuinely competitive - and LM Studio's continuous batching means a single loaded model serves concurrent users properly, which on Ollama means raising OLLAMA_NUM_PARALLEL from its default of 1.

Scenario 4: You need to hand a compliance reviewer something they can audit. Jan. AGPLv3, opt-in analytics, no chat collection. If you need the full provider-by-provider picture, we checked 21 providers against their own terms, local runners included.

Scenario 5: You want your local model to use tools over MCP without writing a bridge. LM Studio or Jan. Ollama does tool calling natively in its API, but it isn't an MCP client - you put an MCP-aware orchestrator in front of it. If your models are throwing "does not support tools", that's a per-model capability issue and we mapped it out in Ollama tool-calling support.

Scenario 6: You're routing inference from an agent platform. Any of them - they all speak OpenAI-compatible HTTP. Point the agent's model config at the right port and the calls run on your hardware. This works with any platform that supports custom endpoints, including BetterClaw's BYOK setup. The next section covers what separates them once an agent is the client.

LM Studio vs Ollama as an AI agent backend

I set up a support triage agent last year. Local model, zero API costs, privacy-first: read incoming emails, classify them, route them to the right team. I started with LM Studio, because the GUI is genuinely the nicest way to pick a model. Then I closed the laptop lid and the agent stopped classifying anything at 2am. I moved to Ollama behind a systemd unit and it ran for four weeks without me touching it.

That's the story behind every "use Ollama for agents" article on the internet. It's now the wrong reason to reach that conclusion, because llmster fixed that specific failure at the source. Boot persistence and restart-on-failure are a systemd config question on both sides. Three things actually matter for an agent backend in 2026.

1. Concurrent requests to one model

This is the one people miss, and for a multi-step agent it matters more than uptime.

LM Studio 0.4.0 added continuous batching for concurrent requests to the same model. Before 0.4.0, requests queued. Ollama has had OLLAMA_NUM_PARALLEL for a while, but its default is 1 - and Ollama's FAQ notes that required RAM scales by OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH, so raising it is a memory decision, not a free win. If your agent fans out sub-tasks in parallel, or you're serving more than one agent from one box, set this deliberately on either tool.

2. Model lifecycle and cold starts

Both load on demand and unload when idle, with very different defaults:

• Ollama: models stay in memory for 5 minutes by default, tunable per request with keep_alive (a negative value keeps it loaded indefinitely, 0 unloads immediately). OLLAMA_MAX_LOADED_MODELS defaults to 3 per GPU, so several models can be resident and routed between - classification on a small model, generation on a large one, same host.
• LM Studio: JIT-loaded models have a TTL of 60 minutes by default. Auto-Evict is on by default, which unloads the previously JIT-loaded model before loading a new one - so you effectively get one JIT model at a time until you turn it off. Models loaded explicitly with lms load have no TTL and stay until you unload them.

For a scheduled agent that fires once an hour, Ollama's 5-minute default means a cold load on every run. That's a config line, not a flaw - but it's the single most common "why is my first request so slow" on local agent setups.

3. Tools: native tool calling vs an MCP client

Both expose OpenAI-style tool calling on /v1/chat/completions, and in both cases whether it works depends on the model, not the server. The difference is MCP: LM Studio can hold the MCP connections itself (over the /v1/chat endpoint, gated by permission keys), while Ollama expects your agent framework to translate tool calls into MCP invocations. That's normal and it's what most frameworks already do - but if you want the runner to own the MCP connections, only one of these does that.

One config trap to know first: Ollama's default context window is set by available VRAM - 4K tokens under 24 GiB, 32K at 24-48 GiB, 256K at 48 GiB and up - and Ollama recommends at least 64,000 tokens for agents and coding tools. Past the window it truncates from the front of the prompt while still returning HTTP 200, so on a consumer GPU a long agent system prompt can silently disappear. We wrote up the num_ctx and OLLAMA_CONTEXT_LENGTH fixes. For Docker networking and the /v1 endpoint requirement when connecting Ollama to an agent, see our troubleshooting decision tree.

Use Ollama as the agent backend when: it runs in a GPU container or on Kubernetes; you route between several models on one host; or you want the backend your agent framework's docs were written against.

Use LM Studio as the agent backend when: you want concurrent requests to a single model without a memory-multiplying config change; you want the runner itself to hold MCP connections; or you're deploying on bare metal where llmster plus systemd is as robust as anything else.

What each one still does better

Ollama's remaining moat. One-command model pulls against a curated registry. A GPU-capable official Docker image, which is what makes Kubernetes, CI and edge deployments straightforward. Multiple models loaded at once with OLLAMA_MAX_LOADED_MODELS. And an ecosystem where being the default backend is itself the feature.

LM Studio's remaining moat. The discovery experience, still unmatched. Native Apple MLX (though Ollama now runs MLX too, so this is no longer exclusive - see our notes on Apple Silicon vs NVIDIA). A built-in MCP client, so a local model can use tools with no bridge code. Continuous batching for concurrent requests to one model. And a daemon, which means the tool you explored in is the tool you can deploy.

Jan's remaining moat. Source you can read. That's the whole pitch and it's a good one.

The part nobody mentions: when local isn't the right answer

Here's my honest take after running all three.

Local inference has constraints no runner can fix. For a single chat turn, a slower local response is fine. For an agent chaining 10-15 inference calls per task, latency compounds - a workflow that takes seconds against a hosted API can take minutes on a laptop.

You're also limited to open-weight models. Verified local options are good now: qwen3.8:27b is on Ollama at 18GB with a 256K context window, and Gemma 4 ships at 12B (7.6GB) and 31B (20GB). But there's no local Claude Opus and no local GPT. (For what each tier of hardware can actually run, see our guide to local AI in 2026. For a head-to-head on the strongest local agent models, we compared Gemma 4 and Qwen.)

And the practical gap: an agent that reads your email, checks your CRM, drafts a reply and updates your project board needs more than a model. It needs OAuth connections, persistent memory, tool integrations, error handling, retries and monitoring. Ollama, LM Studio and Jan provide inference. The rest is on you.

The answer for most production agents is hybrid: local for development and privacy-sensitive tasks, a hosted API for the paths that need speed or a frontier model, switched by configuration rather than a rewrite.

That's the gap a managed agent platform fills. We built BetterClaw to handle the infrastructure so you can focus on what the agent does. Connect a cloud API key for speed, or point at your local endpoint for privacy. Free plan with 1 agent and 100 credits a month; Basic is $19/month, and Pro is $49/month for 5 agents. 28+ model providers including local endpoints, zero inference markup. For how that compares to writing the orchestration yourself, our BetterClaw vs CrewAI comparison has the no-code vs code-first breakdown.

The setup I'd actually recommend

Install two of them.

Use LM Studio when you're in discovery mode - trying a new model family, checking whether a 12B is enough before you reach for a 31B, comparing quantisations, tuning parameters. Use Ollama when you're in build mode and you want the backend that every other tool in your stack already expects. Find the model in LM Studio, note the exact tag, pull it on Ollama.

The difference from a year ago is that this is now a preference, not a constraint. If you'd rather stay in one tool, llmster will serve your agent perfectly well on a Linux box. And if what you're optimising for is auditability rather than convenience, Jan does the same job with source you can read.

The tools aren't competing so much as occupying different corners. None of them replaces an agent platform if you want AI that does things beyond answering prompts.

If you're ready to put local inference to work, give BetterClaw a look. Use cloud APIs, your local models, or both: the free BetterClaw desktop app works with Ollama, LM Studio and llama.cpp, and connects them to your agents with no ports to open.

Frequently Asked Questions

What is the difference between LM Studio and Ollama?

Ollama is a CLI-and-API-first local inference server; LM Studio is a desktop app with a model browser, chat UI and parameter sliders that also ships a server. The old distinction - that only Ollama could run without a GUI - ended with LM Studio 0.4.0 in January 2026, which added llmster, a standalone daemon you install and run from the terminal with no desktop app. Both are free on macOS, Windows and Linux. The differences that remain are Ollama's GPU Docker image and multi-model routing versus LM Studio's model browser, built-in MCP client and concurrent requests to a single model.

Is Ollama or LM Studio better for AI agents?

Neither is a blanket winner any more. Before LM Studio 0.4.0 (January 2026), only Ollama could run without a desktop session, which settled the argument. Now both ship a GUI-free daemon with a documented systemd unit. Choose Ollama if your backend runs in a GPU container, if you route between several models on one host, or if you want the backend your agent framework tested against. Choose LM Studio if you need concurrent requests to a single model, or you want the runner itself to act as an MCP client.

Does LM Studio have a headless mode?

Yes, two of them. Since 0.3.5 (October 2024) the desktop app has had a "Local LLM Service" mode that runs the server without the GUI and can start on login. Since 0.4.0 (January 2026) there's llmster, a separate GUI-free daemon for Linux, macOS and Windows, started with lms daemon up. LM Studio documents running it as a systemd service on Linux, and publishes an official lmstudio/llmster-preview Docker image - though that image is a technical preview and is CPU-only on x86. Don't run the desktop app and llmster on the same machine at once.

Which handles concurrent agent requests better?

LM Studio, out of the box. Version 0.4.0 added continuous batching so one loaded model serves concurrent requests, with a Max Concurrent Predictions setting and a unified KV cache on by default. Ollama's OLLAMA_NUM_PARALLEL defaults to 1, and Ollama's own FAQ notes RAM scales by OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH - so raising it is a memory trade you should make deliberately rather than a free upgrade.

Is Ollama faster than LM Studio?

You can't assume either way now. LM Studio and Jan run llama.cpp (LM Studio also runs Apple MLX). Ollama announced its own engine built on the GGML tensor library in May 2025, previewed an MLX engine on Apple Silicon in March 2026, and since 0.40.0 (6 October 2026) runs supported architectures such as qwen3.8, gemma4 and qwen3.5 on MLX automatically on Apple Silicon. Benchmark your model at your quantisation on your hardware; published numbers, including the 1.8x figure cited in "Friends Don't Let Friends Use Ollama", are single configurations.

Can I run Ollama and LM Studio at the same time?

Yes, they default to different ports - 11434 and 1234 - so they won't conflict on the network. The real constraint is memory: two loaded models consume two models' worth of VRAM. The one combination to avoid is LM Studio's desktop app and llmster on the same machine, since they manage overlapping runtime resources.

What is LM Studio Bionic?

A separate app LM Studio launched on 16 July 2026: an AI agent for open models that does coding and document work, with local models or paid open-model inference on LM Studio's cloud. It does not replace LM Studio. The LM Studio app, the lms CLI and the llmster daemon - the parts this comparison covers - continue alongside it.

What is "Friends Don't Let Friends Use Ollama"?

An opinion piece by Zetaphor, published on Sleeping Robots on 15 April 2026, arguing that people should move off Ollama. Its main points are Ollama's slow crediting of llama.cpp and a 400-plus-day MIT licence-notice compliance issue, performance regressions from the custom GGML backend, listing DeepSeek-R1 distillations under the base model's name, a closed-source desktop app, and a cloud pivot with unclear data handling plus CVE-2025-51471. It recommends llama.cpp, llamafile, LM Studio, Jan, koboldcpp and ramalama instead. It's worth reading as a governance critique; treat the benchmark numbers as one configuration rather than a general law.

How do I switch between Ollama, LM Studio and Jan without breaking my setup?

All three expose OpenAI-compatible APIs, so mostly you change the port: Ollama on 11434, LM Studio on 1234, Jan on 1337, each with a /v1 prefix. Download the same model at the same quantisation to keep output comparable, and copy your system prompt and sampling settings over manually, since those live inside each app. Watch two defaults that differ: Ollama unloads an idle model after 5 minutes, LM Studio's JIT TTL is 60 minutes.

Are Ollama, LM Studio and Jan free?

Yes, all three, with no subscriptions or per-token fees. Ollama is MIT-licensed open source. Jan is AGPLv3 open source. LM Studio is proprietary but free, and since July 2025 that includes use at work - the previous commercial-licence requirement was removed. Your only cost is hardware and electricity.

Should I use local inference or a hosted API for agents?

Local is best for development, privacy-sensitive workloads and zero-marginal-cost personal agents. Hosted APIs win on latency across multi-step workflows, on access to frontier models there's no local equivalent for, and on not making you the operator of your own uptime. Most production setups run both - local for development and sensitive tasks, hosted APIs for speed-critical and customer-facing work - switched by configuration rather than by rewriting the agent.