Ripple-65B: a dense 65B model that beats 500B open weights

Ricursive Intelligence published Ripple-65B Preview on Hugging Face this week: a 65B dense transformer, pretrained on 12 trillion tokens, with a one-million-token context window and an Apache 2.0 license. On TerminalBench 2.1 it scores 80.52, ahead of Reflection Beam 501B at 80.1, Meta Muse Spark Open 816B at 76.4, Thinking Machines Inkling 975B at 63.8 and NVIDIA Nemotron 3 Ultra 550B at 56.4.

Read that list again. A 65B model beat open-weight models eight to fifteen times its size on the benchmark that measures whether an agent can actually drive a terminal, and it did it while carrying a license you can ship in a product.

*Caption: The model card states the claim and the comparison set directly: 80.52 on TerminalBench 2.1 against substantially larger US open-weight models. Screenshot: Hugging Face.*

Why dense, when everyone else went sparse

The card explains the design choice in its own words: they trained a modernized dense transformer rather than a mixture of experts, because the goal was to reduce pretraining and posttraining infrastructure complexity while keeping agentic performance. Dense models spend every parameter on every token, which is expensive to run but simple to train and simple to serve. They also fit on hardware you can buy.

The efficiency claim is where it gets interesting. Starting from an Olmo 3 baseline, Ricursive says its v1 ladder improves compute efficiency on code by 16 times relative to the Olmo 3 ladder, rising to 55 times for the full run, at 40 percent model FLOPs utilization throughout pretraining. The team that did it scaled from one person to five.

*Caption: TerminalBench 2.1, as published on the model card. The 65B dense model sits above every larger US open-weight entry it was compared against. Figure: Tokenstead.*

What it takes to run

A 65B dense model at 4-bit is roughly 33GB of weights. That fits a single 48GB card with room for context, a 128GB DGX Spark, or a 96GB desk machine at higher precision, and it is the number this site cares about. The lab shipped BF16 and NVFP4 builds, plus a base model and a DFlash2 variant. Community GGUF quants appeared within days, and the AtomicChat set already has more downloads than the official repository.

*Caption: The trade the dense design makes: more memory per token than a sparse model, far less memory than the 500B to 975B models it beats. Figure: Tokenstead.*

That combination is unusual. The open-weight models that top agentic leaderboards have been 500B to 1T total parameters with 20B to 100B active, which means either a cluster or a very deep wallet. Ripple trades sparsity for density and lands at a size one person can host.

*Caption: Compute efficiency on code against the Olmo 3 ladder: 16x for the v1 ladder, 55x for the full run. Figure: Tokenstead.*

The honest caveats

These are the lab’s numbers on the lab’s benchmark run, with reasoning effort at maximum, and TerminalBench 2.1 is one benchmark. The Preview tag means the posttraining stack is still moving. Downloads are modest so far, roughly 939 on the main repo and 1,668 on the community GGUF, which tells you the community is still validating it.

*Caption: The repository as published: BF16 shards, NVFP4, base and DFlash2 variants, Apache 2.0 throughout. Screenshot: Hugging Face.*

Why it belongs on this site

Every build on the hardware pages has been solving the same problem from the other end: buy enough memory to hold a model worth running. Ripple changes the model side of that equation. A 65B dense model that scores like a 500B one means the $30k flagship and the $20k Spark cluster stop being about squeezing frontier-class weights into memory and start being about running a genuinely strong agent model with cache room to spare.

It also puts pressure on the assumption that open-weight progress requires sparse models and a cluster. A five-person team, a dense architecture, and a license that lets anyone ship it is a different thesis from the trillion-parameter race, and on this benchmark it won.