We added two MLX builds to a copy of LM Studio that had only ever run GGUF files, and three things changed that nobody asked for. A model key that agents on our test machine already use began to load a different file. A context length we set on the command line was dropped. And one load took nine minutes and two seconds. None of them produced an error. This guide walks through adding an MLX model in LM Studio next to a GGUF you already rely on, with the check for each of the three, from a session on 12 October 2026.
How to add an MLX model in LM Studio next to a GGUF you already use
The test machine is an M4 Pro with 48 GB of unified memory on macOS 27.0.1, with LM Studio 0.4.25 and its MLX engine at version 1.11.0. LM Studio already held GGUF copies of Gemma 4 31B and Qwen3.6 35B-A3B. We wanted the 4-bit MLX builds of both, to compare the engines.
LM Studio will download a model for you from its own search. We fetched the files from Hugging Face ourselves, because one build was going to an external drive. LM Studio’s page on importing models downloaded outside the app gives the layout it expects: a publisher folder inside ~/.lmstudio/models/, a model folder inside that, and the files inside the model folder. An MLX build is a folder of several files, not one file, so the whole folder goes in. Ours were lmstudio-community/gemma-4-31B-it-MLX-4bit at 18.44 GB and lmstudio-community/Qwen3.6-35B-A3B-MLX-4bit at 20.4 GB.
Check the files before you load them. A size check after our download found one of the four Qwen3.6 weight files short, at 1.49 GB of 4.38 GB. Resuming the download completed it. Hugging Face lists a SHA-256 hash for every large file in a repository, and after the resume all eight weight files across the two builds matched theirs. Compare one yourself with a single command and the hash shown on the file’s page:
shasum -a 256 model-00004-of-00004.safetensorsThen confirm LM Studio can see the build:
lms lsThat listing is where the first surprise showed up.
Why lms load picks the MLX model in LM Studio after you add it
LM Studio did not list the Qwen3.6 MLX build as a new model. It folded it into the entry that was already there. Before, lms ls showed qwen/qwen3.6-35b-a3b with one variant. Afterwards it showed the same key with two variants, and lms ls qwen/qwen3.6-35b-a3b named them:
qwen/qwen3.6-35b-a3b@4bit 17.54 GB
qwen/qwen3.6-35b-a3b@q4_k_m 22.07 GBThe machine-readable listing, lms ls --json, carried a selectedVariant field for the key, and it now read qwen/qwen3.6-35b-a3b@4bit. So the plain command lms load qwen/qwen3.6-35b-a3b, which had loaded the GGUF that morning, loaded the MLX build that afternoon. Any agent or script that asks the server for that key gets the new file too.
We could not choose the other variant from the command line. lms load qwen/qwen3.6-35b-a3b@q4_k_m and lms load qwen/qwen3.6-35b-a3b@4bit both answered “Model not found”, although those are the names lms ls had just printed. Loading by the GGUF’s folder path failed the same way.
Gemma went differently. Its MLX build appeared as a separate key, gemma-4-31b-it-mlx, and the existing google/gemma-4-31b-qat kept its single GGUF variant. The two Gemma builds come from different original models on Hugging Face, the standard release and the quantisation-aware-trained one, which may be why LM Studio kept them apart.
The check is short. After adding any MLX build, run lms ls --json and read selectedVariant for every key your agents name. If one has moved, the model behind your endpoint has changed even though no configuration file did. That matters because the two engines do not behave identically. In our tests the MLX build of Qwen3.6 was faster, as our MLX vs llama.cpp comparison records, and it also returned empty content for every structured output request.
What to do when LM Studio ignores the context length on an MLX model
LM Studio documents a flag for this. Its page for the lms load command says --context-length sets the number of tokens the model will consider as context. We loaded all four builds with the short form of that flag set to 32,768.
| Build | Context requested | Context loaded |
|---|---|---|
| Gemma 4 31B, GGUF | 32,768 | 32,768 |
| Qwen3.6 35B-A3B, GGUF | 32,768 | 32,768 |
| Gemma 4 31B, MLX | 32,768 | 71,936 |
| Qwen3.6 35B-A3B, MLX | 32,768 | 183,296 |
Both GGUF loads did as asked. Both MLX loads chose their own figure and said nothing. lms ps is the only place the real number appears.
This is a reported fault. Issue 2250 in LM Studio’s bug tracker, opened on 8 August 2026, describes MLX models on engine version 1.11.0 loading at a context sized to the machine’s memory whatever the user configured, and names the Qwen3.6 35B-A3B 4-bit build among the models affected. It was still open when we read it.
There is no setting we can offer that fixes it, because we found none that took effect. What you can do is know the number. Run lms ps after every MLX load and read the context column. Then cap the conversation from the client side: an agent that trims or compacts its own history at a fixed token count will never reach the larger window. We have written before about what happens when a local model’s context is not the size you assumed, and about what a 64K context window costs in RAM. We have not yet measured how memory grows on the MLX engine as a long session fills a window of 183,296 tokens. After sessions of about 22,000 tokens, the MLX process held 17.4 GB for Gemma 4 31B and 21.4 GB for Qwen3.6 35B-A3B.
Why an MLX model takes nine minutes to load from an external drive
The Qwen3.6 MLX build sat on a portable SSD, linked into the models folder. Its first load took 542 seconds. The Gemma 4 31B MLX build, on the internal drive, had loaded in 14 seconds, although its files had just been copied and were probably still in the system’s file cache, so that figure flatters it.
The cause was the cable, or the port. macOS reported the drive’s connection at 480 megabits a second, which is USB 2 speed, and 20.4 GB in 542 seconds works out at about 38 megabytes a second. Copying the 18.44 GB Gemma build off the same drive earlier had taken 8 minutes 11 seconds, the same rate. To read the link speed of an external drive:
system_profiler SPUSBDataType SPUSBHostDataType | grep -i -B2 -A12 "Your Drive Name"Look for the Link Speed line. If it says 480 Mb/s, the drive is on a USB 2 path however fast the drive itself is, and a different cable or port is the fix. A nine-minute load is also likely to outlast the timeout of any tool that loads models on demand and waits a fixed time for a reply.
That is the common thread in all three. Adding an MLX build is easy and the engine is quick, and the cost shows up as quiet changes to things that were settled: which file a key means, how much context a load gets, how long a load takes. Three commands cover them, lms ls --json, lms ps and system_profiler, and they are worth running before the first agent is pointed at the new build, not after it has behaved strangely for a day.
