Ripple-65B Preview: A $0.20 Endpoint, a Native vLLM Merge, and Three Context Numbers

The weights landed at 02:41 UTC on 4 November. Nineteen hours later someone opened a pull request to put them in vLLM's main branch, and at 17:36 UTC on 5 November it merged — 1,153 added lines across 27 files. That is fast even by the standards of a model release with a lot of attention on it, and it changes something specific: until that merge, Ripple-65B Preview — the 65B dense Apache 2.0 checkpoint from Ricursive Intelligence — had exactly one documented serving path, a plugin the authors shipped outside the engine. The question for anyone evaluating it is no longer whether it can be served. It is which of the now-official ways to serve it fits your hardware, and what each of them quietly costs you.

Two facts sit behind that question and they pull in opposite directions. Native vLLM support makes self-hosting plausible for teams that never got the out-of-tree SGLang script working. The hosted listings, meanwhile, still disagree with the model card about how much context you actually get — one service page headlines 128K in its specification sidebar while the model card section on the same page says up to 1,048,576 tokens, and the first commercial endpoint to carry the model served 16,384. Neither fact resolves what a 65B model advertising a million-token context is supposed to do when the endpoint fronting it says 128K.

What was actually missing before the merge

The clue is in the pull request's own description, which states that before it, "the only serving path was the authors' out-of-tree SGLang plugin." That plugin shipped with the model card as an SGLang 0.5.19 setup, which means anyone wanting to serve Ripple-65B Preview had to either adopt a specific engine version with an external script, or write their own model definition against a checkpoint that declares a custom architecture.

That second point is the one that quietly kills adoption. The BF16 repository carries the custom_code tag, and the config identifies the architecture as RicursiveForCausalLM — a name no engine had heard of a week ago. Loading it meant --trust-remote-code, which in most production environments is a conversation with a security reviewer before it is a technical decision.

The merge removes that step rather than working around it. The PR adds a built-in RicursiveConfig, so the checkpoint loads without --trust-remote-code, and it registers the architecture in the model registry alongside every other first-class family. A parallel effort to do the same for SGLang is still open and unmerged, so vLLM is currently the only mainstream engine where this model is a supported citizen rather than a script.

The parts of the merge that matter more than the model file

A 413-line model implementation is the unglamorous half. The interesting additions are the ones that make the model behave like the thing its benchmark numbers describe.

• Reasoning and tool calls — the merge adds --reasoning-parser ripple and --tool-call-parser ripple, which handle an optional think block and Hermes-style JSON tool calls, with streaming output matching the non-streaming form. Without these, an agentic model returns text you have to parse yourself, and the parse is where deployed agents fail.

• A validated recipe — recipes/models/ricursiveAI/Ripple-65B-Preview.yaml, 97 lines, defaults to the NVFP4 checkpoint on a single B300, with a BF16 variant and the parsers wired in. It passes the recipes repository's own validate-source.mjs. This is the closest thing to an official "run it like this" that exists for the model.

• Speculative decoding through the draft checkpoint — the repository ships a 4.04B drafter, and the merge teaches vLLM to read its NoPE layer layout via no_rope_layers. On GSM8K the PR reports mean acceptance length rising from 4.98 to 7.34 tokens per verification step.

• 158 lines of parser tests, plus a trace builder, which is the least visible and most reassuring part: the reasoning-parser behaviour is pinned by tests rather than by a comment.

Why acceptance length is the number to watch, not tokens per second

Ricursive's own efficiency figure is 250 tokens per second on two B200s at batch size 8, before quantization or custom kernels. That number was measured with the authors' own SGLang build, on the checkpoint revision they tested. It is a fine ceiling and a poor planning input, because the thing that decides whether an agent loop feels fast is how many tokens survive verification per draft pass.

The drafter helps there and only there. It proposes 16-token blocks with 32 candidates per position and reads intermediate hidden states from the target at layers 1, 20, 39, 58 and 77 — a 4.04B model whose entire job is to guess what the 64.8B model will say next. Its own card is careful about the conditions: validation ran on eight H100s under ripple-sglang against the RL-step-500 checkpoint, and the card states plainly that this "does not establish compatibility or performance for other target revisions or runtime versions."

Read that sentence twice before you build a latency budget on 7.34. It is a same-revision, same-runtime measurement. The vLLM merge changes the runtime. Nobody has published an acceptance-length figure for the merged path yet, which is the first thing I would measure on my own traffic rather than borrow.

What the download costs you, and on what hardware it fits

The BF16 instruct repo is 129.6 GB across 16 shards, and the safetensors metadata totals 64,782,689,360 parameters — dense, all of them active on every token. There is no expert routing to exploit and no way to trade active parameters for quality. If you want the full-precision model, that is the number you provision for, plus KV cache.

• Quantized path — the NVFP4 repo stores 39,616,865,360 parameters, roughly 61% of the BF16 count, and the merged recipe defaults to it on a single B300.

• Draft path — add 4.04B parameters and a second KV path if you enable DFlash2; the recipe leaves it opt-in rather than default.

• Single-workstation claims — Ricursive says the model fits on an NVIDIA DGX Spark, and a community report has it running on three Radeon AI PRO R9700 cards under ROCm 7.2.1. Both are credible for the quantized checkpoint and neither comes with a throughput figure I would quote as a service level.

• Parallelism — the merge explicitly claims tensor parallel, pipeline parallel, torch.compile and CUDA graphs, which is what makes multi-GPU serving of a 65B dense model practical rather than aspirational. Dense models split cleanly, and 65B across four 80GB cards is a comfortable tensor-parallel-4 layout in BF16.

The context window is still three different numbers

This is the unresolved item, and it survived the merge untouched because it is a serving-configuration question rather than an engine question.

The model card advertises "up to 1M context length," and the config supports positions well beyond that — long-context training stages used 2M-token sequences. The commercial listing published this week headlines a 128K context window and repeats 128K in its specification sidebar, while the same page's model card section says "context length of up to 1,048,576 tokens." At launch, the first hosted endpoint that carried the model served 16,384.

Three numbers, one checkpoint. The most likely explanation is unremarkable: the 1M figure describes what the architecture and weights can do, and the smaller figures describe what a given serving deployment has been configured and validated for. That is a normal gap. It is also the gap that decides whether the model is usable for repository-scale agent work, because a 16K window cannot hold a large diff plus its test output, and a 128K window can hold about one.

If you are evaluating Ripple-65B Preview for agentic coding, treat the context number as a property of the endpoint, not of the model, and test the endpoint. The vLLM recipe is where you can set your own.

Where this leaves the routing decision

None of this changes the shape of the choice, only the number of viable paths to it. You can now run the model yourself on vLLM with an official recipe, or call a hosted endpoint at roughly $0.20 per million input tokens and $0.60 per million output, with cached input billed at a fraction of that. Those are different products with the same weights: one gives you control of the context window and the bill, the other gives you a credit card and someone else's queue.

OrcaRouter does not carry Ripple-65B Preview — the catalogue is 200+ models and this is not one of them, which is worth saying plainly rather than implying otherwise. What that means in practice: if the reason you are looking at this model is that it is cheap and open, the comparison you actually need is against something you can reach on the same key. DeepSeek V4 Pro sits at $0.66 and $1.98 per million with a 1M context and 384K maximum output; Kimi K3.1 Pro sits at $2.00 and $10.00 with 1M context and a 943K output ceiling. Running those two through one endpoint with automatic failover is the part of the stack we can take off your hands. The Ripple half is yours to host or to buy.

What is still vendor-reported, and what an outsider found

Every capability number attached to this model comes from Ricursive. Terminal-Bench 2.1 at 80.52 is the headline, and the card also carries 80.5 on Terminus 2, 76.5 on SWE-bench Verified, 61.42 on SWE-bench Pro v1.0, 79.1 on SWE-bench Pro v2.0 Hard, 44.3 on DeepSWE 1.1, 39.4 on SciCode and 71.67 on MCP Atlas. None of it has been reproduced by an independent lab, and Artificial Analysis has no entry for the model — its models directory returns 404 for every Ripple slug I tried, which is what "unscored" looks like from the outside.

The one independent signal that exists points the other way and deserves to be stated precisely. A 157-test suite called Cold Iron scored the model 93 out of 157 and placed it 28th of 28, five points behind the next-lowest entry. The author's own breakdown is more interesting than the rank: of 64 failures, 12 were provider timeouts returning zero tokens and 49 were finish=length — the model ran out of a 4,096-token output budget before producing a gradeable answer. Only three were content misses. Crediting the timeouts would move it to 105, still about 26th.

That is a result about serving configuration as much as about capability, and it is exactly the class of failure that native engine support with a validated recipe is supposed to reduce. A model that exhausts a 4K output cap on coding tasks is a model being run wrong, not necessarily a model that cannot code.

What to watch next

Three things would settle this model faster than any further coverage. An independent score — the moment Artificial Analysis or LMArena picks it up, the vendor table becomes checkable rather than quotable. A merge on the SGLang side, which would end the single-engine situation. And a checkpoint without "Preview" in its name, since Ricursive has described this release as deliberately lightly post-trained, with the real internal product being a chip-design variant.

Until then, the honest summary of this week is narrow and useful: the serving story improved materially in 36 hours, the capability story did not change at all, and the context-window question moved from the model card to your own configuration file.