article2026-08-10by Ben Racicot

Migrate from LM Studio on Mac: Your Models Are Already Portable

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.

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.

Model Storage, Three Ways

	LM Studio	Ollama	ToolPiper
File names	Original GGUF names	sha256-<digest>	Original GGUF names
Default location	~/.cache/lm-studio/models	~/.ollama/models/blobs/	~/Library/Application Support/ToolPiper/models/
Directory is user-changeable	Yes, in the app	Via environment variable	Yes
Importing an existing GGUF	Drop it in the folder	Modelfile plus ollama create, which copies it	Drop it in the folder
Getting a model back out	It is already a file	No export command	It is already a file
Disk cost of importing	None	Roughly doubles until you delete the original	None

How to get started

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/<publisher>/<repo>/<file>.gguf ~/Library/Application\ Support/ToolPiper/models/. For llama.cpp directly: put it anywhere and run llama-server --model <file>.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 covers the rest, most of which is small.

Frequently Asked Questions

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.

LM StudioMigrationGGUFmacOSOllamaLocal LLM

Ollama Export on Mac: Get Your Models Out of the Blob StoreThe same job in the harder direction, with no export command Uninstall LM Studio on Mac: The Model Cache Does Not Go With the AppThe cleanup once the models are moved LM Studio Alternative: The Honest List (2026)Deciding where to move to, sorted by what you are replacing ToolPiper vs LM Studio: Which Local AI App Does Your Mac Need?The head-to-head, including where LM Studio stays ahead Which Local LLM on Mac: A Model Selection Guide for Apple SiliconDeciding what is worth carrying across

Migrate from LM Studio on Mac: Your Models Are Already Portable

Where are the models?

Moving to another llama.cpp-based tool

Moving to Ollama is the one direction that is harder

What does not transfer

Doing it, step by step

Landing in ToolPiper

Model Storage, Three Ways

How to get started

Inventory what you have

Find the file

Copy it into the new tool

Generate something before you trust it

If you are going to Ollama instead

Reclaim the space

Frequently Asked Questions

Related