A Model Downloads in LM Studio but Won’t Appear in the List

The file is where you expect it, the size looks right, and My Models is empty or missing the one you want. This is almost always the folder layout, and it is one specific rule rather than a general permissions mystery.

The app lists an index, not a directory

LM Studio does not enumerate GGUF files on demand. It maintains an index of known models, built by scanning its models directory, and the list you see is that index. Two consequences follow, and they explain most of the confusing behaviour.

First, a file that does not fit the scanner’s expectations is not “hidden” — it was never indexed, so no amount of scrolling or searching will surface it. Second, the index is refreshed at points the app chooses. Users have reported models downloaded through the command-line tool not appearing in the GUI until the app is restarted, and models vanishing from the list after an update while remaining present on disk. A restart is therefore a legitimate first step here in a way it rarely is elsewhere: it forces a rescan.

Do it in this order — restart the app first, because it costs ten seconds and eliminates the entire class of stale-index problems before you start moving files around.

The folder layout it requires

The scanner expects models organised the way a Hugging Face repository is: a publisher directory, a repository directory inside it, and the GGUF file inside that. A file placed directly in the models root, or one level too deep, is not indexed.

# Indexed
~/.lmstudio/models/lmstudio-community/Meta-Llama-3.1-8B-Instruct-GGUF/
    Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf

# Not indexed: no publisher/repo levels
~/.lmstudio/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf

# Not indexed: one level only
~/.lmstudio/models/my-models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf

This is why a model downloaded from elsewhere — from a browser, with huggingface-cli, or copied off another machine — usually does not show up. The fix is to create the two directory levels and move the file into them. The names do not have to match any real publisher; they have to exist. Multi-part GGUF files belong together in the same repository directory, and moving only the first part of a split model gives you an entry that then fails to load.

Pointing it at a different directory

If your models live on an external drive or a shared volume, change the directory rather than symlinking into the default one. LM Studio exposes the models directory as a setting in its My Models view, and the lms command-line tool can report and manage the same state. After changing it, the same two-level rule applies inside the new root.

Where this goes wrong:

• A network volume that is not mounted at launch. The scan runs, finds nothing, and the index is empty. Mount first, then start the app.
• Permissions on the directory. A models folder owned by another user, or a .lmstudio directory whose ownership was changed by running something as root once, produces an empty list with no error. Restoring ownership to your own user has resolved this in reported cases.
• Case sensitivity and extensions. The scanner is looking for .gguf. A file that arrived as .gguf.part, .bin, or with the extension stripped by a browser is not a candidate.
• Cloud-synced folders. A models directory inside a sync client’s folder may contain placeholder files rather than real bytes. These have the right names and the wrong sizes.

When the download never finished

A download interrupted partway leaves either a partial file or a temporary one. Neither is indexed as a usable model, and the app usually shows nothing rather than showing a broken entry. Check the size against the model card as described in the stuck-preparing page — that page treats the case where the file is indexed and then hangs, which is the same underlying corruption caught one step later.

Delete the partial file rather than resuming. A resumed download that appends to a corrupt prefix produces a full-size file that fails at load, which is a much more annoying problem than an obviously missing one. Disk space is the usual reason a download stopped, and it is worth checking before re-pulling forty gigabytes.

When the app lists it and the API does not

A separate case with the same symptom: the model is visible in the GUI but absent from /v1/models on the local server, so a tool pointed at LM Studio reports no such model. That is not an indexing problem at all.

With just-in-time model loading enabled, the endpoint reports every downloaded model, because any of them can be loaded on demand. With it disabled, the endpoint reports only models currently loaded into memory — which is a defensible design and a surprising one if you are expecting a catalogue. If a client says the model does not exist while the app plainly shows it, check that setting before changing anything on disk.

The command-line tool is useful here because it reads the same index the GUI does without the GUI’s caching. lms ls prints what the app believes it has; if the model is absent there too, the file is genuinely not indexed and the folder layout is the thing to fix. If it is present in lms ls and absent from the window, you have a stale view and a restart is the whole fix. That one comparison separates a disk problem from a UI problem in a couple of seconds, and it is worth doing before either.

Whatever the cause, the confirmation step is the same: load the model in the app once. A model that loads and answers is indexed correctly, and anything still failing after that is a client or server configuration problem rather than a missing file.