Ollama Export on Mac: Get Your Models Out of the Blob Store

Try to leave Ollama and you hit a one-way door. Importing a GGUF into Ollama is a one-line Modelfile. Getting one out has no command at all - ollama export doesn't exist, and the GitHub issue requesting it, open since August 2023 with years of +1s, was closed "not planned" in April 2026.

The good news is that the door is only locked from the inside by naming, not by format. The GGUF models Ollama downloaded to your Mac are sitting in ~/.ollama/models/blobs/ as standard GGUF bytes under a sha256 filename, and you can recover every gigabyte of them. One caveat: models published for Ollama's MLX engine, its default on Apple Silicon since v0.30, may be stored in a format other than GGUF, so check a blob before relying on this path for them. Here's how, and here's what won't come along.

Where does Ollama store models on a Mac?

Ollama stores model weights at ~/.ollama/models/blobs/ as content-addressed files named sha256-<digest>, resolved through manifest files under ~/.ollama/models/manifests/. For GGUF models the weights themselves are standard GGUF - only the naming and the manifest layer are Ollama-specific.

Each model in your library is really a manifest pointing at several blobs: one multi-gigabyte blob for the weights, plus small ones for the license, chat template, and parameters. The weights blob is the one you want, and there are two ways to find it.

How do you export a model from Ollama?

Run ollama show <model> --modelfile and read the FROM line - it prints the absolute path of the weights blob. Copy that file to a name ending in .gguf, and any llama.cpp-compatible runtime can load it directly. In our testing, a copied blob loaded and generated identically to the original download.

We didn't take that on faith. While benchmarking Ollama against upstream llama-server, we pointed llama-server directly at Ollama's blob files - the literal sha256-named paths - and they loaded and served tokens like any other GGUF, because they are GGUF. The walkthrough below is the same move with a friendlier filename.

The migration, step by step

The steps below move one model. Repeat for whatever's worth keeping, then reclaim the disk space at the end. If you are moving to ToolPiper, you can skip the archaeology entirely; the section after this one is for you.

What doesn't transfer?

Honesty section. Three things stay behind:

Modelfile customizations. If you built custom models with ollama create - a system prompt, a temperature, a num_ctx - those live in Ollama's manifest layers, not in the GGUF. You'll re-apply them in whatever tool you land on. The chat template usually does travel, because upstream GGUF files embed their template in metadata.

The registry names. llama3.2:latest is an Ollama-ism. Your exported file is just a file, which is rather the point.

Symlink setups. Don't be tempted to symlink into the blob store instead of copying - ollama rm and Ollama's pruning delete blobs underneath your links. The community tools that linked blobs into other apps fought this for years, and the maintained one, gollama, dropped its linking feature as more trouble than it was worth. Copy, then delete the original.

The alternative: let ToolPiper adopt the library in place

ToolPiper reads Ollama's library itself: it finds ~/.ollama/models (or wherever OLLAMA_MODELS points), reads the manifests, and asks once to adopt, with the model count and total size on the button. Each model's GGUF weights are hardlinked into ToolPiper's own store, ~/Library/Application Support/ToolPiper/models/, under a real name. No bytes are copied, nothing is written into ~/.ollama, it is instant at any size, and the adopted models survive ollama rm and Ollama's pruning. ToolPiper adopts GGUF weights only. One thing to know: once ToolPiper holds the second link, ollama rm reports success but the disk space comes back only when you delete the model in ToolPiper too.

For models you do not have yet, ToolPiper downloads from Hugging Face as plain, named GGUF files into that same folder, with RAM-aware suggestions so you don't grab something your Mac can't hold. There's no manifest to decode because nothing was ever hidden.

That's the storage model this whole guide exists to work around, applied from day one: your models are ordinary files with ordinary names, and leaving ToolPiper someday would need no guide at all.

The runner around those files is free - the native llama.cpp engine (upstream build b11669, stated publicly), unlimited downloads, multi-model switching, the local OpenAI-compatible API, embeddings, speech, and an MCP host, with 206 of ToolPiper's 468 native tools free. No account, no caps, no terminal. You are not moving to a frontend that still needs Ollama underneath: ToolPiper bundles the engine, so once your models are adopted there is no second process to keep running. It also answers the Ollama API itself on :11434, so the tools you already pointed at Ollama keep working against ToolPiper without being reconfigured.

Cleaning up, and the order that matters

Verify before you delete anything. Load every exported file in whatever tool you are moving to and generate at least one token from each. An export that silently produced a truncated or wrong-sized file looks identical to a good one until something reads it, and the originals are the only copy you have until you have checked. Only then: ollama rm each model, and quit the menu bar app.

⚠️ Do not rm -rf ~/.ollama as a first move. That directory holds more than blobs. ~/.ollama/id_ed25519 is the keypair identifying you to Ollama's registry, and if you have ever pushed a model it is not something you can simply regenerate. server.json holds preferences you set deliberately. If you want the disk space back, delete ~/.ollama/models/, which is the part that is actually large, and leave the rest until you are certain you are not going back. The blobs directory is usually the largest AI-related folder on a Mac that's run Ollama for a while - ours was holding about 9GB for three models. Your exported GGUF files are now visible, named, and portable to any tool that speaks the format, which is every local inference tool that matters.

Download ToolPiper at modelpiper.com/download - it offers to adopt your Ollama library when it finds one, so there is nothing to export first.

Part of our Ollama series. For the full head-to-head before you switch, see Ollama vs ToolPiper. For what the two engines do with identical files, see our same-bytes benchmark.