Ripple-65B Preview is becoming another model builders can evaluate through Ollama, which serves language models on hardware they control. Native support merged in ollama/ollama on November 8. Ricursive’s model stores far fewer parameters than the four American open-weight competitors in its launch comparison. Yet it activates more parameters per token than any of them.
A parameter is a learned numerical value. Ripple uses a dense network rather than selecting among expert networks for each token—the pieces of text a model processes. A mixture-of-experts model combines shared computation with a selected portion of its experts. Builders considering local coding models therefore face two size questions before a speed test: what must be stored, and what gets used for each token?
Fewer total.
More active per token.
Read right for more total parameters; read up for more active parameters per token. Both axes start at zero and use a linear scale. The numbered points match the models in the table.
Active per token (billions)
Total parameters (billions)
| Model / point | Total | Active per token |
|---|---|---|
| 1 · Ricursive Ripple-65B Preview | 65 | 65 |
| 2 · Reflection Beam | 501 | 23 |
| 3 · NVIDIA Nemotron 3 Ultra | 550 | 55 |
| 4 · Meta Muse Spark Open | 816 | 42 |
| 5 · Thinking Machines Inkling | 975 | 41 |
Source: Ricursive’s Ripple-65B Preview model card, checked November 8, 2026. Ricursive selected these peers; this is not an independent survey. Ripple is dense; the other four models use mixtures of experts.
Counts, not performance: these values do not measure speed, cost, total RAM requirements or task quality.
The smaller stored set gives builders a reason to investigate Ripple for hardware that cannot accommodate those larger models at the same precision. The active count gives them a separate question about execution. Both facts can be true without either model being universally easier to run.
The choice was deliberate. Ricursive’s launch account describes a general-purpose version of the model behind its chip-design platform. The lab says it chose a dense architecture partly to simplify training and serving infrastructure. Its design still combines different attention patterns and other modifications; “dense” does not mean an off-the-shelf model can simply be relabelled.
Neither count measures inference cost, speed, hardware fit or task quality. Precision changes how much space each value occupies. Working memory also holds intermediate calculations and the conversation’s attention cache. Hardware, kernels, context length and workload affect execution. The table identifies an architectural tradeoff to test; it does not establish that Ripple runs faster, slower or more cheaply.
What Ollama adds to the choice
Ollama’s new implementation makes that evaluation more concrete. Its native model support maps the stored weights into Ripple’s layers and checks their shapes and quantization layouts. The computation handles the architecture’s combination of sliding-window and full attention. This supplies execution machinery through the MLX runner, whose platform paths include Metal and CUDA.
Two other jobs connect those calculations to an agent conversation. The renderer turns messages, tool definitions, earlier calls and tool responses into the model’s expected input. The parser separates generated reasoning, answer text and tool calls, including streamed output. An application still has to authorize and execute a requested tool. Together, these pieces let a builder assess conversation and tool interaction alongside model execution.
As checked on November 8, Ollama’s latest stable release, dated November 3, predates the merge. Testing this path requires an appropriate build. Ripple already had local inference: Ricursive publishes SGLang instructions for two NVIDIA B200 GPUs. Ollama adds another implementation through which builders can evaluate the model.
The workload decides
Ricursive’s benchmark comparison uses BF16 precision and maximum effort, combining published competitor scores with some in-house evaluations. It acknowledges harness-dependent results. Those figures do not establish equivalent coding quality for a quantized Ollama build. Its experimental NVFP4 checkpoint quantizes feed-forward layers while retaining BF16 attention; the name does not mean every parameter becomes four-bit.
We inspected the source without running tests or inference. The new runner tests use a tiny synthetic model to exercise requests, cancellation and cache recovery. They do not measure full-checkpoint coding performance.
For a team choosing a local coding model, Ripple expands the set worth testing. The useful next comparison is a released build completing a reproducible coding task, with its precision, machine, context length, memory and elapsed time recorded. The decision is whether the smaller stored set produces the required work within that machine’s constraints. Its parameter label alone cannot answer that.
