--- title: "Ollama-Compatible API on Mac: Keep Your Tools, Swap the Server" description: "ToolPiper serves the Ollama API on localhost:11434. Point the Ollama CLI, ollama-python, the OpenAI SDK, or Hollama at it - no code changes. Native Mac app, no account." date: 2026-06-11 author: "Ben Racicot" tags: ["Ollama", "API", "Text Generation", "Developer", "Privacy", "macOS"] type: "article" canonical: "https://modelpiper.com/blog/ollama-compatible-api-mac" --- # Ollama-Compatible API on Mac: Keep Your Tools, Swap the Server > ToolPiper serves the Ollama API on localhost:11434. Point the Ollama CLI, ollama-python, the OpenAI SDK, or Hollama at it - no code changes. Native Mac app, no account. ## TL;DR ToolPiper answers the Ollama wire API on localhost:11434 - an opt-in, loopback-only listener backed by its own embedded llama.cpp engine. Point anything that already talks to Ollama at it and the full client loop works: list, show, ps, streamed chat and generate, embeddings, pull, and delete. Drop-in verified with the Ollama CLI, the official ollama-python and OpenAI SDKs, and Hollama. ToolPiper is a native Mac app, not a terminal binary, and it isn't out of beta yet - the compatibility layer shipped first because keeping your existing tooling working is the whole point of switching. You've already evaluated the local model runners and made up your mind. The blocker was never which one runs Llama 3.2 a few tokens faster. It's that half your stack has `localhost:11434` hardcoded - the editor plugin, the Python script you wrote last month, the chat client you finally got configured the way you like it - and switching runners means rewiring every one of them. So most people don't switch. They stay on the tool their other tools already speak, and the better app loses by default. ToolPiper removes that cost. It doesn't ask your tooling to learn a new protocol. It serves the Ollama API itself, on the port your tools already point at, backed by its own engine. You keep your tools. You swap the server underneath them. ## What is the Ollama API, and why is it hardcoded everywhere? The Ollama API is the REST interface Ollama serves on `localhost:11434` - endpoints like `/api/chat`, `/api/generate`, and `/api/tags`. Hundreds of tools target it directly, so a tool that "supports Ollama" usually means it has that port and path scheme baked in. Ollama shipped a clean local-inference API early and it became the de facto standard for talking to a model on your own machine. The official client libraries - `ollama-python`, `ollama-js` - wrap those exact endpoints. Editor extensions, chat front-ends, and automation scripts all assume the same shape. The port is the integration. That install base is real, and it's the strongest thing Ollama has going for it on a Mac. The catch is that the assumption runs one way. Tools speak Ollama's dialect, so the runner that serves that dialect wins the integration regardless of what the app around the runner is like. That's the lock-in we wanted to break - not by asking everyone to rewrite their integrations, but by answering the protocol they already use. ## What does ToolPiper's Ollama-compatible API serve? ToolPiper answers the Ollama wire API on `localhost:11434` through an opt-in, loopback-only listener (Settings → General, off by default), backed by its own embedded `llama-server` engine. The full client loop works: `list`, `show`, `ps`, streamed `chat` and `generate`, embeddings, `pull`, and `delete`. This is a real compatibility surface, not a partial shim. We pinned the contract to a specific Ollama release (0.23.4) and capture its responses as fixtures, so the JSON your client gets back matches the shape it expects field for field. A streamed `ollama run` triggers an on-demand model load and streams tokens the same way it does against Ollama. A `pull` fetches the weights and a `delete` removes them. The model picker, the keep-alive, the per-model memory - all of it answers. Two deliberate differences. First, `pull` resolves against Hugging Face and a curated name list, not Ollama's registry, because ToolPiper stores plain GGUF files instead of a content-addressed blob store. Second, Modelfile operations - `create`, `push`, `copy`, and the raw blob endpoints - are rejected with a message that names the first-party replacement, because Modelfile semantics don't exist in ToolPiper and pretending they did would be worse than saying so. If your client only reads and runs models, you won't touch either edge. Configurable clients that let you set a base URL can also point at `http://127.0.0.1:9998/legacy/ollama`, the same compat layer mounted on ToolPiper's main port. The `:11434` listener exists for the clients that can't be reconfigured at all. ## Which Ollama clients actually work with ToolPiper? Drop-in verified with the Ollama CLI, the official ollama-python and OpenAI SDKs, and Hollama. Each one ran its real scenarios against ToolPiper's listener with no code changes. We didn't want to claim compatibility from a passing unit test, so we ran the actual clients people use: **The `ollama` CLI (0.30.7).** `ollama list`, `show`, and `ps` return ToolPiper's models. `ollama run` streams a response with an on-demand load on first use. A full `pull` → `run` → `rm` round-trip completes against the native engine. **The official `ollama-python` library (0.6.2).** The same library tools import to talk to Ollama, pointed at ToolPiper, returns streamed chat and embeddings unchanged. **The official OpenAI Python SDK (2.41.1).** ToolPiper's OpenAI-compatible surface answers the SDK most tools reach for first. **Hollama (0.35.4), in real Chrome.** A browser client, so this also exercises CORS - the preflight and headers a browser sends, answered without a config flag. Four clients are not the entire Ollama ecosystem, and we won't pretend they are. The list widens as we verify more, and every entry is a scenario we actually ran, not a logo on a slide. ## Why does ToolPiper mark its own Ollama API "legacy"? Every response from the compatibility layer carries an RFC 9745 `Deprecation` header and a `Link` header pointing at ToolPiper's first-party `/v1/` API. The Ollama dialect is the on-ramp. The `/v1/` API is where new integrations should land. The compat layer was born deprecated, on purpose. "Legacy" here is a lifecycle statement, not a dig - the Ollama API did its job and earned its install base, and we serve it so the install base can move without friction. But we tell every caller, in-band, that there's a successor: ToolPiper's own OpenAI-compatible `/v1/` surface, which is the dialect most tools already speak as their primary anyway. That's the honest version of a migration path. Bring your Ollama-shaped tools over today, unchanged. When you build something new, build it against `/v1/`. The compatibility layer stays until it stops earning its keep, and then it gets deleted - which is exactly what you'd want a migration on-ramp to do. ## It's still in beta. Why did the compatibility layer ship first? ToolPiper is pre-1.0 and already serves the entire Ollama client loop, deprecated by design, with a pinned wire contract and a four-client validation matrix. The compatibility layer isn't a roadmap item - it shipped before the product left beta. That ordering is the point. A model runner is judged on the app around the model, and ToolPiper is a native macOS app written in Swift, not a Go binary you drive from a terminal. Download a model, load it, switch between several, watch per-model memory, chat - those are buttons and panes, not `OLLAMA_*` environment variables and Modelfiles. The runner underneath is the upstream `llama-server` binary embedded directly, build number printed on the [pricing page](/pricing), so the engine that runs your models is the same llama.cpp engine, unmodified. We could have left protocol compatibility for after launch. We didn't, because a tool that's still in beta and already speaks your existing tooling's protocol exactly - contract-tested against pinned fixtures, gated in CI, and labeled deprecated in its own response headers - is the version of "we take integration seriously" that you can check rather than take on faith. The free tier is the whole runner: unlimited model downloads, multi-model switching, the local OpenAI-compatible API, embeddings, chat, transcription, the visual pipeline builder, and an MCP server with over 300 tools. No account, no caps, no terminal. ## Where does Ollama still win? Ollama runs on macOS, Linux, and Windows, deploys headless in Docker, and has the larger integration ecosystem today. ToolPiper is macOS-only and single-user. If you need Linux, Windows, or server-side deployment, use Ollama. ToolPiper is built on Metal, the Neural Engine, and macOS frameworks that have no cross-platform equivalents, so it's a Mac app and only a Mac app. Ollama runs as a background service on servers, in containers, behind a load balancer - ToolPiper is a desktop app for one person at one machine. Ollama is MIT-licensed open source; ToolPiper is a commercial product whose entire runner is free, with the open-source llama.cpp engine inside it and the build number stated publicly. And if your workflow is built on Modelfiles, that's genuinely Ollama's model, not ours. For local inference on a Mac, driven from a real app, with your existing tools still pointed at `localhost:11434` - that's the case ToolPiper is built to win, and the compatibility layer is how you switch without paying the rewiring tax. Download [ToolPiper](/toolpiper) at [modelpiper.com/download](https://modelpiper.com/download), flip on the Ollama compatibility listener in Settings → General, and point your existing client at `localhost:11434`. A starter model downloads automatically, so there's something to talk to in about a minute, no account required. _Part of our [Ollama series](/blog/best-ollama-frontend-mac). See also the full [Ollama vs ToolPiper comparison](/blog/ollama-vs-toolpiper) and the [guide to getting your models out of the blob store](/blog/migrate-from-ollama-mac)._ ## FAQ ### Does ToolPiper actually serve the Ollama API, or just an OpenAI-compatible one? Both, on different ports. ToolPiper has always served an OpenAI-compatible API. The Ollama-compatible layer is separate: an opt-in, loopback-only listener on localhost:11434 (Settings → General, off by default) that answers Ollama's own wire format - /api/chat, /api/generate, /api/tags, embeddings, pull, and delete - so tools that hardcode the Ollama dialect work without changes. Configurable clients can also use http://127.0.0.1:9998/legacy/ollama. ### Which Ollama clients are verified to work? The Ollama CLI (0.30.7), the official ollama-python library (0.6.2), the official OpenAI Python SDK (2.41.1), and Hollama (0.35.4) in real Chrome. Each ran its real scenarios against ToolPiper's listener with no code changes - the CLI did list/show/ps, a streamed run with on-demand load, and a pull-run-remove round-trip. Four clients aren't the whole ecosystem, and the verified list widens as we test more. ### Why is ToolPiper's Ollama API marked deprecated? On purpose. Every response carries an RFC 9745 Deprecation header and a Link header pointing at ToolPiper's first-party /v1/ API. The Ollama dialect is the migration on-ramp so your existing tools keep working, and /v1/ is where new integrations should land. "Legacy" is a lifecycle statement, not an insult - the layer stays until it stops earning its keep, then it gets deleted. ### Does the compatibility layer work even though ToolPiper is in beta? Yes. ToolPiper is pre-1.0 and the layer shipped before launch, contract-tested against fixtures pinned to Ollama 0.23.4, gated in CI, and validated against four real clients. Keeping your existing tooling working is the reason to switch, so the compatibility surface came first rather than after. ### Can I use my existing Ollama models through the API? The compat layer's pull resolves against Hugging Face and a curated name list rather than Ollama's registry, because ToolPiper stores plain GGUF files instead of a content-addressed blob store. To bring weights you've already downloaded with Ollama, re-pull them as GGUF or extract the blobs by hand - our migration guide covers both paths. Once they're in ToolPiper, every client on :11434 sees them. ### What doesn't the Ollama-compatible layer do? Modelfile operations - create, push, copy, and the raw blob endpoints - are rejected with a message naming the /v1/ replacement, because Modelfile semantics don't exist in ToolPiper. If your workflow is built on Modelfiles, that's Ollama's model. Read-and-run clients (chat, generate, list, pull, delete) are fully covered.