--- title: "Ollama Export on Mac: Get Your Models Out of the Blob Store" description: "Ollama has no export command - the request was closed \"not planned\" in 2026. Here's the manual path from sha256 blobs to plain GGUF files, step by step." date: 2026-06-09 author: "Ben Racicot" tags: ["Ollama", "Migration", "Text Generation", "macOS", "GGUF", "Local LLM"] type: "article" canonical: "https://modelpiper.com/blog/migrate-from-ollama-mac" --- # Ollama Export on Mac: Get Your Models Out of the Blob Store > Ollama has no export command - the request was closed "not planned" in 2026. Here's the manual path from sha256 blobs to plain GGUF files, step by step. ## TL;DR There is no ollama export. The GitHub issue asking for one sat open since 2023 and was closed "not planned" in April 2026. But the weights Ollama downloaded are standard GGUF bytes inside sha256-named blobs, so you can get them out by hand: find the blob with ollama show --modelfile, copy it to a real filename, and point any llama.cpp-compatible tool at it. This guide walks the whole migration, including what doesn't transfer. 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](https://github.com/ollama/ollama/issues/335), 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. Every model Ollama downloaded to your Mac is sitting in `~/.ollama/models/blobs/` as standard GGUF bytes under a sha256 filename. You can recover every gigabyte of it. 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-`, resolved through manifest files under `~/.ollama/models/manifests/`. 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 --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](/blog/ollama-vs-llamacpp-benchmark-mac), 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'd rather 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: re-download as plain GGUF and skip the surgery If your models are standard library pulls (and for most people they are), re-downloading is honestly less work than blob extraction. ToolPiper pulls models from Hugging Face as plain, named GGUF files into a folder you can see - `~/Library/Application Support/ToolPiper/models/` - with RAM-aware suggestions so you don't grab something your Mac can't hold. The downloads run in the background. 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 b9533, stated publicly), unlimited downloads, multi-model switching, the local OpenAI-compatible API, embeddings, and an MCP server with over 300 tools. No account, no caps, no terminal. While you transition, ToolPiper also connects to your still-running Ollama as a backend, so both libraries are usable from one interface until you're ready to retire the second process. ## Cleaning up Once everything you care about is exported or re-downloaded: `ollama rm` each model, quit the menu bar app, and delete `~/.ollama/` and the app itself. 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](https://modelpiper.com/download) - a starter model downloads automatically, and your exported files drop straight into its models folder. _For the full head-to-head before you switch, see [Ollama vs ToolPiper](/blog/ollama-vs-toolpiper). For what the two engines do with identical files, see [our same-bytes benchmark](/blog/ollama-vs-llamacpp-benchmark-mac)._ ## Steps ### 1. List what you have and pick the keepers Run `ollama list` to see every installed model with its size. Disk is the constraint during migration since copies briefly double a model's footprint, so migrate the large ones one at a time. ### 2. Find the weights blob Run `ollama show llama3.2 --modelfile` (substitute your model). The printed `FROM` line is the absolute path of the weights blob, something like `~/.ollama/models/blobs/sha256-dde5aa3f...`. That multi-gigabyte file is your model. If you prefer the manifest route, the JSON under `~/.ollama/models/manifests/` lists the same digest on the layer with mediaType ending in `.model`. ### 3. Copy it to a real filename Copy the blob to a name that says what it is: `cp ~/.ollama/models/blobs/sha256-dde5... ~/Models/Llama-3.2-3B-Instruct-Q4_K_M.gguf`. Copy, don't symlink - Ollama's cleanup deletes blobs under your links. Model name and quantization are in the GGUF metadata if you've lost track of which blob is which. ### 4. Load it in the new tool For ToolPiper: move the file into `~/Library/Application Support/ToolPiper/models/` and it appears in the model picker, ready to load. For llama.cpp directly: `llama-server --model ~/Models/Llama-3.2-3B-Instruct-Q4_K_M.gguf -ngl 99`. Run a quick chat to confirm the model behaves before you delete anything. ### 5. Reclaim the disk Once verified: `ollama rm llama3.2` removes the model from Ollama's store. When the last model is out, quit Ollama, delete the app and `~/.ollama/`, and the migration is done. ## FAQ ### Does Ollama have an export command? No. The CLI has create, pull, rm, run, and friends, but no export. The GitHub issue requesting import/export (ollama/ollama#335) was opened in August 2023, absorbed several duplicate requests over the years, and was closed "not planned" in April 2026. The manual blob-copy path in this guide is the way out. ### Are Ollama models just GGUF files? The weights are, yes. Ollama stores them as content-addressed blobs named `sha256-` with the GGUF bytes unmodified inside - we verified this by loading blob files directly in upstream llama-server. What's proprietary is the store layout: the naming, the manifests, and the Modelfile parameter layers around the weights. ### Can I point llama.cpp directly at an Ollama blob? Yes - llama-server loads a blob by its sha256 path like any GGUF, and in our benchmarking it generated identically to a normally-named copy of the same file. For anything longer than an experiment, copy the blob to a real .gguf filename first so Ollama's pruning can't delete it out from under you. ### Will my custom Modelfiles transfer? The weights transfer; the customizations don't. System prompts, parameters like num\_ctx, and template overrides live in Ollama's manifest layers, not in the GGUF, so you'll re-apply them in the new tool. Chat templates usually survive because upstream GGUF files carry their template in metadata. ### Is it easier to just re-download models instead? Usually, if your models came from the standard library. ToolPiper downloads the same models from Hugging Face as plain named GGUF files, so there's nothing to extract or rename - the trade is download time and temporary disk overlap against the blob archaeology above. Custom or hard-to-find quantizations are the case where blob extraction earns its keep.