--- title: "Migrate from LM Studio on Mac: Your Models Are Already Portable" description: "There is no export step. LM Studio stores plain GGUF files, so moving to another tool is a file move. Here is the whole migration and what stays behind." date: 2026-08-10 author: "Ben Racicot" tags: ["LM Studio", "Migration", "GGUF", "macOS", "Ollama", "Local LLM"] type: "article" canonical: "https://modelpiper.com/blog/migrate-from-lm-studio-mac" --- # Migrate from LM Studio on Mac: Your Models Are Already Portable > There is no export step. LM Studio stores plain GGUF files, so moving to another tool is a file move. Here is the whole migration and what stays behind. ## TL;DR LM Studio needs no export tool, because it never locked anything up. Models sit as plain GGUF files under ~/.cache/lm-studio/models with real filenames, and any llama.cpp-based tool loads them directly. The migration is a move or a copy. What does not transfer is the app state: chats, per-model presets, and prompt templates. Migrating off a local AI tool is usually an archaeology problem. You go looking for your models and find a content-addressed store, a manifest layer, and a community script from 2024 that used to work. LM Studio is not that. It writes plain GGUF files with the names they were published under, in a directory it lets you change. Whatever else is true about the app, its storage is honest, and the consequence is that this guide is short. ## Where are the models? By default, ~/.cache/lm-studio/models, organized into publisher and repository subfolders that mirror how the models are laid out on Hugging Face. LM Studio's docs confirm the directory is user-changeable from within the app, so if you ever pointed it at an external drive, check the setting before assuming the default. The fastest way to confirm what you actually have is the CLI. LM Studio ships `lms` with the app, and `lms ls` lists the models available on disk. Run it before you move anything and you have your inventory. If the command is not found, the app has not been run yet on this machine, which the docs list as a prerequisite. ## Moving to another llama.cpp-based tool Copy or move the .gguf files into the new tool's models directory. There is no conversion, no import step, and no metadata to rebuild. GGUF carries its own architecture, quantization and chat template in the file header, so the receiving tool reads everything it needs from the bytes you moved. Two practical notes. Copy rather than move while you are testing, so a bad result costs you disk rather than a redownload; delete the originals once the new tool has actually generated something. And keep the filenames, because they encode the model name and quantization, and you will want to know which is which in six months. ## Moving to Ollama is the one direction that is harder This is the query people search most in this cluster, and it deserves the honest answer: it is the awkward direction, and not because of anything LM Studio did. Ollama does not read loose GGUF files from a folder. It keeps weights in a content-addressed store as sha256-named blobs behind its own manifest format, so importing means writing a one-line Modelfile and running `ollama create`, which copies the file into that store. Your disk usage roughly doubles until you delete the original, and the model is then inside a layout that takes manual digest mapping to get back out of. Importing into Ollama is a one-line Modelfile; exporting from it has [no command at all](/blog/migrate-from-ollama-mac). If Ollama is where you are going, do it deliberately and one model at a time, watching the disk. If you are going there because you want a headless server, that is a good reason. If you are going there because you assumed it was the standard destination, know that any llama.cpp-based tool takes your files as they are. ## What does not transfer Honesty section. Three things stay behind, and none of them are recoverable from the model files. **Chats.** Conversation history is app state, stored under `~/Library`, in a layout that is LM Studio's and version-volatile. There is no portable format for this across local AI apps, so treat the history as something you leave rather than something you move. If a specific conversation matters, copy the text out before you uninstall. **Per-model presets.** LM Studio lets you save defaults per model, including GPU offload, context size and whether to use Flash Attention. Those live in app state, not in the GGUF, so you will set them again wherever you land. Most of them you will not want anyway: GPU offload on Apple Silicon should be at maximum in any tool, and context size is a decision you should be remaking against the new tool's memory behaviour. **Prompt templates you overrode.** If you edited a model's template in the app, the edit is app state. The template that travels is the one embedded in the GGUF metadata by whoever published it, which is usually the correct one and is what the receiving tool will use. ## Doing it, step by step The steps below move one model so you can verify before committing. Repeat for the rest, then reclaim the space. ## Landing in ToolPiper Since you are reading this on our site: ToolPiper's models directory is `~/Library/Application Support/ToolPiper/models/`, and moving your LM Studio files into it is the whole import. They appear in the model picker, ready to load. No conversion, no manifest, no registry name. The engine is upstream llama-server embedded directly, build b10068, unmodified, so the same file behaves the same way. Expect parity on speed rather than a gain: our same-bytes benchmark on an M2 Max landed within single digits in both directions with the winner flipping by model. Pick on storage, interface and direction, which is exactly what this page has been about. What the free tier adds around the runner: unlimited model downloads, multi-model switching, a local OpenAI-compatible API, embeddings, developer tokens, all speech including transcription, text-to-speech, voice cloning and push-to-talk dictation, full browser automation, and an MCP server with over 420 tools that Claude Code, Cursor and any other MCP client can call. Local RAG over your files is the $10 Pro tier. No account, no caps, no terminal. The honest limits: macOS 26 or newer and Apple Silicon only, a higher floor than LM Studio's macOS 14.0, and no Windows or Linux build. LM Studio's model browser is also better than ours, and if in-app model discovery is the thing you use it for, that is a real reason to keep it installed alongside. The files are shared either way. Cost, since a migration is a good moment to check it: LM Studio's local app is free and its cloud inference is metered per million tokens. Nothing in the move above costs anything on our side either, and the free tier covers the runner outright. [The full comparison of what each charges for](/compare/is-lm-studio-free). ## Steps ### 1. Inventory what you have Run `lms ls` to list the models on disk with their sizes, and check the app's model directory setting in case you moved it off the default. Decide what is worth keeping now rather than moving forty gigabytes of experiments you will never load again. ### 2. Find the file Open the models directory in Finder with Cmd+Shift+G. Inside you will find publisher and repository folders mirroring Hugging Face, with the .gguf file at the bottom. The filename tells you the model and the quantization, which is the metadata you need. ### 3. Copy it into the new tool For ToolPiper: `cp ~/.cache/lm-studio/models///.gguf ~/Library/Application\ Support/ToolPiper/models/`. For llama.cpp directly: put it anywhere and run `llama-server --model .gguf -ngl 99`. Copy rather than move until you have confirmed it works. ### 4. Generate something before you trust it Load the model in the new tool and run a real prompt, not just a load. A truncated copy can load and then behave strangely, and you want to find that out while the original is still on disk. ### 5. If you are going to Ollama instead Write a one-line Modelfile containing `FROM /full/path/to/model.gguf` and run `ollama create my-model -f Modelfile`. That copies the weights into Ollama's blob store, so watch the disk and delete the original only once the model runs. Do one at a time. ### 6. Reclaim the space Once everything you care about is in its new home and generating, delete the originals from the LM Studio models directory. If you are removing the app too, [the leftovers list](/blog/uninstall-lm-studio-mac) covers the rest, most of which is small. ## FAQ ### Does LM Studio have an export function? It does not need one. Models are stored as plain GGUF files with their original names, in a directory the app lets you change, so getting them out is a copy. That is the opposite of the situation with content-addressed stores, where the weights are real GGUF bytes under sha256 filenames and recovering them takes manual digest mapping. ### How do I move models from LM Studio to Ollama? Write a Modelfile with a single line, `FROM /full/path/to/model.gguf`, then run `ollama create my-model -f Modelfile`. Ollama copies the weights into its own content-addressed store, so your disk usage roughly doubles until you delete the source file. Do one model at a time and confirm each runs before deleting anything. ### Will my chats and settings transfer? No. Conversation history, per-model presets and any prompt template you overrode are app state stored under ~/Library in a layout specific to LM Studio, and no local AI app reads another's. If a particular conversation matters, copy the text out before you uninstall. The model files carry their own chat template in GGUF metadata, so that part travels on its own. ### Do I need to convert GGUF files for a different app? No. GGUF is a standard container and it carries the architecture, quantization and chat template in its header, so any llama.cpp-based tool reads everything it needs from the file. The only case that needs work is importing into a tool with its own store, which is a copy into that store rather than a format conversion. ### Can I keep LM Studio installed while I try something else? Yes, and it is the sensible way to do this. Copy rather than move, so both tools see a working library, and delete the originals once you are sure. LM Studio's model browser is the best in the category, so keeping it around purely for discovery while another app does the running is a reasonable end state rather than an unfinished migration. ### Where does ToolPiper put the models I move over? ~/Library/Application Support/ToolPiper/models/, as plain named GGUF files. Drop a file in and it appears in the model picker. There is no import step and no manifest, which means leaving again someday would need no guide either.