The case against Ollama: a thin wrapper with thick problems

What happened

A post titled "Stop Using Ollama" hit the front page of Hacker News this week with 454 points and a long comment thread, reigniting a fight that's been simmering in the local-LLM community for the better part of a year. The author — writing at sleepingrobots.com — lays out a catalogue of grievances: Ollama is a Go wrapper around llama.cpp that does not make its upstream obvious; it publishes distilled fine-tunes under the names of the frontier models they were distilled from; it pulls model weights through its own registry (`registry.ollama.ai`) rather than Hugging Face; and it phones home by default for version checks.

None of these claims are new. What's new is that the pile has gotten tall enough that a single post can connect them into a coherent argument. The thread on HN quickly split into two camps: practitioners who've been frustrated by the `ollama pull deepseek-r1` experience shipping a 4.7GB Qwen-2.5-7B distill instead of the 671B-parameter mixture-of-experts original, and users who argue Ollama's `brew install` ergonomics are the reason local inference broke out of the hobbyist ghetto at all.

The specific provenance complaint is the one worth taking seriously: when Ollama's library lists `deepseek-r1:7b`, a user reasonably assumes they are running DeepSeek's R1 model, not a Qwen base that has been fine-tuned on R1's chain-of-thought traces. DeepSeek's own model card makes the distinction; Ollama's UI does not surface it until you read the tag description. For a platform whose entire value proposition is making model selection frictionless, the friction it has removed is the friction of knowing what you're actually running.

Why it matters

The llama.cpp attribution question is more interesting than it looks. Ollama does credit llama.cpp in its README and license — this isn't a rug-pull — but the project has built a brand that many users experience as the inference engine itself. Georgi Gerganov's team at ggml-org ships the actual CUDA, Metal, and CPU kernels; Ollama adds a model registry, a daemon, a REST API, and a `Modelfile` DSL. Reasonable people disagree on how much of the product that represents. The HN thread surfaced a recurring pattern: new users file performance bugs against Ollama that are really llama.cpp bugs, and the fix cycle has to route upstream. When the wrapper has more GitHub stars (130k+) than the engine (70k+), something has gotten inverted in how credit flows.

Then there's the registry question, which is the one with real operational teeth. Pulling a model from `registry.ollama.ai` is not the same as pulling one from Hugging Face. Hugging Face publishes SHA256 hashes, git-lfs history, and a model card with a clear authorship chain. Ollama's registry re-hosts quantized GGUFs with its own tags and its own digest format. If you're at a company where the security team has to answer "where did these weights come from," the Ollama answer is "an HTTP endpoint with a manifest" — which is true of Docker Hub too, but Docker Hub isn't the default way engineers pull cryptographically-sensitive artifacts into inference pipelines.

The telemetry complaint is the weakest link in the essay. Ollama does a version check against its update server on startup; it does not, as far as the code shows, exfiltrate prompts. The author concedes this, but uses it as a jumping-off point to argue that the *pattern* of a daemon that phones home by default is the wrong default for a tool whose appeal is running models off the internet. That's a defensible position — LM Studio, llamafile, and raw llama.cpp all let you air-gap more cleanly — but calling it a privacy incident overstates what's actually in the packet capture.

The community reaction tracked the author's argument closely. Top comments cited the Qwen-distill-as-R1 naming as the strongest grievance, with several engineers reporting that `ollama list` output had confused teammates into thinking they'd deployed the full R1 model in production. A minority defended Ollama on the grounds that `brew install ollama && ollama run llama3` is still the shortest path from zero to a chat loop, and that asking hobbyists to compile llama.cpp with the right BLAS flags is a regression for the ecosystem.

What this means for your stack

If you're evaluating where to put local inference in 2026, the honest answer is that Ollama is fine for prototyping and hostile for production. For anything you're going to deploy, pin the model by Hugging Face repo and revision hash, pull the GGUF yourself, and run llama.cpp's `server` binary directly — you lose the Modelfile convenience and gain audit-ability. The `llama-server` REST API is OpenAI-compatible enough that your client code doesn't change.

For local dev loops where you want the `ollama run` ergonomics, the mitigation is to stop trusting the short tag names. Always check `ollama show --modelfile` before you reason about a model's capabilities — if the base model line reads `qwen2.5` and the tag reads `deepseek-r1`, you know what you're actually running. Better still, push your team to use the full distill name (`deepseek-r1-distill-qwen-7b`) in code and documentation. This costs nothing and prevents the slow-motion reasoning failures that come from assuming a 7B distill can do what a 671B MoE can.

For the security-conscious, the alternatives are mature. llamafile ships a single executable that includes weights and runtime — trivial to audit and trivial to air-gap. LM Studio offers the same UX as Ollama with explicit Hugging Face provenance. vLLM and TGI remain the right choice for any serious serving workload. None of these have Ollama's first-run ergonomics, and none of them need to.

Looking ahead

The useful frame here is not "Ollama bad" but "Ollama is what happens when a convenience wrapper becomes a de facto standard faster than its governance can mature." The naming conventions, the registry-by-default, the thin attribution — these are the kinds of decisions that get locked in when a tool's install base outruns the thought someone put into its tag schema. The fix is not a boycott; it's the same fix as every other ecosystem-dependency question. Pin your versions, verify your hashes, read the modelfile, and don't confuse the wrapper for the engine underneath.