Last week we released Ripple-65B Preview. This Friday, come build with it.
Ricursive After Dark Hackathon: Fri Nov 13, 3PM–10PM, at our Palo Alto office. Compute, dinner, and hardware prizes.
Applications close Thursday, November 12 at noon PT. Accepted participants will be notified by email Thursday night with the address and full details.
https://t.co/zkOcwkS8nD
Today we release Ripple-65B Preview, our 65B dense LLM we pretrained from scratch.
Ripple sets a new state-of-the-art for U.S. open-weight models in agentic coding tasks, surpassing significantly larger models including Muse Spark Open-816B, Beam-501B, Inkling-975B, and Nemotron 3 Ultra-550B.
Learn more: https://t.co/Pe04ZKhkE9
Ripple-65B ships with our DFlash 2 as its official drafter ⚡
Huge congrats to @RicursiveAI on the release, and thank you for building on DFlash 2 from day one!
Lossless speculative decoding, straight from the lab.
GMI Cloud is proud to be a Day 0 launch partner for Ripple-65B Preview from @RicursiveAI 🚀
It's a 65B dense model pretrained from scratch, and it sets a new state of the art for U.S. open-weight models on agentic coding tasks, ahead of much larger models.
Try it now 👇
Really happy to finally share Ripple-65B Preview! We trained it from scratch with a core team of five researchers, and it sets a new U.S. open-weight SOTA on Terminal-Bench 2.1 for agentic coding.
Three choices that shaped how we built it, and a few things I learned along the way.
1. We deliberately chose a dense model.
Many leading open-weight models are MoEs. For our use case, we wanted strong reasoning and low latency for agents going through long sequences of model and tool calls. Going dense also gave us a simpler training and serving stack and avoided expert-routing communication. That combination mattered a lot to us.
2. We bought no posttraining data.
A lot of the work went into building our own data generation and filtering pipelines, and making sure we covered the tasks we cared about. We built on open-source training and inference stacks throughout. I’m particularly happy about how much we were able to do as a small team by building on the community’s work.
3. We worked on the RL system and curriculum together.
Mixed RL meant dealing with very different rollout lengths, tool-call patterns and shares of the batch across domains. We tuned oversampling per domain and per problem to keep batch latency down, while managing policy staleness and trainer-inference mismatch. Score centering worked best among the corrections we tried; we used it alongside truncated importance sampling.
We also kept adjusting task selection and introducing harder problems as the model improved. Getting batches ready faster and keeping updates stable had to go hand in hand with giving the model useful problems to learn from.
Loved building this with @DZhang50, @esonghori2, @ethanboneh and @amiwilliamhuang. Huge thanks to our cofounders @annadgoldie and @Azaliamirh, and the whole @RicursiveAI family for making it possible. Really proud of what we built together.