What Is Recursive's Eureka Machine and Did It Build Flint?

What is the Eureka machine?

The Eureka machine is Recursive's automated research system. It runs a loop in which agents propose ideas, write code, run experiments, and keep the winners as stepping stones for the next round. Recursive says it helped design the architecture, quantization, and GPU kernels of Flint, its first model. The name also refers to a book by Richard Socher. The claim is interesting, but there is no published paper yet.

Who is behind Recursive?

The public face is Richard Socher. He taught well-known NLP courses at Stanford, led AI at Salesforce after it acquired his startup, and more recently founded the search company You.com. His 2014 Stanford PhD thesis was titled "Recursive Deep Learning for NLP and Computer Vision," so the lab's name has some history behind it. He also published a book called The Eureka Machine, which lays out the broader vision.

He recruited eight co-founders from places like Google, OpenAI, DeepMind, and Meta. One is Tim Rocktäschel, who came from Google DeepMind, where he led the open-endedness team connected to Genie, Google's world model.

Recursive came out of stealth in May with $650 million raised at a $4.65 billion valuation. With a team of about 30 or fewer, investors were backing the team and its self-improvement approach rather than any shipped product.

How does the Eureka machine work?

Two things share the name: the vision in Socher's book, and the system actually running inside Recursive. The real system is a loop:

1. An agent proposes an idea to try.
2. It writes the code.
3. It challenges its own work and runs experiments, training or benchmarking something.
4. Winners become stepping stones for the next round.

Many research paths run in parallel, and the system combines the most promising ones. Anyone who has followed open-endedness research will find this familiar. The difference is scale, with more money and compute behind it. Recursive says earlier runs in June targeted tasks like lowering loss on nanoGPT and nanochat. Flint is its first model of useful size.

Why is the evaluator the hard part?

Recursive's own framing is that generating ideas was easy and building the judge was hard. As the search got stronger, candidates started gaming the evaluation. Examples include caching outputs and exploiting timing. The only fix is to keep strengthening the evaluator, which resembles the generator and discriminator dynamic in GANs.

Socher has said the team found many bugs in its own test harness. The lesson applies to anyone running agent loops or reinforcement learning. A verifier is an attack surface, and the better your optimizer gets, the more holes it finds. Think of a clever intern who will hit whatever metric you set, whether or not it serves the real goal.

What did Recursive say the system automated for Flint?

Recursive describes three parts.

The output layer detail matters. Flint uses a tokenizer of about 150,000 tokens, and the output layer alone is around 300 million parameters, roughly an eighth of the active compute per token. Most models leave it unquantized. Recursive says quantizing it helps the NVFP4 version score close to full precision.

The mega kernel cuts kernel launches and trips to memory. That is where the speed claim on Apple hardware comes from.

What is Flint, and how does it perform?

Flint is a mixture of experts model with 40B total parameters and about 2.5B active per token. It has 256 experts, picks six per token, and keeps one shared expert always on. Of its layers, 35 use sliding window attention (about 500 tokens) and 14 use full attention. Recursive documents 262k context with up to 65k output tokens. Reasoning is always on.

The license is Apache 2, and there are four official Hugging Face repos: BF16, INT4, a GGUF quantization, and NVFP4. It runs in Ollama, LM Studio, and llama.cpp, with vLLM and SGLang support for serving.

On speed, Recursive's own engine, called Wreck, reportedly reaches about 130 tokens per second on a MacBook with an M4 chip, roughly ten times a dense Qwen 3.8 27B model on the same machine. That engine appears to install only on a fairly powerful Mac. Those Mac numbers come from Recursive's launch footage, not independent testing.

On quality, the picture is mixed:

• Against similar-class MoE models, including Qwen 3.6 35B, Flint leads on most benchmarks and roughly ties Qwen 3.6 on LiveCodeBench.
• It appears to beat its rivals on instruction following.
• Against the dense Qwen 3.8 27B, it loses. On Terminal Bench it scores 55 versus 73, and it trails on SWE-bench and LiveCodeBench too.

So Flint is not the best coding model. It is a fast model that gets close to dense-model quality. One reviewer who ran the benchmarks himself saw results that differed from Recursive's, better in some cases and worse in others. Recursive's blog also says Flint may need more guidance than larger closed models, so break big jobs into smaller, explicit steps. Its docs recommend the Pi harness over Open Code.

How credible is the claim that an AI built Flint?

Partly supported, mostly unverified. The model exists, it is open, and anyone can test its speed and benchmarks. What nobody outside Recursive can check is how much the Eureka machine contributed versus human researchers.

The open questions are specific:

• No paper. There is no published methodology to examine.
• Unknown compute. Recursive has not said how much compute the loop used, though it described building Flint in under four months with a small machine and a set of agents.
• Unknown agents. It is unclear which models power the agents or how many run. A frontier model from another company could be doing much of the work.
• No ablations. Without comparisons to human-led baselines, it is hard to say what the automation actually added.

The individual pieces are also plausible without any exotic claim. Searching expert configurations, applying quantization-aware training, and writing a fused kernel are all tasks where agents with a good evaluator can help. The credibility question is about degree and autonomy, which is exactly what a paper would clarify.

What can builders take from this?

The most portable lesson is about evaluators. If you run agent loops or RL, assume your optimizer will find shortcuts in your metric, and budget time to harden the harness. The second is practical: for local agent work, active parameter count drives speed, while total parameters decide whether the model fits in memory.