Claude proves fuzz tests can't crash
Claude proved that fuzz tests in 123 open-source libraries can't crash on any input under 64 MB
On Friday's Hacker News front page, Anthropic and Theorem had Claude turn fuzz tests into proofs. Take a library's own fuzz test from Google's OSS-Fuzz, compile it to RISC-V, and state one rule: no input under 64 megabytes ever crashes it. Claude writes the proof, and the Rocq checker verifies it, so the only things to trust are the checker, the machine model and the rule itself. It held for 239 entry points across 123 libraries, about 180 million lines of proof.
Bugs a fuzzer would miss
Trying to prove it found bugs that only huge or rare inputs reach
A fuzzer takes random samples from the space of inputs. The proof covers the whole space.
Every failed proof points at a bug, and Claude patched them as it went. A decompressor had an out-of-bounds write that only an input near 20 megabytes, with one rare layout, could reach. Fuzzers mostly cap inputs around one megabyte. An image decoder needed a 64 megabyte input and two gigabytes of memory. In the thread, pinevale asked whether this just proves fixed crashes stay fixed. btilly answered: a fuzzer samples the inputs, and the proof covers every one of them.
What the proofs cover
The proofs hold on RISC-V and musl, and most of these libraries ship on x86 and glibc
Proved for
- RISC-V
- static binary, musl libc
- single-threaded
- inputs under 64 MB
Most deployments
- x86 or ARM
- dynamic, glibc
- threads
- any input size
A proof is only as wide as its model. These cover single-threaded static binaries on RISC-V with musl, and most people run these libraries on x86 or ARM against glibc. They cover the fuzz entry points only, so the rest of each library stays unproven. You can try it on your own code: Theorem offers to run the same pipeline for open-source projects, and it publishes a Claude skill for getting started. A proof can take hundreds of millions of tokens, and newer models need fewer of them.
Kimi K3.1 Pro
Kimi K3.1 Pro codes in a terminal about as well as Claude Opus 5.5, and its weights open by November 4
Moonshot released Kimi K3.1 Pro, with a one million token context, and a Highspeed version that runs two to three times faster. You can pick it now in Kimi Code with the model command, or call it through the Kimi API. The full weights follow by November 4. On terminal coding tasks it lands within a point of Claude Opus 5.5, and well ahead of GPT-6 Astra.
Kimi held back exploit skill
Moonshot stripped exploit training data from Kimi K3.1 Pro before opening the weights
Offensive cyber capability "below what our pipeline can produce"
So they admit that they could do more, but they won't?
The open weights come with less exploit skill than the same training could produce. Moonshot removed security data from mid-training and the reinforcement learning mix. A checkpoint trained without that cut solves about nine in ten exploit tasks; the release solves about eight in ten. Moonshot plans to raise that ceiling in later open releases. In the thread, rudolftheone asked whether that means they could do more and won't. besterman23 wondered how much exploit skill comes back from ordinary programming knowledge anyway.
Docker is weird
Writing a container runtime shows that a Docker container is just a restricted process
Creator of Docker, stopped by to answer questions
The most important part of runc is written in C
Code and Cake started writing a container runtime for fun, and wrote up what Docker turned out to be. A container is an ordinary process the kernel restricts with namespaces and cgroups. An image is a folder that becomes the new root. And runc is written in Go, whose runtime is multi-threaded, so a C module runs before Go starts to make the single-threaded system calls. shykes, who says he created Docker, joined the thread to answer questions. jlhawn, who worked at Docker for five years, added that the C part is the one that matters most.
Dijkstra on natural language programming
Dijkstra in 1978: programming in English adds work on both sides of the interface
A machine is programmed in whatever source control tracks. Java an LLM helped write is still Java.
A 1978 note by Edsger Dijkstra came back around. He argued that moving from formal symbols to our native tongue adds work on both sides of the interface, and that formal notation is what rules out nonsense. In the thread, riknos314 said a machine is programmed in whatever source control tracks, so Java an LLM helped write is still Java. What does your repo track: the prompts, or the code?
