Status: live since v0.9.2 (16 August 2026), on by default. This page is the contract: it went up months before the code so anyone could argue with it, and it changes in the same release as the behaviour, never after.
Why we want this at all
Ollama Herd is a free, open-source hobby project. Nobody is selling your data because nobody is selling anything. But we are genuinely flying blind: we do not know how many people run it, which models they actually use, or which errors they actually hit. That means we guess at what to fix, and we guess badly.
There is no company behind this, no paid tier, no ads, no investors, and no accounts. Nothing is being monetized, now or later. A small amount of usage data makes the project better for everyone who uses it, and it goes straight back out: the aggregates are public at /stats, so the community that generated the numbers sees the same thing we do. The code that sends it is open source too, so you do not have to take this page's word for it: read the sender.
On by default, and one line to turn off
Usage reporting is enabled by default, with a notice on first start telling you it is on and how to turn it off. One line on the machine that runs the router turns it off permanently:
FLEET_NODE_TELEMETRY=falseWhy on by default? Because when it is off by default, roughly nobody turns it on, and the handful who do are not a representative herd. We would end up guessing. Homebrew and a lot of other open-source tools land in the same place for the same reason.
On by default does not mean public. Left alone, your install is a number in a total. No name, no row, nothing anyone can point at and say that one is yours. Giving your herd a name is a separate thing you have to go and do, and we are never going to do it for you.
History: this page first proposed opt-in. We changed our minds before writing any of the code, and said so here rather than quietly editing the plan. v0.9.2 was the first release to send anything.
One herd, not one machine
A fleet reports once, from the router, not once per machine. The router is the only part that knows your three machines are one herd, so it is the part that sends. That fixes a counting problem: a 3-machine fleet used to look like three separate people, and "active installs" quietly meant "active machines".
Inside that one report, each machine gets a line of its own, so we can tell one big herd from three small ones. Totals like machine count and memory are added up from those lines rather than sent as a number we have to take on faith.
- prompts and completions
- hostnames
- file paths
- raw error text
- install_id, a random UUID
- agent_version and day
- per model: request and token counts, p50 and p95 latency
- error counts by fixed category
- a nickname, only if you set one
- device_id, a 16-character hash, not a hostname
- chip, memory_gb, cores
- Ollama and MLX versions
- requests served that day
Exactly what is sent
One request per day, containing a daily summary of the previous day. Nothing streams in real time, and nothing is sent per request.
| Field | Example | Why |
|---|---|---|
install_id | a random UUID | Count active herds and retention without knowing who you are |
agent_version | 0.9.5 | Know which versions are in use before changing or deprecating anything |
day | 2026-08-14 | Day granularity only, never timestamps |
model | qwen3.6:27b | Which models people actually run, so testing targets reality |
| request / token counts | 412 | Rough scale of real-world use |
| latency summary | p50, p95 | Whether routing is helping on real hardware |
| error counts by category | context_too_long: 3 | Which failures are common enough to prioritize |
Then one line per machine in the herd:
| Field | Example | Why |
|---|---|---|
device_id | a1b2c3d4e5f6a7b8 | Tell your machines apart from each other. Not a hostname: see below |
chip | Apple M3 Ultra | Which hardware people actually run on: the CPU name the operating system reports. On Linux with an NVIDIA card, the first GPU's model name is added (for example <CPU name> + NVIDIA GeForce RTX 4090) |
memory_gb | 512 | The single number that decides which models fit |
cores | 32 | Rough sense of the hardware mix |
ollama_version | 0.32.13 | Whether we can require a newer Ollama without stranding people |
mlx_version | 0.31.3 | Same question for MLX. Absent if you do not have it installed |
requests | 7494 | Whether routing spreads work or piles it on one machine |
Those runtime versions are the honest reason this exists. "Can we require Ollama 0.32.7?" is a question we currently answer by guessing, and guessing wrong means breaking someone's setup for no reason.
Error categories are a fixed list (context_too_long, vram_exceeded, connection_error, and similar). Raw error text never leaves your machine, because raw errors contain paths, model names, and occasionally prompt fragments.
What is never sent
- Prompts and completions. Not sampled, not hashed, not truncated. Never.
- Your hostname. Machines get named things like
johns-macbook. A randominstall_idis used instead, and there is a test that fails the build if a hostname ever appears in a payload. - Anything a machine could be recognized by. The per-machine
device_idis a hash of your herd's randominstall_idplus the node name, cut to 16 characters. It cannot be turned back into a name, and because your herd's own random id is mixed in, the same Mac in someone else's herd produces a completely different value. It identifies a machine within your herd and is meaningless outside it. Our server rejects anything that is not 16 hex characters, so a bug on the sending side gets an error rather than quietly filing your hostname. - File paths, IP-derived identity, account details. There are no accounts.
- Raw error strings, per above.
- Request tags, unless separately enabled.
This is enforced structurally, not by good intentions: the payload builder filters against an explicit allow-list of field names, and the test suite fails if a contributor adds a field without adding it to that list and to the test.
Nicknames, and the leaderboard
You can give your herd a name, and that name is the only thing you choose that shows up in public. We tell you it is going public before you set it.
If you do not set one, herds running v0.9.4 or newer are listed under a generated handle instead, like herd-7f3a2b. It is the first six characters of a hash of your random install id, so it is stable enough to hold a leaderboard position and tells nobody anything about you or your hardware. We do not publish the install id itself, because that is the key you would use to ask us to delete you.
Names are capped at 30 characters and limited to letters, numbers, spaces and - _ . A longer name is shortened and anything outside that set is dropped, rather than the whole day's report being thrown away over it. Your usage data is the part that matters; the name is decoration.
Most of what we publish back is aggregate: total installs, herd sizes, which models are popular, common error categories (all on /stats). Installs on v0.9.3 and older only ever appear inside those totals.
Then there is the leaderboard, which is just for fun. Biggest herd, most machines, that sort of thing. It ranks on hardware rather than how much you use it, partly because anyone can point curl at our endpoint and claim a billion requests, and partly because "I bought more Macs" is a funnier thing to compete over. Names appear as soon as you set one, and we remove anything that turns out to be unpleasant. None of it is verified, so enjoy it in that spirit.
Those hardware totals are added up from your machines' individual lines, so the total always matches the parts. A machine you retire stops reporting and leaves the total within 30 days, without you having to tell us.
Not interested in a name? Do nothing, and you appear as a handle rather than as something you picked. Not interested in being listed at all? FLEET_NODE_TELEMETRY=false is the honest answer today, and it also stops you contributing to the totals. We would rather say that plainly than imply a finer switch exists. A listed-but-unnamed toggle is the next thing we want to build here.
This changed in v0.9.4. Earlier versions were told the leaderboard would never know they existed, so they are never listed, even now. Only installs that have seen the first-run notice describing this can appear, which is why the cutoff is a version rather than a date.
How to say no, and how to change your mind
Set this on the machine that runs the router (herd), before starting it, and nothing is ever sent, including the first run. The router is the only process that sends, so setting it on the other machines alone changes nothing:
FLEET_NODE_TELEMETRY=falseThe install_id lives in a plain file under ~/.fleet-manager/ on whichever machine runs the router. Delete it and you are a new herd; delete it and opt out and you are simply gone. Because every device_id is derived from that file, deleting it also makes every machine in the herd unrecognizable, which is the useful side effect of salting them with it. We will also honor deletion by install_id on request, which is the practical upside of a random identifier: it is easy to find and easy to remove.
How long it is kept
Daily rows, both per-herd and per-machine, for 365 days, then aggregated and the raw rows dropped. Aggregates carry no herd or machine identifier.
Why we say pseudonymous, not anonymous
A random UUID that persists across runs is not truly anonymous, because it links one day's data to the next. Under European data-protection guidance that makes it pseudonymous data, and calling it anonymous would be a convenient overstatement. So we do not. We hold no way to connect an install_id to a person, and we do not want one.
Tell us if this is wrong
This page went up before the code so it could be argued with, and it still can be. If a field here should not be collected, if the opt-out is unclear, or if the page and the code that sends it ever disagree, please open an issue. A disagreement between the two is a bug, and the code is what gets fixed.
See also the privacy policy, which describes what the website and this project collect today.