Home / Library / Articles / Runner shootouts
Shootout
llama.cpp vs LM Studio: the two ends of the spectrum
This is the widest gap in the series. LM Studio is a polished desktop app that holds your hand from download to first message. llama.cpp is the bare engine underneath half this ecosystem, flags and all. Funny thing though... they run the SAME models at the same speed.
The one-line version
LM Studio: install an app, browse models like an app store, click the one your machine can handle, play. llama.cpp: fetch or build a server, manage your own GGUF files, choose your own flags, and hold the keys to EVERYTHING. Opposite ends of the same road.
The boring truth: they both do the job
Strip the packaging and the gap nearly vanishes. LM Studio runs models using
the same inference technology llama.cpp pioneered, so the same GGUF on the same
GPU generates at roughly the same speed. Both serve an OpenAI-compatible API on
localhost, and both connect to mi·do·na the same way: pick the runner in the
connection panel, point it at the /v1 endpoint, done.
The choice is about how much of the machine you want to touch... not what the machine can do.
Side by side
| llama.cpp | LM Studio | |
|---|---|---|
| Interface | Command line | Desktop GUI |
| Install | Homebrew, binary, or build | Installer |
| Getting a model | Manual GGUF or -hf | Built-in model browser |
| Default port | 8080 | 1234 |
| OpenAI-compatible API | Yes | Yes |
| Browser access (CORS) | On by default | Toggle in settings |
| Hardware guidance | You know your hardware | Flags what your machine can run |
| Sampler control | Everything, first | The standard set |
| Best for | Maximum control | Easiest first start |
The first night
LM Studio is the gentlest on-ramp in local AI, full stop. The built-in browser searches models, shows quantization options, and flags which ones your RAM and GPU can actually hold... which neutralizes the most common beginner failure before it happens. You will be talking to a model in minutes, without learning a single new word.
llama.cpp assumes you've done this before. Get a binary or build one, find
a GGUF (or pass -hf and let it fetch), start
llama-server with your flags. None of it is hard for someone
comfortable in a terminal. All of it is homework for someone who isn't.
The long haul
Here's where the order flips. Once running, llama.cpp is the lower-friction mi·do·na backend: permissive CORS is on by default, so the browser reaches it with no settings safari. It's scriptable, it starts at boot if you tell it to, and updates land here before anywhere else... new samplers, new model architectures, new tricks, day one.
LM Studio wants to be an open app. The server runs while the app runs, and browser access needs the CORS toggle flipped once in settings. Its sampler set covers the standards (temperature, top-p, and friends) but not the exotic tail that llama.cpp exposes. For most players that tail never matters... mi·do·na's Imagination dial speaks to both runners just fine. For prose tinkerers, it's the whole game.
The verdict
Pick LM Studio if this is your first local model, or you simply want software that behaves like software. The guided model browser is worth it all by itself.
Pick llama.cpp if the terminal is home. Zero-config browser access, every knob that exists, and the fastest path to whatever the ecosystem ships next.
Honestly? Plenty of people start on LM Studio and graduate to llama.cpp later... and mi·do·na doesn't care which one is underneath. Ports and defaults reflect each project's documentation as of July 2026. Check the official docs if a release has moved since.
You bring the model. mi·do·na brings the story.
Either runner plugs straight into mi·do·na, right in your browser. Nothing you write ever leaves your machine.