Ripple-65B Preview Is Here: The Open-Weight Coding Model You Can Run on a MacBook

Ricursive Intelligence just shipped Ripple-65B Preview, a 65-billion-parameter open-weight coding model that the company claims you can run locally on a MacBook Pro or an NVIDIA DGX Spark. It's Apache 2.0 licensed, scores 80.5 on Terminal-Bench 2.1, and was trained from scratch for roughly $32 million. That's a tenth of what the company says the previous open-weight leader cost.

I've spent the last day going through the model card, the GGUF builds, and the pile of skepticism this launch kicked up on Hacker News. Short version: the benchmark numbers are real, the "runs on a MacBook" claim needs an asterisk, and the "state of the art" framing is doing a lot of quiet work.

What is Ripple-65B Preview?

Ripple-65B Preview is a dense transformer, not a mixture-of-experts model, pretrained on 12 trillion tokens of mostly English and code data. Ricursive Intelligence is the company behind it, founded by Anna Goldie and Azalia Mirhoseini, who both worked on Google's AlphaChip project before striking out on their own in late 2025.

That chip-design pedigree matters here. Ricursive's actual product is a model that helps design more efficient silicon. Ripple-65B is a general-purpose spinoff of that same architecture, released as a way to show off the training recipe. It's not a side project. It's a demo of the main thing.

The architecture itself is unusual for a model this size. It's "thin-and-deep": a narrow 5120-dimension hidden size stretched across 80 layers, with gated attention, global NoPE (no positional embeddings in most layers), and value residuals borrowed from recent efficiency research. Ricursive says this combination bought them a 16x compute efficiency win on code versus their Olmo 3 baseline.

How good are the benchmark numbers, really?

Here's where it gets interesting, and where I'd slow down before taking the launch graphics at face value.

• Terminal-Bench 2.1: 80.5 — this is the headline number, and it does edge out Reflection's Beam-501B (80.1) despite Ripple being roughly 8x smaller.
• SWE-bench Pro v2.0 Hard: 79.1
• MMLU: 89.6
• AIME 2025: 98.3

Those are strong numbers for a 65B dense model. But on Terminal-Bench 2 specifically, Ripple actually leads Beam by a much bigger margin (80.5 vs 70.8), while on SWE-bench Verified, Beam wins 81.6 to Ripple's 76.5. On SWE-bench Pro v1.0, Beam is ahead 66.1 to 61.4. On DeepSWE 1.1, Meta's Muse Spark Open (60.0 at 816B) crushes Ripple's 44.3. SciCode is Ripple's weakest category at 39.4.

So it's not a clean sweep. It's a model that's excellent at terminal and bash-heavy agentic tasks and merely okay elsewhere. The benchmarks also mix harnesses (Terminus 2, DeepSWE 1.1, Inspect AI, OpenCode), which makes apples-to-apples comparison harder than the launch chart suggests.

The Hacker News thread (the discussion link above has a lot of this) jumps on the "U.S. open-weight SOTA" framing almost immediately. One commenter calls it out directly: each qualifier ("open-weight," "U.S.," "on agentic coding") narrows the claim until it's basically guaranteed to be true. Qwen3.8-Flash-Next from Alibaba scores 84.3 on the same benchmark, ahead of Ripple, but it's Chinese, so it doesn't count under Ricursive's framing. That's a real distinction for government procurement and export-control reasons, but it's not what most readers hear when they see "state of the art."

Can you actually run it on a MacBook?

This is the part that got my attention for the headline, and it's also the part with the biggest gap between marketing copy and reality.

Azalia Mirhoseini's own launch tweet says you can "run Ripple-65B locally and efficiently on a MacBook Pro or DGX Spark." Technically true. Practically, there's a catch: the model's advertised 1M-token context window doesn't survive the trip to consumer hardware.

The dev.to writeup on Ricursive's spark.py script (linked below) found that while the hosted version on OpenRouter and the 2x B200 server recipe both support the full 1,048,576-token window, the official DGX Spark script hard-codes the context limit at 131,072 tokens — an 8x cut. Same weights, same model, radically different ceiling depending on where you run it.

For the MacBook side specifically, AtomicChat's GGUF conversion (community-built, not official Ricursive) gives the real numbers:

So "runs on a MacBook" means a 64GB MacBook Pro, running a quantized version at roughly a third the precision of the original BF16 weights, and almost certainly not at the full 1M context. On a GH200 with Q4_K_M, community testing clocked prompt processing at 309 tokens/s and generation at 40.6 tokens/s — fine for a chat session, slow for agentic loops that chew through long contexts. A MacBook, with less memory bandwidth than a GH200, will land well below that. It'll run. It won't be fast.

I'd also flag that this is a dense 65B model, not a sparse MoE. Every token activates all 65 billion parameters, which is exactly why Hacker News commenters predicted it'd be "prohibitively slow" outside datacenter GPUs before anyone had even benchmarked it on a Mac. One Mac Studio owner in the thread said it'd run "at usable speeds"; another pushed back hard, pointing out dense models don't get the free lunch that MoE architectures give consumer hardware. Both are right, depending on what "usable" means to you.

Is the $32M training cost believable?

Ricursive's claim is that the full R&D cost (pretraining ladder, posttraining, synthetic data generation, everything) came to about $32 million over roughly 8 weeks, and that they hit 40% model FLOPs utilization using plain sharding with no custom kernels. They also say the RL stage used only 1.4 million rollouts, which is a small number by frontier-lab standards.

I can't independently verify a training budget — no outside lab can, for any model, ever. But the number is plausible given the architecture choices (dense, mid-size, no MoE routing complexity) and the team's background in efficient compute from the AlphaChip work. It's a believable number from people who'd know how to hit it, not an auditable one.

Should you actually use it?

If you're doing terminal-heavy agentic coding work (bash scripting, environment setup, CLI-driven tasks), Ripple-65B's Terminal-Bench score makes it worth a try, especially since Apache 2.0 means no licensing headaches for commercial use. If your work leans toward SWE-bench-style pull-request generation or scientific code (SciCode), the numbers say look elsewhere first; Ripple is clearly weaker there.

If you were drawn in by "runs on a MacBook," temper expectations. You need 64GB of RAM, a quantized build from a third party (not Ricursive's own release), and you'll be working with a meaningfully smaller context window than the 1M figure in the headline. It's a real local-coding option, not a magic trick.

For broader context on how other large open-weight coding models stack up, see our pieces on Kimi K3 vs Claude for frontend coding and Qwen 3.8 Max's release. If you're trying to make sense of the flood of model releases this year, our August 2026 recap is a good index.

Watch

Ricursive's own launch thread and Azalia Mirhoseini's follow-up (above) are the most direct source for the claims in this post: worth reading in full before you decide whether the MacBook angle matters for your workflow.