Status: shipped in v0.9.2, 16 August 2026. It is on by default. This page went up months before the code did, so that anyone could argue with the contract while changing it was still cheap, and it changes in the same release as the behaviour rather than after it.
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.
A small amount of usage data makes the project better for everyone who uses it. And we intend to give it straight back: aggregate statistics published publicly, so the community that generated the numbers can see them too.
It will be on by default, and anonymous
Anonymous usage reporting will be enabled by default, with a notice on first start telling you it is on and how to turn it off. One line in your shell 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.
We said opt-in here first and then changed our minds, before writing any of the code. Nothing has ever been sent by any release, so nobody got surprised. Leaving the old wording up would have been tidier for us and worse for you.
One herd, not one machine
A fleet reports once, from the router, not once per Mac. The router is the only part that knows your three Macs are one herd, so it is the part that sends. That fixes a counting problem: a 3-Mac 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.
Exactly what would be 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.2 | 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 Macs apart from each other. Not a hostname: see below |
chip | Apple M3 Ultra | Which Apple Silicon people actually run on |
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 Mac |
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. That is the one thing that ever shows up in public, it is entirely your call, and we will tell you it is going public before you set it.
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, which models are popular, common error categories. Anonymous installs 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 Mac you retire stops reporting and leaves the total within 30 days, without you having to tell us.
Not interested? Do nothing. Staying anonymous is the default and the leaderboard will never know you exist.
How to say no, and how to change your mind
Set this before starting a node and nothing is ever sent, including the first run:
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 exists before the code so it can be argued with. If a field here should not be collected, if the opt-in flow is unclear, or if something looks like a mistake, please open an issue. It is far easier to change a plan than a shipped default.
See also the privacy policy, which describes what the website and this project collect today.