Ricursive Opens Ripple-65B Preview, Using a Dense Architecture for Coding Agents and Million-Token Context

Ricursive Intelligence released Ripple-65B Preview on November 4, a general-purpose version of an internal model used in its chip design platform. The release includes BF16 instruction-tuned, NVFP4-quantized, and BF16 base-model weights under the Apache 2.0 license. OpenRouter has also listed the model as a hosted service, allowing developers to evaluate it through an API before deciding whether to self-host. Official announcement, model card, service page

The technical highlight is a 65-billion-parameter dense Transformer. The team says this choice is intended to reduce infrastructure complexity during pretraining and post-training. The model uses a narrow, deep configuration with 80 layers and a hidden dimension of 5,120, increases the proportion of sliding-window attention relative to global attention, and adds gated attention and numerical-stability measures. This represents a different set of training tradeoffs, but a lower total parameter count does not directly imply lower compute cost per token, since a dense model uses all of its parameters on every pass. Architecture details

The model was pretrained on 12 trillion tokens, primarily English text and code, then underwent mid-training, long-context training, supervised fine-tuning, and mixed-domain reinforcement learning. It is listed as supporting context lengths of up to about one million tokens. Chinese teams will still need to assess it using Traditional Chinese document retrieval, cross-file editing, and tool-calling tests. A long context window alone also does not guarantee that the model can reliably use all of its contents. Training data and process

The company reports a score of 80.5 on Terminal-Bench 2.1, while its table lists 76.5 on SWE-bench Verified, below some comparison models. The model card also notes that scores for several competing models change when using the official Terminus 2 framework, a 128K context window, and a summarization mechanism. These results should therefore be treated as benchmarks reported by the publisher, not as a ranking that applies to all coding workloads. Engineering teams should standardize the agent framework, context budget, and number of retries, then compare task success rates, latency, and memory use for BF16 and NVFP4 to determine whether the open weights offer practical deployment benefits. Evaluation methods and limitations