The model browser, and the problem it actually solves
You search Hugging Face from inside the app, and each model lists its available quantisations with an indication of whether a given file will fit your machine’s memory.
That guidance matters more than it sounds. Choosing a quantisation is where first-time users most often fail — they download a file too large to load, or a 2-bit version that produces poor output and conclude local models are useless. Both are avoidable and neither is obvious without help.
The naming is opaque until explained: a file marked Q4_K_M is 4 bits per weight, K-quant method, medium variant. Practically, Q5_K_M and Q4_K_M are the usual sweet spots; Q6 and Q8 are better if memory allows; Q3 and below degrade visibly, and a smaller model at Q4 usually beats a larger one at Q2.
Running a model, and the settings worth touching
Downloaded models run in a chat window with the parameters that actually matter exposed as controls rather than flags.
Context length is the one to understand. It sets how much conversation the model retains, and it consumes memory — often as much as the model itself at long settings. A model that loads fine at 4k context may fail part-way through a session at 32k, which is the most common cause of a crash that appears unprovoked.
GPU offload controls how many layers move to the graphics card. Finding the highest value that loads is normal practice, and partial offload is genuinely useful — a card with insufficient VRAM still contributes rather than being unusable.
Temperature, top-p and the system prompt are exposed conventionally.
The local server, which is why developers use it
LM Studio can serve any loaded model over an OpenAI-compatible HTTP endpoint on localhost. Applications written against the OpenAI SDK are repointed by changing a base URL and supplying any non-empty key.
This is the half of the product that turns it from a consumer app into a development tool. Prototyping against a local endpoint costs nothing per request, works offline, and sends nothing anywhere — which makes it a reasonable first step before deciding whether to deploy a model properly with vLLM.
The compatibility is close rather than exact, so an application relying on less common parameters needs testing rather than assuming.
What your hardware needs to be
- Windows, macOS or Linux, 64-bit. Apple silicon is well supported and benefits from Metal acceleration without configuration.
- RAM is the real constraint. 8 GB runs small models awkwardly; 16 GB is a comfortable working minimum; 32 GB opens up mid-sized models at usable context lengths.
- Disk space in the tens of gigabytes if you keep several models — individual files run from roughly 2 GB to well over 20 GB.
- A GPU is optional. Without one, inference runs on the CPU at roughly reading speed.
On that last point, a measured figure rather than an impression: we recorded 23 tokens per second on a mid-range desktop with no graphics card. A desktop wrapper does not change that arithmetic — the engine underneath is the same, and speed is a hardware fact.
The licence question people miss
LM Studio the application is proprietary, not open source, although free to download. The models it runs are open-weights; the software around them is not.
If your reason for going local is data privacy, that distinction is irrelevant — conversations stay on your machine either way. If your reason is auditability of the whole stack, it matters, and Jan is the open-source equivalent.
Commercial and workplace use is governed by LM Studio’s own terms, which have differed for business use at various points. Check them if you are deploying it across a team rather than using it personally.
Where it fits
People who want local AI without a terminal: writers, analysts, researchers and students working with material they would rather not send to a hosted service, and anyone needing an assistant that works offline.
Developers prototyping against a local endpoint before committing to a deployment.
Model evaluation, where it is genuinely strong — comparing four models on the same prompt is a few clicks here, against four pulls and four sessions elsewhere.
It is a poor fit for headless servers, for scripting, and for anyone whose workflow is a terminal already.
What the interface buys you
- No terminal at any point — install, download, run, serve.
- Guidance on what will fit, which removes the commonest first-time failure.
- Easy model comparison, because switching is a menu rather than a command.
- An OpenAI-compatible local server with nothing extra to install.
- Nothing leaves the machine, and no account is required for local models.
- Exposed context and offload settings, which are the two that decide whether a model runs well.
The drawbacks
- Closed source. Free, but not inspectable, and its terms govern workplace use.
- Speed is hardware, not software. CPU-only means reading speed, whatever the interface promises.
- Heavier than a daemon — a poor fit for a server or a script.
- Model quality varies enormously and the browser does not rank it; a small quantised model will disappoint anyone expecting hosted-frontier output.
- Disk usage grows quietly as downloads accumulate.
- New architectures can arrive later than in the engine underneath.
If you switch away
Your models are GGUF files on disk and are read by Ollama, Jan, llama.cpp and others — the same files, no conversion. Point another tool at the folder and continue.
Chat history stays inside the application and is the only thing that does not travel. Exit cost is close to zero, which is worth knowing when comparing against hosted tools that hold your history.
The alternatives
- Ollama — the terminal-first equivalent, and the one we have hands-on tested.
- Jan — a similar desktop app that is open source.
- GPT4All — comparable packaging with a stronger focus on chatting over your own documents.
- Open WebUI — a browser interface if you would rather run the model as a service.
Compiled from LM Studio’s documentation and public sources. We have not hands-on tested this tool. Last reviewed 16 August 2026.
