Nineteen months of unsecured Ollama servers, reconstructed from the commit history of three scanners and then probed directly. Hundreds of them are not servers at all. They are one honeypot kit wearing an Ollama mask, built to catch the people scanning for open models. Another 365 carry a ransom demand for files that were never encrypted. The wallet has never received a satoshi.
Thousands of real machines have Ollama left open on the internet. Some of them, for years... we've got the receipts. This is what they are running, where, and for how long.
The buttons above switch to other slices: the share running an uncensored model, a 30B-plus model, or four-bit weights. Each frame counts a five-month window.
Each country's share of the exposed servers, stacked to 100%. Reading it as a share rather than a raw count cancels out the swings in how much the scanners covered at any moment, so what's left is the composition.
Servers grouped by the lab that trained the base model, not the model
name, so Qwen stays one line as it moves from 2.5 to 3 to 3.6. A server counts once per
vendor it hosts, so shares sum past 100%. A name claiming a closed-weights commercial
model, claude-3-opus:latest or gpt-4:latest, counts toward no
lab at all, because no lab shipped those as weights. gpt-oss is real and
still counts for OpenAI.
Exclude questionable drops every server that fails one of the
Chapter 2 tests: it reports the fixed phantom catalogue, advertises a closed-weights
model that cannot exist in Ollama, advertises a scratch name like test, or
reports a blob size that disagrees with the published one. The tests go by model name,
so a community re-upload that keeps a commercial model's name is caught with them.
Each lineage as a share of the exposed servers over time, so the survey's changing coverage cancels out. A lineage follows a model line through its generations , gemma3 into gemma4, qwen3 into qwen3.6 and 3.8, llama3 into the muse models, because tracking a single release only ever shows it being replaced. Pick any lineage to add or drop it.
ollama.com publishes a cumulative pull count for each of its official models. That counts downloads. This survey counts what is still installed on a server left open to the internet. Those are different acts, and the two populations are wildly different in size, so both sides are drawn as a share of the same universe: of every pull of an official model, what fraction is this one, against the same fraction of every official-model install we found. Only Ollama hosts are counted anywhere on this page.
The gap is the chart. A model far to the right of its download share is one people leave running; far to the left, one they pull and move on from.
A pull count only ever goes up, so over the whole library the oldest models win by having been there longest and nothing recent can rank at all. Published in the last year renormalises both sides over a recent cohort, which is where adoption is actually visible.
You generally have to update Ollama to run a newly published model: new architectures land in the daemon first. Each row below is one model. The diamond marks when it was published; the circles are the release dates of the Ollama daemons found serving it, sized by how many hosts. Where a circle sits far to the left of its diamond, somebody put a new model on an old machine, well after the box was built.
Daemon dates come from the tag history of the Ollama repository. Model
release dates come from
Artificial Analysis ,
deliberately not from ollama.com, whose date is a last-updated stamp that is wrong by
months and dates qwen3.5 and qwen3.6 to the same day when they are six weeks apart. Rows are the tagged name, since
qwen3.6:27b and qwen3.6:35b shipped six days apart. This covers
the hosts of the daily live probe that report a version and run a
model the catalogue dates.
Model sizes come from the tag when it states one, like
gpt-oss:120b. A :latest tag is resolved against ollama.com by
its manifest digest: llama3.2:latest shares a digest with
llama3.2:3b-instruct-q4_K_M, which names both the parameter count and the
quantisation.
Shown as a share of installs whose size is known. Coverage is under the chart.
How hard the weights are compressed. q4 is Ollama's
default for most models and dominates the chart. The deviations from it are the
interesting part.
Servers grouped by the /24 they sit in, a rough stand-in for one operator. Each column is a block size. The bar spans the middle half of lifespans, the line is the median, the whisker reaches the 10th and 90th percentiles. Lifespan rises with block size up to five servers, then falls.
Each circle is a day a model's server count jumped further than its own normal churn explains. Up is a block coming online, down is a block going offline. Height is how many robust deviations (MAD) the jump was, circle area is how many servers moved at once. Hover for the model and where the jump sits against its normal daily range.
Every server's lifespan, from its first sighting to its last. Most are gone within a week, but a stubborn tail stays reachable for months, and hundreds for more than a year.
Every sighting of a host, across the git scanners, FOFA, Shodan and our own re-probe, is a sample of how long it stayed reachable. Fit a survival curve on the window where sampling was dense and you get the chance a server is still up a given number of days after it first appears. Most exposures are gone in days. A small core persists for months. The shaded band is the model's confidence.
A single scanner only ever catches a slice of the live population on any given day, so the raw count understates it and jumps around with coverage. Feeding every host's sightings and its later liveness check into the survival model gives a smoother estimate of how many servers were probably alive each month. This is a modelled estimate from sampling, not a headcount, so read the shape rather than the exact number. The band is a 300-run bootstrap that also varies how long the persistent core is assumed to last, which is why it fans out in recent months where the estimate depends most on that assumption.
Each dot is a model. Across is how many hosts run it; up is the average library size of those hosts, meaning how many models they run in total. It opens on the whole record pooled; press play, or drag the slider, to run it month by month. The axes are fixed across the aggregate and every frame, so a dot moving is the model moving and not the scale changing.
The popular defaults sit on minimal single-purpose boxes, while cloud-proxied and specialised models ride on big multi-model rigs. Popularity anti-correlates with library size.
Running it over time separates the responder fleet from the real
baseline, which one snapshot cannot. During the 2025 wave openchat sits on
hosts that are 74–89% flagged by Chapter 2's tests with libraries of four to eight
models; once the wave recedes the hosts still running it are 21–45% flagged with
libraries of eight or nine. codellama does the same, 70–81% down to 22–33%.
A control that is not in the phantom catalogue, llama3.2, holds flat at
30–39% throughout. The model does not change, the machines running it do.
Circle size is the model's parameter count. Coloured by lab, with uncensored and abliterated models pulled out in red as a behaviour of their own; the dashed line is the typical library.
Every server placed by the first two octets of its IPv4 address. The X-Axis is the first octet, the Y-Axis the second, circle area the number of servers in that /16 that week. Pick a lab and the fill shows each neighbourhood's share running its models. Whole regions of the address space favour one lab.
Scan for long enough and you start to distrust your own results. We went looking for people running Ollama on the open internet, and a large fraction of what came back does not behave like anybody running anything.
Nobody reported this. It turned up as arithmetic that would not sit still. So: here are the counts, here are the two separate things the counts turn out to be, and then each one in turn. Both of them come apart in the end, though the bigger one held out for eighteen months and only gave way when we stopped asking it about Ollama.
Start with the size of it, before anybody tries to explain anything. Take every server that reported a model list and run four checks a normal install passes without thinking. Is the catalogue a fixed list turning up word for word on thousands of machines that have never met? Are the models named like scratch files? Are they commercial products whose weights were never released to anyone? Does the file size the server reports match the file that actually exists?
That is a lot of servers failing a very low bar. None of it is an accusation about any particular machine, and some of it is surely somebody testing something on a Tuesday. Every chart in Chapter 1 lets you throw these out and watch what happens. What is left over is the question of what they are, which is the rest of this chapter.
The first useful thing we found is that this is not one phenomenon. Sort the flagged machines by what they actually advertise and they fall into two piles with almost nothing to do with each other.
Pile one: old models, on servers that are not servers.
A frozen pool of unremarkable models from 2023 and 2024, the same short list everywhere:
llama2:latest, llama3:latest, openchat:7b,
codellama:13b, qwen2.5:1.5b. Sizes constant to the byte across
machines with no connection to each other. Version strings drawn from a small rotating
set. Ask one to hold a conversation and whatever answers is not a language model. This is
the bulk of it, and it comes and goes in waves.
Pile two: commercial models that cannot exist. Servers offering
gpt-4o, claude-3-opus and gpt-4. Neither OpenAI nor
Anthropic has ever released those weights, to anyone, so whatever sits under those names
is something else wearing the label. Far fewer of these, and here is the odd part: they
are on ordinary working servers, serving real models quite happily alongside.
Different models, different machines, different behaviour, different scale. The only thing the two piles share is that both are wrong. We take them in that order.
This is the big pile. Hundreds of hosts answering the Ollama API from what is very obviously a script: one frozen model list, identical file sizes, version strings off a wheel, and chat replies stitched together out of a phrase bank. Everything below is what they do.
The fake Ollama is not the point of these machines. It is one lure on a trap built for the people scanning for open Ollama servers, which is to say for us.
OllamaSpider scrapes Shodan and grabs endpoints on ports that were never Ollama. The other two feeds verify their hosts and do not carry this. Open Ollama servers are not mostly fake, and there are thousands of real ones. This is a claim about a specific set of hosts in a specific feed.
These hosts are live and responding. Something on each one answers
the Ollama API with a model list, a version string, a chat reply. All of them advertise
some subset of one small, fixed pool of old, unremarkable models
(llama2:latest, llama3:latest, openchat:7b,
qwen2.5:1.5b and a couple of others), frozen since early 2024, each at a
size constant to the byte wherever it appears.
Ask one a question and the reply reads like filler from a small phrase bank rather than a model's answer. Ask its version and you get one of four fixed strings. Ask a model for its details and the response is empty, yet the running-model endpoint reports every one of them loaded and running at once, which no real host does.
Ask it to run a model that does not exist and it answers anyway; tell it to pull or delete a model and it reports success while nothing changes. Every command fails the same way: it always says yes. It is hundreds of hosts actively answering, and answering the same narrow way.
The sharpest test does not come from the scanners. In a fresh snapshot
of 4,407 hosts that answer as Ollama, ollama version splits the
population in two. Real servers report one of 172 different versions in a natural
long tail. The responders return one of just four fixed strings, which stand as a tight
near-equal band far above every real version. The four are in
orange.
Hosts report a subset of the same handful of models, at sizes constant to the byte. The most common single catalogue in the feed, reported in full by tens of thousands of them, is:
Each model's size is constant to the byte, where genuinely pulled models vary by quantisation and version:
Spread across ports that mostly are not Ollama's. The same machine appears once per port:
Everything else here comes from commit logs. This does not. The project owner sent one instruction with a single correct answer to every OllamaSpider host advertising a given model and read the replies. A real model answers. A fake one replies with filler that quotes the prompt back.
Three runs, two test questions, three models from the fixed catalogue:
Line up all three probe captures and the replies give themselves away. Every one is an opener, then the word Regarding with your prompt quoted back, then a filler clause, then a closing question, each drawn from a tiny fixed pool.
Seven
openers, eight middles, five closers make possible sentences,
assembled by pre[rand] + your text + mid[rand] + post[rand]. This is string
concatenation, not a model.
A real Ollama host reports one version. These return four fixed strings
in near-equal proportion, from 0.1.0 to 0.6.3. It is the same
rotate-a-fixed-list trick as the chat replies, applied to the version field.
Ollama listens on 11434. These hosts mostly do not. They answer on ports assigned to databases, service meshes and Windows remote management. This is the port mix of these responders, not of open Ollama servers in general.
ollama.com publishes the real blob size of every library tag, so a reported size can be checked against an outside fact. Each row is one host: the small dot is the tag's real published size, the large dot the size it reports for that tag.
Every test above asks the same kind of question. We spoke Ollama at these machines, in more and more careful ways, and got nonsense back. The thing we never did was speak anything else at them.
A real Ollama daemon serves its own short list of /api/
routes and returns 404 for everything else. So ask one of these hosts for the four
things a scanner always asks for instead. A WordPress login page. A leaked
.git config. A .env file. A database dump left in the web
root. None of them has anything to do with Ollama, and a real Ollama host has none of
them.
They serve all four.
This is not a broken Ollama. It is a honeypot that answers every protocol you try, and Ollama is one of the personalities it wears. That reframes every finding above. A catalogue frozen since 2024 is not neglect, it is a prop. Sizes that do not match the published blobs are not a bug in somebody's mock, they are numbers nobody expected to be checked against ollama.com. The phrase bank is not a failed language model, it is enough of one to keep a scanner reading for another few seconds while it is logged. Every command succeeds because the point is to never give you a reason to leave.
The pages give up the operator. Compare the bodies byte for byte across the machines and two of the four are the same file on nearly all of them, which makes this one kit deployed repeatedly rather than many people doing the same thing. The other two are different on every single one, and those are exactly the two that carry credentials.
One last thing the sweep turned up, which is the strongest evidence that somebody is still tending this. The live fleet now splits almost exactly in half by what it advertises.
Who runs it. The kit matches no published honeypot, tarpit or
mock-server project, checked against GitHub, the web, and the honeypot literature. The
closest, funnypot, echoes the model name rather than the prompt and runs
on a single host. Whether this is one security vendor's canary network, one researcher
at scale, or something with a less friendly purpose, the traffic alone does not say.
Nor whether it works. The whole design assumes somebody scrapes an exposed host, finds a credential, and tries it. We are not going to find out by trying one.
The catalogue is not an arbitrary list. It is what people were actually running when the trap was built.
Separating the two populations in the past is harder than it looks.
The catalogue test cannot do it, because a server running llama3 in early
2025 was running the most popular model of the moment, and the test would call it fake
in hindsight. Reported size cannot do it either: the fleet's byte-exact constant is
indistinguishable from a genuinely popular tag that everyone pulled from the same
re-push.
The port can. It is recorded on every observation, it is set by whoever installed the thing, and no part of it is inferred from a model list. Ollama's default is 11434. Almost every real server uses it and almost none of this fleet does.
So in an unfiltered count these old models never went out of fashion. They did. What holds the number up is a fleet advertising a 2025 shelf that nobody restocked, which is also why the sizes are wrong and the version strings are from the same era. Half the fleet has since moved to current flagship names, so somebody eventually noticed the bait had gone stale.
Machines in this feed answering on the port Ollama actually uses, against machines answering on anything else. They trade places at the end of July 2025 and never trade back.
Here is the one thing about this fleet we can say without hedging. Every phantom-catalogue host that our FOFA capture also saw is on AWS. Not most of them. All of them. The same capture holds ten thousand Ollama servers hosted somewhere that is not AWS, and the number of those carrying the phantom catalogue is zero.
Spread proportionally, a couple of thousand should be sitting on Hetzner and OVH and the rest. Go and look. They are not there.
One account, one cloud, one kit. The hosting is the operator's invoice.
The small pile. Like the big one, it gave way to a single HTTP request we should have sent much earlier, and to a different endpoint than the one we kept interrogating.
Below: what these servers claim, the two sensible explanations for it, why the evidence refuses to support either, and then what is actually in there.
Probing live hosts directly turned up a separate oddity. Hundreds of
real, working Ollama boxes advertise a closed-weights model that cannot exist on
Ollama: gpt-4, gpt-4o, claude-3-opus, and newer
names like claude-opus-4.8, gpt-5.5 and
gemini-3.5-flash. Of the live hosts we reached, 726 carried at least one
of these.
They never appear alone. Every one of those 726 also runs genuine open
models, usually Qwen, DeepSeek, or an abliterated Huihui build, so these are not empty
decoys but real servers with fake names planted among the real ones. And the fake names
carry no hf.co/ prefix the way the genuine models on the same boxes do, so
they are made on the machine with ollama cp or a Modelfile, not pulled from
Hugging Face. There is no upstream repo claiming to be GPT-4. It is local theatre.
Two very different levels of effort sit behind it. On 708 hosts the
premium name points at a real but tiny 638 MB, 1.1B, Q4_0 llama blob, a small
model wearing a big label. About 500 of them share one byte-identical blob, so this is a
single artifact copied across hundreds of machines, not hundreds of separate pranks. A
smaller, more deliberate seven fabricate the manifest outright: zero-byte entries whose
parameter_size is the literal string synthetic, listing
current premium models they demonstrably do not hold, each sitting beside per-host
gateway-diagnostic entries. That tier looks like a catalogue kept
up to date on purpose, or a scanner planting its own write-test marker. We cannot tell
which from here.
One detail gives the game away: which names get faked. Whenever a real
model actually sits behind the fake label, the label is a 2024 trophy, almost always
gpt-4, gpt-4o or claude-3-opus. The current
flagships, claude-opus-4.8 or gpt-5.5, turn up only as the
empty synthetic manifests, never with weights behind them. So nobody parks a cheap model
behind a current name and invites you to test it. The impersonation is frozen where it
started, reaching for models that were the state of the art when these boxes were set up
and have since been passed by weights anyone can download for free. Even the successful
version of this lie now points at something a small open model would beat.
The fake names are not the only small thing on these boxes. Setting the fakes aside and measuring the real models, hosts carrying a premium name run noticeably smaller models than clean hosts: a median of 1.9 GB against 4.7 GB, with 42% under a gigabyte versus 16%. They also cluster on old Ollama versions, a fifth of them on 0.30.2 alone, where clean hosts spread across many including current releases. So the premium label tends to sit on an older, lighter, less maintained box.
There is a completely mundane explanation available and we went looking
for it first. Plenty of closed-source software ships a hardcoded list of OpenAI model
names with no way to change it. Point it at your own machine with
OPENAI_BASE_URL, run ollama cp to give one of your models the
name the software insists on, and it works. This is not a hack somebody clever invented.
Ollama documents it.
Good theory. It makes predictions. Every one of them is wrong.
So the tidy explanations leave no mark anywhere we would expect to find one. That is not the same as knowing what this is. It only rules things out, which is most of what this chapter can offer.
So we stopped theorising and asked one. Ollama has an endpoint,
/api/show, that hands back exactly what a model is: what it was copied from,
the architecture inside the file, and any system prompt somebody attached to it. It is one
curl. In hindsight this should have been the first thing we tried rather than
the last.
Every single one of them is tinyllama. A 638 MB model
from 2023 that runs comfortably on a laptop, wearing a GPT-4 badge, with about
1.25 kB of text stapled to the front.
The text is a ransom note. It announces that the machine has been compromised and asks for Bitcoin. It is installed as the system prompt and as a pre-seeded conversation, so the model has already agreed, in writing, to repeat the demand in every answer it ever gives. Nothing is encrypted. Nothing is deleted. Several of these machines are cheerfully serving real 27-billion-parameter models the whole time.
If you got here by searching that wallet address, this part is for you. We published it on purpose. If you found this note on a machine you run, searching the address is exactly what you would do next, and you deserve to land somewhere that tells you the truth. It has never been paid, by anybody. Nothing on your server was encrypted or deleted. The demand is a bluff and you can ignore it.
What does deserve your attention is how it got there. Your Ollama API was reachable from the open internet and accepted writes without asking anyone for a password, which means anybody at all could install a model on your machine. This particular person left a note asking for money. The next one might not. Close the port, and delete the models you did not put there.
The raw feed behind Chapter 1. Five sources contribute: two GitHub scanners, one FOFA-based and six countries only, the other an accumulating list, plus point-in-time FOFA and Shodan pulls and our own daily re-probe. OllamaSpider is excluded here. Only 15.6% of what it reports sits on Ollama's port against about 47% for the other two, it sprawls across 7,911 ports including CouchDB and Consul, and half its servers fall in the responder blocks from Chapter 2.
Total deduplicates a server seen by both.
Model tags ending -cloud are dropped throughout, since those proxy to
Ollama's hosted service and commit no weights, disk or GPU on the reporting machine. They
are 2.7% of installs but 32% of everything at 90B parameters and above.
Collapse duplicates also folds together groups of 50+ addresses reporting the same model list on the same day.