On October 12, Anthropic published a research note on self-replicating AI that put a short timeline on a difficult problem: small models might be months away from spreading across cheap IoT devices without relying on a datacenter. William Zhou and Daniel Freeman tested real hardware, repeated their experiments, and reported uncertainty around the results. They also explained where they had simplified the environment.
I came away from it interested in the engineering and less convinced by the timeline. The study shows models doing useful work across hardware they weren't specifically built for. It also shows how much harder it is to put all the steps together, and how slowly an agent would run on the devices it was supposed to spread through.
What the hardware could do
The researchers bought fifteen off-brand Android TV boxes for about $55 each, with 4 GB of RAM per device. They split Gemma4-26B-A4B across the fleet using pipeline parallelism. That choice mattered: when a node drops out, pipeline stages are easier to recover than a model split through tensor parallelism.
The fleet reached an aggregate 0.39 tokens per second. In the inference setup workload, processing a full 32k-token context window took roughly a day for the 26B configuration. A complete agent trajectory needed between 2.6 and 4.7 of those windows. Getting the model to run was only the beginning of the performance problem.
In a separate experiment, Qwen3.5-9B was asked to set up inference on unfamiliar hardware. It succeeded on eight of the nine hardware types tested, spanning devices such as a Jetson Nano, a Mac, and the TV boxes. The individual tasks were familiar systems work: choose compatible software, install it, debug the failures, and get a server running. What interests me is that the model could connect those tasks and work through environments it hadn't been given a fixed setup procedure for.
That matters for an agent operating across a mixed fleet. Malware built around a particular device and software configuration has a narrower set of assumptions to work with. A model that can inspect an unfamiliar system and troubleshoot its way through setup has more room to adapt.
How they tested replication
The replication experiment used a VPC with eight nodes running an Android environment. Access was deliberately easy: each node exposed an ADB port without authentication. The authors describe this as an upper bound on real-world success, since the experiment largely removed the difficulty of gaining access.
GLM-5.2 reached all eight nodes in four of five trials. But the model making the decisions ran on a separate inference server. The payload it set up on the target devices was Llama3.1-8B, which was small enough to fit. The researchers used that common payload to compare models without making the larger ones serve their own, much larger weights.
That is a reasonable experimental choice, and it puts a limit on what the result demonstrates. The successful run had a large model directing work on the target nodes from elsewhere. The decisions still depended on compute outside the target fleet. As an orchestration pattern, that is available now. A small model doing the whole job from the devices themselves remained the capability being projected.
To reach that point, a model has to be capable enough to complete the replication process and small enough to run on the target hardware. The study hadn't demonstrated both conditions in the same model. Its timeline comes from extending a trend in the Epoch Capabilities Index, with gains of 13.7 points a year among the leading small models. The authors explicitly describe the index as a proxy for replication ability.
I would keep that forecast separate from the experiments when deciding what to defend against. The experimental results support the architecture we can see working. The date depends on the trend continuing and the general capability score translating into this particular task.
The time available to defenders
Using the measured inference speeds and the work required to complete setup, the researchers estimated 71 to 150 hours for the 26B configuration and 28 to 51 hours for the 9B model. Those estimates put replication on a timescale of days. They weren't measurements of a fully self-contained worm spreading through a real population.
That pace gives defenders time to act. The study cites a Mirai remediation effort in which ISP quarantine and customer notification cleared 92% of infections within fourteen days, compared with 74% without notification. Whether those measures would stay ahead of an AI worm would depend on how quickly infections were detected and how consistently operators responded.
There would also be traffic to investigate. A replicator carrying its weights has to move large model files onto new hosts, and distributed inference can keep devices communicating for long periods. Residential devices exchanging multi-gigabyte payloads and sustaining unusual traffic give defenders something concrete to look for. The paper itself identifies those network patterns as useful signals.
For this version of the threat, I would spend time on whether someone is actually watching those signals and can act on them. A slow replication cycle buys time only if a defender uses it.
What the agents passed on
In the inheritance experiment, instances of Qwen3.5-9B left notes for their successors about what they had tried and where they had failed. Across six generations, inference setup success rose from 45% in the first generation to as high as 84% in later ones. The next instance could start with something learned by the previous one, instead of repeating the same mistakes.
Combined with the hardware results, that suggests a way for an agent to become more effective on a particular fleet as it encounters it. Here, passing useful experience between instances improved inference setup. Whether that carries over to other parts of an attack remains to be tested.
Giving the small model access to a stronger advisor, Opus 4.8, produced a different result. The advice didn't measurably improve performance. The smaller model struggled to ask useful questions, and unsolicited advice didn't solve the problem either.
That makes me more interested in a larger model directing smaller agents than in small agents deciding when to ask for help. The authors reach a similar conclusion. It also fits the replication experiment, where the model coordinating the work was running on a separate server.
Where I would look for a control
The defensive recommendations include network monitoring, ISP quarantine, and better security defaults on devices. I would also test controls at the point where a weight-based replicator stages its model files.
Those files have recognizable structures. GGUF specifies identifying bytes in its header, and Safetensors has a defined, parseable header. Where a defender can inspect the file, that provides a way to identify a model artifact. A known payload can also be matched by its hash.
The context would still matter. A model file on its own doesn't establish malicious activity, and an ordinary network monitor won't necessarily see the contents of a transfer. But a television unexpectedly fetching weights from a public hub, or a device staging a known replication payload, is a specific event around which to build a detection or policy check.
For a hub or endpoint operator with that visibility, I would investigate whether known payloads could be blocked before inference starts. If this replication path requires those weights to arrive, preventing that transfer interrupts the path. I'd test it against the actual workflow, including legitimate uses and possible evasions, before claiming it works as a defense.
The cloud route
The paper also considers API-based replication: a model acquiring stolen credentials and using someone else's inference access to keep running. From a defensive standpoint, I would give that route immediate attention. It avoids much of the work involved in getting a model to run across a collection of underpowered devices.
Kimwolf infected more than two million devices, largely Android TV boxes. The authors estimate that a similarly sized fleet, divided into groups of fifteen devices running Gemma4-26B-A4B, could host about 133,000 model replicas. At the speeds they measured, the entire fleet would provide at most roughly forty H100s' worth of inference. That is a hypothetical compute estimate, not a report that Kimwolf actually ran those replicas.
It is a lot of compromised hardware for relatively little inference. Access to an existing cloud service would remove that particular burden, although the provider would also have an account it could investigate or disable. For an organization deciding where to spend defensive effort, credential protection and unusual API usage or billing deserve attention alongside the IoT scenario.
This is note 1 of 5 in THRESHOLD, on the eight weeks when the floodgates opened. Next is The Receipt: XBOW's Chrome exploit chain, the researchers and agents who built it, and what Google's validation adds to the result.
- Zhou, W., & Freeman, D. (2026, October 12). Self-replicating AI: small models may be capable of autonomous self-replication on commercial IoT devices. Anthropic.