Dense Coding Model Claims US Open Lead: 65B Beats Models 15× Its Size
On November 4, Ricursive Intelligence—the chip-design lab founded by Google researchers Anna Goldie and Azalia Mirhoseini—released Ripple-65B Preview, and the numbers caught people's attention because they shouldn't add up.
The company says Ripple-65B Preview is a 65-billion-parameter dense language model now the state-of-the-art US open-weight model on agentic coding tasks, outperforming rivals several times its size. It scores 80.5 on TerminalBench 2.1, edging out Reflection AI's 501-billion-parameter Beam at 80.1, and beats Meta's Muse Spark Open (816 billion parameters) which scored 63.8. The company says Ripple-65B Preview's total R&D cost came in at around $32 million, which it describes as roughly a tenth of what the previous open-weight leader in agentic coding cost to build.
That efficiency claim matters, but the real story is architectural. Dense architecture means Ripple uses all 65B parameters on every token instead of routing through experts, a deliberate contrarian choice while most labs chase MoE efficiency. Since mid-2025, almost every competitive open-weight model has been mixture-of-experts—sparse routers that activate only a fraction of their weights per token. DeepSeek V4 does it. Qwen does it. The tradeoff is obvious: MoE lets you activate fewer parameters and run faster, but every token still reads the full parameter count from memory. Ripple inverts that. All 65 billion parameters participate in every token. It's slower to generate per token, but the model itself is smaller.
What people are building with it
Co-founder Azalia Mirhoseini said in the launch post that you can run Ripple-65B locally and efficiently on a MacBook Pro or DGX Spark. The claim immediately drew skepticism from the community. One early tester ran it locally on a DGX Spark and reported Ripple scored 80.5% on Terminal-Bench 2.1, narrowly ahead of Reflection's Beam-501B at 80.1%. But another asked about throughput: "What tok/s are you getting on the Spark? 65B dense on ~273GB/s of memory bandwidth has to crawl in an agent loop".
The weights are a free download from Hugging Face. In BF16 they need about 130 GB of memory, so local setups start from the NVFP4 build or community GGUFs. The community has already published AtomicChat GGUFs, at 38.8 GB for the Q4_K_M quantization and 68.8 GB for Q8_0. In actual hands-on testing, local deployment took hours, not minutes, requiring a custom VM, a quantized checkpoint using about 75GB of VRAM, and manual rewrites of the provided inference code for a different GPU than it was built for.
One tester ran Ripple-65B against a real, running full-stack application: a retirement calculator covering 20 countries, built with a typical frontend/backend/cache/database setup inside Docker. The benchmark results are real. The local deployment experience is harder than the marketing suggests.
What's actually good (and what isn't)
Ripple's 80-layer design uses a Gemma-style layout for training stability, with extra attention heads and sliding window attention to control compute cost. Ricursive pretrained the model from scratch on 12 trillion tokens and did not start from someone else's base model and fine-tune it, which is the shortcut many smaller labs take. That matters for independence, not so much for performance.
The practical read: Ripple-65B looks like a specialist, not a generalist. On Terminal-Bench 2.1 Ripple wins (80.5 against 73.0), on SWE-bench Pro it is level (61.4 against 61.7 and 62.5) and on DeepSWE 1.1 it beats the 27B (44.3 against 42.2) but stays far from Flash-Next, at 58.7. The model is good at agentic coding. It's not a general-purpose frontier replacement.
Every token Ripple generates goes through all 65B, on a Spark that Ricursive's launch page itself describes as low on memory bandwidth next to datacenter accelerators. A dense model designed for simpler training and local deployment—but "simpler training" doesn't mean faster serving. Ripple's dense model architecture provides strong reasoning performance with low-latency token generation, but the model's small parameter envelope enables it to run efficiently on local devices such as NVIDIA DGX Spark, which feature high compute FLOPs with low memory bandwidth relative to datacenter accelerators. Translation: it runs where MoE models don't, but slowly.
How to try it
Ricursive says Ripple-65B Preview is available on Hugging Face, Together AI, GMI Cloud and OpenRouter, with Fireworks listed as going live later on launch day. For API access, you don't need to care about density. For local: Set it up on a DGX Spark with a script that takes git clone, setup, and first start ~11 min (kernel compile), later ~2 min. On Mac with MLX, run mlx_lm.server --model frogggias/Ripple-65B-Preview-MLX-4bit --trust-remote-code. Running the model locally required nontrivial VRAM (around 75GB in quantized form), a capable workstation GPU, and manual engineering work to adapt the provided inference code; in testing, a quantized version used approximately 75GB of VRAM on a 96GB VRAM VM, running on an Nvidia RTX Pro 6000 Blackwell GPU.
The bet is real: density works for training simplicity and local memory footprints. Whether it matters for your workflow depends on whether you have 75GB of VRAM and patience for 6.7 tokens per second.