LM Studio

LM Studio is a desktop application for running large language models on your own machine. It is not a service and not a model: the weights sit on your disk, inference runs locally, and the network is only needed to download models.

The app handles discovery, downloads, loading into memory and chat, while inference runs on the llama.cpp runtime, with an MLX runtime on Apple Silicon. That runtime is reachable from the interface, the command line and a local API, so hand-driving it and scripting it are not mutually exclusive.

Models and quantisation

Most models come as GGUF files, which llama.cpp opens on every supported platform; on Apple Silicon, MLX models load as well. The quantisation level is visible in the file name (Q4_K_M, Q8_0) and sets both the memory footprint and the quality.

Downloaded models land in a local directory under publisher/model/file, keeping their Hugging Face structure. A GGUF file obtained elsewhere can be brought in with lms import. Checkpoints published as safetensors are not loadable on their own; those need a GGUF or MLX build.

The local server and the API

The server starts with a toggle on the Developer tab, or from a terminal with lms server start. It listens on port 1234, and the OpenAI-compatible endpoints live under /v1: /v1/models, /v1/chat/completions, /v1/responses, /v1/embeddings and /v1/completions. An existing OpenAI client needs no rewrite, only a new base URL, for example http://localhost:1234/v1.

Its own REST API under /api/v0 reports more metadata about a model: architecture, format, quantisation, state and maximum context length. Anthropic-compatible endpoints and first-party TypeScript and Python SDKs talk to the same server.

It binds to localhost by default but can be served on the network, and that boundary needs deliberate handling of authentication and of the clients allowed to reach it.

Command line and headless use

lms ships with the installation, is open source, and sees the same model library as the app: lms get searches and downloads, lms ls lists the models on disk, lms ps lists the loaded ones, and lms load and lms unload move them in and out of memory.

Loading is configurable: --gpu sets how much computation is offloaded (max, auto or between 0.0 and 1.0), --context-length sets the context size, and --identifier gives the model a stable name that keeps client code from breaking on every model swap. With no graphical interface, as on a server or a CI runner, the llmster daemon runs standalone against the same server.

What to watch

• Memory. Loading allocates memory for the weights, so model size and context length set the requirement together. On Windows the documentation recommends at least 16 GB of RAM and 4 GB of dedicated VRAM, and requires AVX2 on x64.
• macOS. An Apple Silicon machine (M series) with macOS 14 or newer; Intel-based Macs are not supported.
• Linux. An AppImage for Ubuntu 20.04 or newer; newer than 22 is less tested.
• Quantisation. A smaller level asks for less memory at the cost of quality and long-context behaviour, so it is a measurement question, not a taste question.

Further reading

• LM Studio as a Local LLM API Server - starting the local server and the APIs it exposes.
• lms, LM Studio’s CLI - the command list, including the load options.
• System Requirements - supported CPUs, memory and GPU requirements.

At CyberElectro LM Studio is the default runtime for local models: we reach the OpenAI-compatible endpoint at http://127.0.0.1:1234/v1, our gpt-oss model does the translation work, and both Docker services and Hermes Agent use the same server.