# LM Studio vs Ollama: Which Local Runner Belongs Behind Your Agent? > LM Studio vs Ollama for agents, checked October 2026: licenses, context defaults, overflow behavior and tool calling, plus llama.cpp and how to wire each in. Most LM Studio vs Ollama comparisons stop at "GUI or CLI." That stops mattering once the runner sits behind an agent. An agent's first request can carry more than 20,000 tokens of system prompt and tool definitions before you type a word, it calls tools in a loop, and it degrades quietly when the runner drops part of that prompt. So I checked Ollama, LM Studio and llama.cpp's own `llama-server` against their docs, terms and GitHub on October 2, 2026, looking at the rows an agent cares about: context defaults, what happens on overflow, which APIs exist, auth, concurrency and license terms. **The short answer:** Put Ollama behind your agent if you want an MIT-licensed background server that most agent tools already speak, then raise its context to 64k: below 24 GiB of VRAM it defaults to 4k and, by default, truncates longer prompts without returning an error. Pick LM Studio if you're on Apple Silicon and want MLX models, a GUI for choosing quantizations and parallel requests out of the box, and your use is personal or internal, because its terms rule out SaaS use. Pick llama.cpp's `llama-server` when you want the engine itself: the newest model support, API keys, and a 400 error where Ollama, by default, silently shortens the prompt. ## LM Studio vs Ollama vs llama.cpp at a glance (checked October 2026) The biggest differences are license, what each does when a prompt doesn't fit, and default concurrency. Interface is the smallest one: all three run headless and serve the same three API families. | Checked 2026-10-02 | Ollama | LM Studio | llama.cpp (`llama-server`) | | ------------------------------ | --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | License | MIT | Proprietary app, free at home and work; `lms` CLI and MLX engine MIT | MIT | | Latest release | v0.35.0 (Sep 28) | 0.4.25 | v0.5.0 (Sep 23); per-commit builds, b11344 the latest on Oct 2 | | Release pace | 25 stable releases Jul 4–Oct 2 | 0.4.0 shipped Jan 28; now 0.4.25 | About 400 per-commit builds Sep 3–Oct 2, plus v0.4.0, v0.4.1, v0.5.0 | | GitHub stars | 182k | 5.3k (the `lms` CLI; the app has no public repo) | 130k | | Interface | CLI, desktop app, background service | Desktop GUI, `lms` CLI, `llmster` headless daemon | CLI binary with built-in web UI | | Default address | 127.0.0.1:11434 | localhost:1234 | 127.0.0.1:8080 | | Agent-facing APIs | OpenAI Chat Completions, Responses (stateless), Anthropic Messages | OpenAI Chat Completions, Responses, Anthropic Messages, REST `/api/v1` | OpenAI Chat Completions, Responses, Anthropic Messages | | Tool calling | On all three APIs; `ollama show` lists a model's `tools` capability | Native for tool-trained templates, prompt-based fallback for the rest | "For ~any model" via Jinja chat templates (`--jinja`, on by default) | | Engines and formats | GGUF via llama.cpp (0.30+); MLX engine on Apple Silicon | llama.cpp (GGUF) on all platforms; MLX on Apple Silicon | GGUF on Metal, CUDA, HIP, Vulkan, SYCL and more | | Default context | 4k under 24 GiB VRAM, 32k at 24–48 GiB, 256k at 48+ | Set per load; docs example loads 4,096 of a 262,144 maximum | Model's trained length, cut by `--fit` to fit memory (min 4096) | | Prompt longer than the context | By default HTTP 200, prompt truncated, warning only in the server log | Inconsistent: a 400 naming the overflow ([#237](https://github.com/lmstudio-ai/lmstudio-bug-tracker/issues/237), 2024); garbage and no error on a tool-result overflow ([#1806](https://github.com/lmstudio-ai/lmstudio-bug-tracker/issues/1806), 0.4.11) | HTTP 400 "exceeds the available context size" | | Parallel requests | 1 per model by default (`OLLAMA_NUM_PARALLEL`) | 4 by default on the llama.cpp engine ("Max Concurrent Predictions") | Slots auto-sized, continuous batching on | | Several models | Up to 3 per GPU; unloaded after 5 idle minutes | JIT loading, 60-minute idle TTL, auto-evict keeps 1 | Router mode: up to 4 loaded at once (`--models-max`), loaded on demand | | Auth on the local API | None: the local server validates no keys | API tokens (0.4.0+), off by default | `--api-key` | | Platforms | macOS 14+ (Intel Macs CPU-only), Windows, Linux, Docker | macOS 14+ Apple Silicon only, Windows x64/ARM, Linux x64/ARM64 | macOS, Windows, Linux via Homebrew, winget, conda, Nix, Docker | | Getting models | `ollama pull` from its library, or `hf.co//` GGUFs | In-app Hugging Face search, `lms get` | `-hf /:` or local files | Sources: [Ollama FAQ](https://docs.ollama.com/faq), [Ollama context-length docs](https://docs.ollama.com/context-length), [Ollama OpenAI compatibility](https://docs.ollama.com/api/openai-compatibility), [Ollama Anthropic compatibility](https://docs.ollama.com/api/anthropic-compatibility), [Ollama macOS requirements](https://docs.ollama.com/macos), [Hugging Face's Ollama guide](https://huggingface.co/docs/hub/ollama), [Ollama 0.30 post](https://ollama.com/blog/improved-performance-and-model-support-with-gguf), [LM Studio developer docs](https://lmstudio.ai/docs/developer), [LM Studio tool use](https://lmstudio.ai/docs/developer/openai-compat/tools), [LM Studio parallel requests](https://lmstudio.ai/docs/app/advanced/parallel-requests), [LM Studio idle TTL](https://lmstudio.ai/docs/developer/core/ttl-and-auto-evict), [LM Studio list-models API](https://lmstudio.ai/docs/developer/rest/list), [LM Studio system requirements](https://lmstudio.ai/docs/app/system-requirements), [LM Studio download page](https://lmstudio.ai/download), [llama-server README](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md), [llama.cpp install guide](https://github.com/ggml-org/llama.cpp/blob/master/docs/install.md), and the GitHub API for [Ollama](https://github.com/ollama/ollama), [llama.cpp](https://github.com/ggml-org/llama.cpp) and [lms](https://github.com/lmstudio-ai/lms) stars and releases. ## Which runner should sit behind your agent? Make the Ollama vs LM Studio call by where the agent runs and who it serves, not by which window looks nicer. ### Choose Ollama if - The agent is one of many clients on your machine. Ollama's [integrations docs](https://docs.ollama.com/integrations) cover Claude Code, Codex CLI, OpenCode, Goose, Cline, Zed and others, and `ollama launch claude --model ` configures and starts one in one command. - You want an MIT license and a service that starts at login and frees memory on its own after five idle minutes. - You run Linux servers: the [Linux docs](https://docs.ollama.com/linux) give a systemd unit, and every server setting is an environment variable on that service. - You can live with one request at a time per model, or you'll raise `OLLAMA_NUM_PARALLEL` and budget the memory. ### Choose LM Studio if - You're on Apple Silicon and want MLX builds next to GGUF, picked in a [built-in Hugging Face downloader](https://lmstudio.ai/docs/app/basics/download-model) that lists each quantization (Q3_K_S, Q8 and so on) before you download. - You'll run a few agents or sub-agents against one model: four concurrent predictions is the default on the llama.cpp engine, and LM Studio's June benchmark ran its MLX engine at four too. - Your use is personal or internal to your company. The terms say "personal and / or internal business purposes." - You want token auth on the local API without putting a proxy in front. ### Choose llama.cpp (`llama-server`) if - You want new model architectures as soon as they're merged: llama.cpp tagged about 400 per-commit builds in the 30 days to October 2. - You'd rather get a 400 error than a confident answer built from part of your prompt. - You want one server process for a container or CI job, with `--api-key`, official Docker images and no app around it. - You're fine managing GGUF files and flags yourself. ## Context length: the default that breaks agents All three can load a model with a smaller window than an agent's first request. Set the context explicitly, then verify what was actually allocated, because each runner fails differently when it's too small. How big is "too small"? In one [Ollama issue from March 2026](https://github.com/ollama/ollama/issues/15013), Claude Code's own `/context` view showed 3.1k tokens of system prompt, 15.5k of built-in tools and 4.5k of MCP tools: about 23.5k before any message. [Ollama's context-length docs](https://docs.ollama.com/context-length) say agents and coding tools "should be set to at least 64000 tokens." More context costs memory, so check that the model still fits before you raise it. ### Ollama ```bash OLLAMA_CONTEXT_LENGTH=65536 ollama serve ollama ps # the CONTEXT column shows what each loaded model actually got ``` If Ollama runs as the macOS app, set the variable with `launchctl setenv OLLAMA_CONTEXT_LENGTH 65536` and restart the app. On Linux, add it to the service with `systemctl edit ollama.service`. The [FAQ](https://docs.ollama.com/faq) covers both. The OpenAI-compatible endpoint has no field for context size, so for a per-model setting bake it into a Modelfile: ```text FROM PARAMETER num_ctx 65536 ``` Then `ollama create -64k -f Modelfile` and point the agent at `-64k`. **Failure mode:** by default, an over-long prompt is shifted, not rejected. The server log shows `msg="truncating input prompt" limit=4096 prompt=42218` (from [pull request #14891](https://github.com/ollama/ollama/pull/14891)) while the client gets HTTP 200. An open pull request measured a 12,000-token prompt against a 4096 window on 0.34.0 and got back an empty answer with only 2,050 prompt tokens evaluated ([#18399](https://github.com/ollama/ollama/pull/18399), September 2026). Ollama's native API accepts a per-request `"shift": false` that returns an error instead ([`api/types.go`](https://github.com/ollama/ollama/blob/main/api/types.go)), but the OpenAI-compatible endpoints have no such field. If an agent on Ollama "forgets" its tools or instructions, search the server log for `truncating input prompt` first. Per the [troubleshooting docs](https://docs.ollama.com/troubleshooting), it's `~/.ollama/logs/server.log` on a Mac and `journalctl -u ollama` on Linux. Memory scales with `OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH`. If 64k doesn't fit, `OLLAMA_KV_CACHE_TYPE=q8_0` uses about half the KV-cache memory of the f16 default, according to the same FAQ. It needs Flash Attention, which Ollama turns on automatically where the backend supports it. ### LM Studio ```bash lms load --context-length 65536 --estimate-only # memory estimate, loads nothing lms load --context-length 65536 curl -s http://localhost:1234/api/v1/models # loaded_instances[].config.context_length ``` The [`lms load` docs](https://lmstudio.ai/docs/cli/local-models/load) cover both flags. If your agent relies on just-in-time loading instead, set a [per-model default](https://lmstudio.ai/docs/app/advanced/per-model) context size in My Models, because the context is chosen at load time. The [list-models example](https://lmstudio.ai/docs/developer/rest/list) in LM Studio's own docs shows a model loaded at 4,096 tokens against a 262,144 maximum. **Failure mode:** in a 2024 report, the API answered an oversized request with "Trying to keep the first 15857 tokens when context the overflows. However, the model is loaded with context length of only 4096 tokens" ([bug tracker #237](https://github.com/lmstudio-ai/lmstudio-bug-tracker/issues/237)). Two open reports matter on a Mac: on 0.4.21, MLX models ignored the requested context length ([#2318](https://github.com/lmstudio-ai/lmstudio-bug-tracker/issues/2318)), and an oversized tool result produced garbage output instead of an error on 0.4.11 ([#1806](https://github.com/lmstudio-ai/lmstudio-bug-tracker/issues/1806)). Check `context_length` after every load rather than trusting the flag. ### llama-server ```bash llama-server -hf /:Q4_K_M -c 65536 --port 8081 curl -s http://127.0.0.1:8081/props # default_generation_settings.n_ctx ``` Per the [llama-server README](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md), `-c 0` (the default) takes the model's trained length, and `--fit` (on by default) shrinks unset values to fit device memory, down to 4096. Set `-c` yourself so the number is one you chose. **Failure mode:** a prompt over the window gets HTTP 400 with "request (N tokens) exceeds the available context size (M tokens), try increasing it" ([server source](https://raw.githubusercontent.com/ggml-org/llama.cpp/8d81559fa7b8bcac9f7c8b478858953486371f90/tools/server/server-context.cpp), line 3207 at commit `8d81559`). It's loud, so your agent sees it. ## Wire it into your agent All three serve OpenAI-style and Anthropic-style endpoints, so wiring is a base URL, a model ID and sometimes a dummy key. | Runner | OpenAI base URL | Anthropic base URL | Model ID comes from | Key | | ------------ | --------------------------- | ------------------------ | -------------------------------------------- | --------------------------------------- | | Ollama | `http://localhost:11434/v1` | `http://localhost:11434` | `ollama ls` (tag included) | Any string; ignored | | LM Studio | `http://localhost:1234/v1` | `http://localhost:1234` | `GET /v1/models`, or `lms load --identifier` | Token if "Require Authentication" is on | | llama-server | `http://127.0.0.1:8081/v1` | `http://127.0.0.1:8081` | Model path, or `--alias ` | Whatever you passed to `--api-key` | A generic OpenAI client needs only the base URL. This is [Ollama's documented example](https://docs.ollama.com/api/openai-compatibility); swap the URL for the other two: ```python from openai import OpenAI client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") # required but ignored reply = client.chat.completions.create( model="", messages=[{"role": "user", "content": "Say this is a test"}], ) ``` If the agent's tool calls come back as plain text, check the model before the agent. `ollama show ` should list `tools`, and LM Studio's `/api/v1/models` reports `trained_for_tool_use`. For other models, LM Studio [falls back](https://lmstudio.ai/docs/developer/openai-compat/tools) to a default prompt-based format, and it warns that smaller or untrained models may emit tool calls it can't parse. Those arrive in `content` instead of `tool_calls`. For Claude Code, both vendors document the Anthropic route. Ollama: `ANTHROPIC_BASE_URL=http://localhost:11434` with `ANTHROPIC_AUTH_TOKEN=ollama`. [LM Studio](https://lmstudio.ai/docs/developer/anthropic-compat): `ANTHROPIC_BASE_URL=http://localhost:1234` with `ANTHROPIC_AUTH_TOKEN=lmstudio`. `llama-server` serves `/v1/messages` too, and tool use there needs `--jinja`, which is on by default. For Codex, LM Studio points to its `/v1/responses` endpoint and Ollama has `ollama launch codex`. **Watch port 8080.** `llama-server` and `octomind server` both default to it (I checked `octomind server --help` on 0.55.2). That's why the examples above move llama-server to 8081. ### Octomind's `local:` provider Octomind is ours. The `local:` provider speaks OpenAI Chat Completions and defaults to Ollama's endpoint, so Ollama needs no extra setup: ```bash # Ollama: local: already points at http://localhost:11434/v1/chat/completions octomind run developer:general -m local: # LM Studio: LOCAL_API_URL takes the full endpoint path, not a base URL export LOCAL_API_URL="http://localhost:1234/v1/chat/completions" octomind run developer:general -m local: # llama-server moved to 8081 export LOCAL_API_URL="http://127.0.0.1:8081/v1/chat/completions" octomind run developer:general -m local: ``` If you turned on LM Studio tokens or `--api-key`, put the key in `LOCAL_API_KEY`. Two traps from the [providers guide](/docs/usage/04-providers): the `ollama:` prefix defaults to Ollama's hosted cloud, so use `local:` for a local server, and `-m` changes only the conversation model. Point the supervisor and compression at the same server if no call should leave the machine: ```toml [model] name = "local:" [supervisor.model] name = "local:" [compression.model] name = "local:" ``` The full walkthrough, including the hybrid local-plus-cloud pattern, is in [run a coding agent locally](/blog/run-coding-agent-locally-ollama). Which model to load at all is covered in [open-weight models that hold up on real coding work](/blog/open-weight-models-for-coding). ## Ollama vs llama.cpp: when to drop the wrapper The llama.cpp vs Ollama choice is mostly about defaults and packaging, not kernels: [Ollama 0.30](https://ollama.com/blog/improved-performance-and-model-support-with-gguf) (June 5, 2026) brought GGUF compatibility "through llama.cpp," alongside Ollama's own MLX engine on Apple Silicon. What Ollama adds: a model library with `ollama pull`, automatic load and unload, an app, `ollama launch` for agent setup, and one environment-variable config surface. What you give up: conservative defaults (4k context under 24 GiB, one request at a time), silent truncation by default, no auth on the local API, and engine updates on Ollama's release schedule rather than llama.cpp's. What `llama-server` adds: every engine flag, a 400 on overflow, `--api-key`, router mode that loads up to 4 models on demand, `--sleep-idle-seconds` to free memory, and new architectures as soon as they land upstream. The [v0.4.0 notes](https://github.com/ggml-org/llama.cpp/releases/tag/v0.4.0), for example, added "initial Qwen3.8-Flash-Next" support. What you give up: curation. You pick GGUF files and quantizations, and with roughly 13 builds a day you pin a version yourself. **Rule:** start on Ollama. Move to `llama-server` when you hit a default you can't change, a model Ollama doesn't run yet, or a truncation you can't afford. ## Is LM Studio open source? Licenses, terms and the "internal business" line No: the LM Studio app is proprietary, while its `lms` CLI and MLX engine are MIT. Ollama and llama.cpp are MIT too: embed them, ship them, sell a service on them. LM Studio is free for home and work [since July 8, 2025](https://lmstudio.ai/blog/free-for-work), and the [app terms](https://lmstudio.ai/app-terms) (version of August 23, 2026) draw two lines that matter for agent builders: - The license covers use "solely for Your personal and / or internal business purposes." - You may not "use for service bureau use, as an application service provider, or a software-as-a-service." If your agent is a product that customers reach through the runner, LM Studio is off the table. Use Ollama, `llama-server` or vLLM. The open parts are narrower than the app: the [`lms` CLI](https://github.com/lmstudio-ai/lms) and [mlx-engine](https://lmstudio.ai/blog/mlx-engine-agentic-workloads) are MIT, and `llmster`, the [headless daemon](https://lmstudio.ai/docs/developer/core/headless), is "the core of the LM Studio desktop app," packaged without the GUI. [LM Studio Bionic](https://lmstudio.ai/blog/introducing-lm-studio-bionic) (July 16, 2026) is a separate agent app that can also run open models in LM Studio's cloud. The LM Studio runner compared here can run entirely offline, per its [docs](https://lmstudio.ai/docs/app/system-requirements). On the Ollama side, a signed-in server can route `:cloud` models through ollama.com. Set `OLLAMA_NO_CLOUD=1` and look for `Ollama cloud disabled: true` in the log if nothing should leave the box. ## Speed: what the published numbers actually show I found no neutral benchmark from 2026 that runs all three on the same machine. The numbers that exist come from the vendors or from one practitioner. The table keeps only those that name their hardware; read them as format and engine effects, not brand effects. | Source | Hardware and model | Result | | ---------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | [Ollama, June 5, 2026](https://ollama.com/blog/improved-performance-and-model-support-with-gguf) | RTX 5090, Gemma 4 26B Q4_K_M | Ollama 0.30 up to 20% faster on NVIDIA | | [LM Studio, June 5, 2026](https://lmstudio.ai/blog/mlx-engine-agentic-workloads) | M3 Max 36 GB, Qwen3.6-27B MLX 4-bit, 4 parallel chats | mlx-engine 1.8.5 vs 1.7.0: 15.24 → 33.97 output tok/s; 82% less extra RAM on long prompts | | [Jakub Jirák, July 8, 2026](https://www.thinkdifferent.blog/blog/lm-studio-vs-ollama-the-local-ai-showdown-nobody-wrote-honestly/) | M2 Ultra 128 GB, Llama and Qwen 8B–70B | LM Studio MLX 4-bit 23–27% faster than Ollama GGUF Q4_K_M; GGUF in LM Studio "nearly identical" | The pattern: off the Mac, all three run llama.cpp-family code, so versions and settings matter more than which runner you picked. On a Mac, the format matters: the one same-machine comparison put MLX 23–27% ahead of GGUF, but it compared MLX in LM Studio against GGUF in Ollama, not two runners on the same format. Ollama's [March 30 MLX post](https://ollama.com/blog/mlx) reports a large speedup over its GGUF path but doesn't name the test Mac, so it isn't in the table. Its MLX engine also runs fewer models than its GGUF path: 0.30 added llama.cpp to bring "support to more models," and the March preview asked for a Mac with more than 32 GB of unified memory. For agents, prompt processing matters more than generation speed. As [Ollama's June MLX post](https://ollama.com/blog/mlx-performance) puts it, "every request resends the whole transcript." Both vendors spent 2026 on cache reuse for exactly that: Ollama's cache snapshots and LM Studio's disk-backed KV cache. [AUTHOR: On your own machine, the same GGUF model at 64k context through Ollama, LM Studio and llama-server: prompt-processing and generation tok/s for a ~20k-token agent prompt?] ## LM Studio alternatives if closed source rules it out Stars and licenses checked October 2, 2026: | Alternative | License | Stars | What it replaces | | -------------------------------------------------- | ---------- | ----- | -------------------------------------------------------------------------- | | [Ollama](https://github.com/ollama/ollama) | MIT | 182k | The background server and model manager | | [llama.cpp](https://github.com/ggml-org/llama.cpp) | MIT | 130k | The engine plus a web UI, with router mode for several models | | [Jan](https://github.com/janhq/jan) | Apache 2.0 | 44.8k | The desktop chat app, with an OpenAI-compatible server on `localhost:1337` | | [vLLM](https://github.com/vllm-project/vllm) | Apache 2.0 | 93k | A multi-user GPU server, with continuous batching and PagedAttention | Jan's latest release was v0.8.4 on July 23, 2026. vLLM is the one to read about if "vllm vs ollama" is your real question: its README leads with serving throughput, PagedAttention, and tensor, pipeline and expert parallelism across GPUs. ## Where each one loses (honest version) **Ollama.** By default it shortens prompts that don't fit without returning an error, and the OpenAI-compatible endpoints can't opt out per request. Its local API has no authentication (binding `OLLAMA_HOST=0.0.0.0` opens it to your network, so put a proxy in front), cloud features are on until you disable them, and one request per model is the default. **LM Studio.** Closed source with a no-SaaS clause, Apple Silicon only on the Mac side (no Intel Macs), open bugs where MLX models ignore the requested context, and a product line now split between the runner and Bionic. **llama.cpp.** No curation, a long flag surface (the README's option table is generated from the code), and a release stream you have to pin yourself. **Octomind in this setup.** `local:` speaks Chat Completions only. Octomind doesn't start or size your runner, so the context-length check above is still your job. A main-only `-m` switch leaves the supervisor and compression on their configured provider until you change them. **[Get Octomind](https://octomind.run)** — point `local:` at whichever runner you picked. ## FAQ ### Is LM Studio better than Ollama? Neither wins across the board. For a server behind an agent, Ollama's MIT license, background service and wide integration support usually decide it. Raise its context to 64k first. LM Studio is better on Apple Silicon when you want MLX models, a GUI for picking quantizations and parallel requests out of the box, as long as your use is personal or internal business. ### Is LM Studio free for commercial use? LM Studio has been free for home and work use since July 8, 2025, with no form or license request. Its app terms (August 23, 2026) still limit use to personal and internal business purposes and forbid service-bureau, application-service-provider and SaaS use. An Enterprise plan adds SSO and model or MCP gating. If customers reach your product through the runner, use an MIT-licensed runner such as Ollama or llama.cpp. ### Does Ollama use llama.cpp? Yes for GGUF models: Ollama 0.30 (June 5, 2026) runs GGUF "through llama.cpp," and on Apple Silicon it also has its own MLX engine. The llama.cpp vs Ollama choice is therefore about defaults and packaging. Ollama adds a model library, auto load and unload and agent integrations. llama-server adds every engine flag, API keys, an error on context overflow and day-one model support. ### Which is faster, LM Studio or Ollama? On the same GGUF file both run llama.cpp-family code, and one practitioner measured "nearly identical" speeds. On a Mac, MLX builds are faster: LM Studio's MLX path beat Ollama's GGUF path by 23–27% on an M2 Ultra in a July 2026 test. Ollama now has its own MLX engine for some models, so compare MLX against MLX. Test your model at your context length before deciding. ### Can LM Studio run headless on a server? Yes. Since 0.4.0 (January 28, 2026), `llmster` runs LM Studio's core as a daemon without the GUI on Linux, macOS or Windows. Install it with `curl -fsSL https://lmstudio.ai/install.sh | bash`, then run `lms daemon up` and `lms server start`. LM Studio's docs include a systemd unit for Linux. I found no separate license for llmster, so read the app terms before it serves anyone outside your company.