Ripple-65B: a dense 65B coder at 15 tokens/s on one 48 GB card, 2-bit on 24 GB
A dense 65B coder on one 48 GB card: 15 tokens/s, a 237K-token prompt answered right, and a real 24 GB RTX 3090 at 2 bits with one wrong test.
Ripple-65B ships as about 130 GB of weights. The card we ran it on has 48 GB. At 4 bits per number, a 38.8 GB file, it fit on one RTX A6000 and wrote about 15 tokens (roughly words) per second, because each word passes through the whole model. At 2 bits it also ran on a real 24 GB RTX 3090, and faster, but in one of its three coding answers the model wrote a test with the wrong expected result.
On one agent benchmark, its authors put it level with open models of 501B to 975B
On Terminal-Bench 2.1, a test of agents working in a command line, Ricursive puts Ripple at 80.5. In their own table that is a 0.4-point lead over Reflection Beam, effectively a tie, and ahead of three larger open models. Terminal-Bench is its headline lead. On most other rows in the same table a rival is ahead.
| Terminal-Bench 2.1 (authors' numbers) | Total size | Score |
|---|---|---|
| Ripple-65B Preview | 65B | 80.5 |
| Reflection Beam | 501B | 80.1 |
| Meta Muse Spark Open | 816B | 76.4 |
| Thinking Machines Inkling | 975B | 63.8 |
| NVIDIA Nemotron 3 Ultra | 550B | 56.4 |
The size column flatters Ripple: the rivals are bigger, but each word they write uses only 23B to 55B parameters. Ripple uses all 65B.
This row is self-reported. The authors admit "replicating benchmark scores has been challenging" and call it a "best-effort attempt". When they reran the rivals on the benchmark's official setup, three of four scored lower than in this table. Our own reading of their table: on SWE-bench Verified, built on real GitHub issues, Ripple scores 76.5 against 81.6 for Reflection Beam.
On the BenchLM mirror of Vals' public Terminal-Bench 2.1 board, five leading entries run from 92.8 (Cognition's SWE-2) to 80.4 (Claude Sonnet 5). That board uses a different test setup, so its numbers do not rank against the authors'. Ripple is a strong open result, not a claim to beat the best closed coders.
Why it matters now: a US lab trained an open coder from scratch and gave it away under Apache 2.0, with no form to fill in. Ricursive puts the whole research bill at $32M, its own estimate. The weights went up on Hugging Face on 4 November. The authors say it was trained on 12 trillion tokens and reads prompts of up to about a million.
Ricursive's own builds target data-center hardware that most teams do not own. The route we took is the one the community opened in two days. A port of Ripple into llama.cpp, a free program for running models on your own card, was merged on 5 November. Nik Bogatyrev submitted the port, which AtomicChat's card says it wrote. AtomicChat published llama.cpp files the same week, from 129.6 GB (full precision) down to 18.5 GB. A llama.cpp update on 6 November could read them.
Dense means 15 tokens per second: every word reads all 65 billion parameters
Ripple wrote 14.3 to 16.3 tokens per second on the A6000. That is the price of the design.
Every rival in Ricursive's table is a mixture of experts: each word uses only part of the model. Ripple is dense: every word goes through all 65 billion parameters. At 4 bits that means reading nearly the whole 38.8 GB file from memory for each word, and the A6000 can do that about 15 times a second. That reading speed, not the chip's arithmetic, is the ceiling.
The closest reference is Nanbeige4.3-33B, a dense coder we tested two days ago. It has half the parameters, so about half the bytes to read per word. It wrote about 42 tokens per second on a 24 GB RTX 4090, a different card. Clover-35B-A3B, which uses about 3 billion parameters per word, wrote 208 on that same RTX 4090.
In practice, 15 tokens per second means a 400-token answer in about 27 seconds. Short questions start answering in under a second. For one developer driving an agent that is workable, not snappy.
Our test: one 4-bit file on one 48 GB card, our own prompts
We used AtomicChat's plain 4-bit file, 38.8 GB, entirely on one RTX A6000. It ran on our standard llama.cpp setup. Most calls went through the same kind of API your product would call.
Our checks were small: a one-word answer, a coding task with its own tests, two kinds of tool call, a fact hidden deep in a long prompt, and one agent job. A tool call is the model asking your program to run something, here a shell command or a weather lookup.
The agent job was a toy repository where we had planted an off-by-one bug that made a test fail. The model had one tool, a shell, and every command it sent ran inside a sandbox with no network.
Here are our limits. We sent one request at a time, and each check ran once or a few times: 4 coding answers with the 4-bit file, 3 on the 3090. The prompts were ours, not the authors' benchmarks, which we did not reproduce. We did not try the authors' own serving setup or their speed-up helper model.
It fixed a planted bug in a toy repo, and every tool call we made was valid
Every tool call came back valid, alone or inside the agent runs, in the standard format existing agent code reads. Before each one Ripple thinks for a sentence or two. Plain questions get a straight answer.
On the A6000, Ripple read the code, ran the tests, saw them fail, and changed one <= to <. It reran the tests, saw them pass and reported back, 6 turns in all. It never touched the tests themselves.
| What we asked | What came back | Time |
|---|---|---|
| "Capital of Australia, one word" | Canberra, no thinking | about 0.5 s |
| A function that merges number ranges, with its own tests | Correct code, tests pass | 12.4 s |
| "Which directory am I in?" with a shell tool | A valid pwd command | 4.8 s |
| "Is it warmer in Lisbon or in Oslo?" | Two weather calls at once, both valid | 7.1 s |
| Fix the failing test in a sandboxed repo | Bug fixed, tests untouched | 35 s |
Long prompts are cheap in memory: 237,532 tokens fit on 48 GB, at 13 minutes to read
The same 48 GB card took prompts up to 256K tokens and found a passphrase hidden at token 237,532, using about 46 GB. This was one hidden-passphrase test per length: it shows the model can find a fact, not that it can reason across a whole codebase.
The reason is in how Ripple remembers what it has read. While reading, a model keeps notes on every token, and those notes usually grow fast with the prompt. Ripple has 80 layers, like 80 people in a meeting, and only 16 note the whole prompt. The other 64 keep only the last 1,024 tokens. The notebook stays small, and for longer prompts we compressed it too.
| Longest prompt allowed | Notes compressed to | Peak memory | Passphrase at | Answer took |
|---|---|---|---|---|
| 32K tokens | no (16-bit) | 42.6 GB | 25,930 tokens | 48 s |
| 128K tokens | 8-bit | 44.4 GB | 118,836 tokens | 292 s |
| 256K tokens | 4-bit | 45.6 GB | 237,532 tokens | 760 s |
All three found it. The catch is time. Reading 237,532 tokens took about 13 minutes, and a 400-token answer then took about a minute. The full million is out of reach on one 48 GB card: 256K with compressed notes is about its limit.
Which GPU: a real 24 GB RTX 3090 works with the 2-bit file, with one wrong test in three
The smallest card that passed is a real RTX 3090, a 24 GB gaming card, with AtomicChat's 2-bit file of 20.0 GB and prompts up to 16K tokens. Fewer bits per number means a smaller file and less to read per word, but rougher numbers and more mistakes.
Two rows below are budgets: we ran them on the 48 GB A6000 to see if the file fits in 32 or 24 GB. Their speeds are A6000 speeds.
| Card or memory budget | File and longest prompt | Peak memory | Speed (tokens/s) | Checks | Real card? |
|---|---|---|---|---|---|
| RTX A6000 48 GB | 4-bit, 32K to 256K | 42.6 to 45.6 GB | 14 to 16 | all right, 4 of 4 coding answers across the 32K, 128K and 256K runs | yes |
| 32 GB budget | 3-bit, 32K | 29.8 GB | 16 to 18 | agent passed, 1 of 2 coding answers with a wrong test | no, run on the A6000 |
| 24 GB budget | 2-bit, 16K | 21.2 GB | 21 to 22 | agent passed, 2 of 2 tests pass but one function never sorts its input | no, run on the A6000 |
| RTX 3090 24 GB | 2-bit, 16K | 21.9 GB | 23 to 31 | agent passed, 1 of 3 coding answers with a wrong test | yes |
| RTX 5090 32 GB | 3-bit | none | none | no result: the host downloaded too slowly | yes, no result |
| 16 GB | none | not tried: the smallest file is 18.5 GB |
The slips point the same way as what AtomicChat measured. Their card says the full model and the 4-bit file disagree on the next word about 7 times in 100, the 3-bit file about 9, the 2-bit file almost 20. The bug-fix job did not catch any of this, because it never asked the model to write new tests. Writing new code is where the small files show it.
So the 48 GB card is the clean result, not a requirement. A 24 GB card runs the model, and you should review what it writes.
On InferenceKey: ready in 19 seconds, because nothing had to be built
Once the file was on the machine, our standard llama.cpp setup had Ripple answering 19.0 seconds after we asked for it. The 3090 took 19.3 seconds.
On InferenceKey, a worker is the small program on your GPU machine that takes orders from the platform. We told the worker to download a ready-made llama.cpp for NVIDIA instead of building it.
The problem you can hit: without that setting, our worker builds llama.cpp itself on NVIDIA machines, 5 to 20 minutes in earlier tests. Status: open on our side. The SDK example sets it by default, so it does not hit this.
This run used a local copy of the platform, not the hosted service. The SDK example runs the model on one machine you name. Requests go through the InferenceKey endpoint on their way to it.
Should you use it? Yes on 48 GB if you can live with 15 tokens per second
- You have a 48 GB card and want an open coding agent you control: worth a try. The 4-bit file gave our cleanest results.
- You need long prompts: a 237K-token prompt fit on 48 GB. Plan on minutes per question, not seconds.
- You have a 24 GB card: the 2-bit file runs, and faster, but review its tests.
- You need speed above all: look elsewhere. Being dense, Ripple reads the whole model for every word.
We ran one request at a time, so a card shared by several agents will be slower than this, by an amount we have not measured, and this is a Preview with what Ricursive calls "relatively light posttraining".
To run the same coding task and tool call on your own 48 GB NVIDIA worker, run python main.py from the Ripple-65B SDK example. It needs a project, an SDK token and an API key, and deletes the deployment when done.
For engineers
Credits
- Ricursive Intelligence: the model, trained from scratch; the BF16, NVFP4 and DFlash2 drafter repos, all Apache-2.0 (the Base repo is linked from the card; its license was not checked); the model card, benchmark table, chat template and server recipe; the launch post.
- Nik Bogatyrev (notforu777): llama.cpp PR #31692, "model : add Ripple (ricursiveai)", merged 2026-11-05 (merge commit
fecdc81e, +406/-3, no new ggml ops; KLD 0 and top-1 100% against the vendor code on a tiny random model and the first 10 real layers; BF16 PPL 3.01; AI usage disclosed). The AtomicChat GGUF card says AtomicChat wrote the port. - AtomicChat: the GGUF quants we used (plain Q4_K_M, AD-IQ3_XXS, AD-IQ2_XXS) and their KLD and top-token table.
- The llama.cpp maintainers: release b12167 (2026-11-06), with prebuilt
ubuntu-cuda-12.8-x64andubuntu-cuda-13.4-x64tarballs, plus the--jinjatool-call parsing. - AI Search: where we spotted it (2026-11-08 news video, chapter at 41:26).
- Our part: the deployment through the platform, the prompts and the sandboxed agent task, the long-context runs, the memory ladder on two real cards plus two A6000 runs sized to 32 and 24 GB budgets, the SDK example and the demo video.
Model and files
ricursiveAI/Ripple-65B-Preview: shada94cc01, created 2026-11-04T02:41Z, last modified 2026-11-06, about 129.6 GB BF16 in 16 shards, not gated. NVFP4 repo99eea447(6 shards, about 57.2 GB; "experimental", NVFP4 MLP and BF16 attention; shipsspark.pyand a notebook). DFlash2 drafter35609b3b(4.04B params, BF16 about 8.08 GB). AtomicChat GGUFdf550a71.- Architecture:
RicursiveForCausalLM(custom code,model_typericursive), 80 layers in a 4:1 pattern (64 sliding-window layers, window 1,024, RoPE; 16 global full-attention layers with NoPE), hidden 5120, FFN 40960, 80 query heads / 8 KV heads, head_dim 128, vocab 100,352,max_position_embeddings2,097,152, gated attention, value residuals, FFN clamp 20, embed scale sqrt(5120). The card calls it "Gemma 3N-like" and "thin-and-deep", started from an Olmo 3 baseline. - Training stages (card): pretrain 12T tokens at 8K; midtrain 200B at 64K; long context 6.5B at 2M; SFT 183B at 128K; long-context SFT 13.5B at 2M; RL 700 steps at 128K. "Relatively light posttraining, with a focus on agentic coding."
- KV cache at f16: 16 global layers x 8 x 128 x 2 x 2 B = 64 KiB per token, plus the sliding-window ring. By that arithmetic 1M at f16 is about 64 GiB of cache alone.
- AtomicChat sizes and same-top-token rate vs BF16: Q4_K_M 38.8 GB 93.0% (mean KLD 0.0380); AD-IQ4_XS 38.7 GB 95.6%; AD-Q4_K_M 40.4 GB 95.9%; AD-IQ3_XXS 28.0 GB 91.2% ("32 GB (RTX 5090)"); AD-IQ2_XXS 20.0 GB 80.8% ("24 GB (RTX 3090 / 4090)"); AD-IQ1_M 18.5 GB 76.8% ("research"); Q8_0 68.8 GB; BF16 129.6 GB. Their own speed: plain Q4_K_M on one GH200 96 GB, prefill 309 tokens/s, decode 40.6 tokens/s. Ricursive publishes no default sampling.
- Vendor claims we did not verify: team "scaled from 1 to 5 people", 40% MFU with simple sharding and no custom kernels, "can fit on consumer hardware such as the NVIDIA DGX Spark", "250 tok/s on 2xB200 batch=8 prior to quantization or custom kernels", $32M total R&D (their estimate), RL to 80.5 with 1.4M rollouts, quality at 1M context.
Authors' benchmarks (not reproduced)
From the model card; all models at full BF16, max effort; italic cells in their table are Ricursive's own runs of the rivals.
| Benchmark | Ripple-65B | Best other in their table |
|---|---|---|
| Terminal-Bench 2.1 | 80.5 | Reflection Beam 80.1 |
| Terminal-Bench 2.1, Terminus 2 harness | 80.5 | Muse Spark Open 78.7 (Beam 70.8, Inkling 56.2, Nemotron 55.1) |
| SWE-bench Verified | 76.5 | Reflection Beam 81.6 |
| SWE-bench Pro v1.0 | 61.42 | Reflection Beam 66.1 |
| SWE-bench Pro v2.0 Hard | 79.1 | best in table |
| DeepSWE 1.1 | 44.3 | Muse Spark Open 60.0 |
| MCP Atlas | 71.67 | Muse Spark Open 89.2 |
| SciCode | 39.4 | Muse Spark Open 58.5 |
| GPQA Diamond | 85.2 | Reflection Beam 90.6 |
| AIME 2026 | 95.0 | |
| AA-LCR | 75.0 | Muse Spark Open 80.7 |
| IFBench | 79.2 |
Rivals are all mixture-of-experts models with 23B to 55B active parameters; Ripple's active count is its full 65B. Public context: five leading entries on the BenchLM mirror of Vals Terminal-Bench 2.1 (updated 2026-11-07): SWE-2 92.8, GPT-5.6 Sol 91.9, Claude Mythos 5 88.0, Claude Fable 5 84.3, Claude Sonnet 5 80.4. Harnesses differ from the authors', so the rows are not directly comparable.
Setup
- GPUs on InferenceKey Cloud: RTX A6000 48 GB (46,068 MiB, 300 W, compute capability 8.6) for the main run; RTX 3090 24 GB (compute capability 8.6) for the real 24 GB rung.
- Backend: the built-in
llamacppbackend,INFERENCEKEY_LLAMACPP_TAG=b12167(the worker default tag is older and cannot read thericursivearchitecture) andINFERENCEKEY_LLAMACPP_ASSET=ubuntu-cuda-13.4-x64. The tarball's libraries resolved to the image's CUDA 13libcublas.so.13/libcudart.so.13; the separatecudart-llama-*tarball is not fetched. - Why llama.cpp and not vLLM or SGLang: the architecture is custom. The vendor's server recipe (
inference/serverin the BF16 repo) runs SGLang 0.5.19 with Ricursive's own model code: unquantized BF16 target plus native DFlash2, TP=2 on two B200, 1Mi default context, Ripple reasoning and tool-call parsers. Ricursive also says the experimental NVFP4 build fits a DGX Spark (untested by us). Separately, the DFlash2 card names aripple-sglangruntime, used for an export validation on 8x H100 with the RL-step-500 target. Whether stock vLLM or SGLang loads the model without Ricursive's extra code was not checked. llama.cpp support is upstream since b12167, and the GGUF is what fits one card. --jinja --reasoning-format deepseek: the template's<tool_call>{json}</tool_call>came back as OpenAItool_calls; reasoning before tool calls (61 to 213 characters) landed inreasoning_content, content never empty.- A local InferenceKey manager, built from our main branch (
435050e1), reached by the workers through tunnels. Production never touched. Sampling temperature 0.6, top_p 0.95; ladder rungs with seed 42.
Step by step with the SDK example
- Clone inferencekey-sdk and open
examples/ripple-65b-agent-llamacpp-private-nvidia(commitea32931f8486a5ff164c57a7a6c3abaea64cfc90). cp .env.example .envand fill inINFERENCEKEY_SDK_TOKEN,INFERENCEKEY_API_KEY,INFERENCEKEY_PROJECTandIK_WORKER_ID(a private NVIDIA worker with 48 GB). Optional:RIPPLE_GGUF_FILE(Q4_K_M by default),RIPPLE_CONTEXT(32768),RIPPLE_KV_TYPE(f16),RIPPLE_LLAMACPP_TAG(b12167),RIPPLE_LLAMACPP_ASSET(ubuntu-cuda-13.4-x64; empty builds from source),IK_KEEP_ALIVE=1.pip install -r requirements.txt(requests>=2.31) plus the local SDK build with maturin (the SDK is not on PyPI).- The prebuilt asset needs a CUDA 13 driver and
libcudart.so.13/libcublas.so.13on the worker. It has not been tried on Blackwell cards (sm_120). python main.py. Itensure()s a fixedllamacppworkload pinned to your worker, waits up to 3,600 s, sends a coding task withgenerate_text(), makes oneexecute_bashtool call and returns a canned result, writesoutputs/answers.jsonand callsdelete()unlessIK_KEEP_ALIVE=1.
The launch command the backend runs:
INFERENCEKEY_LLAMACPP_TAG=b12167 \
INFERENCEKEY_LLAMACPP_ASSET=ubuntu-cuda-13.4-x64 \
llama-server \
-hf AtomicChat/Ripple-65B-Preview-GGUF \
--hf-file Ripple-65B-Preview-Q4_K_M.gguf \
--alias ripple-65b-preview -ngl 99 -fa on \
-c 32768 -ctk f16 -ctv f16 \
--jinja --reasoning-format deepseek
For 128K use -c 131072 -ctk q8_0 -ctv q8_0; for 256K -c 262144 -ctk q4_0 -ctv q4_0. For a 24 GB card set RIPPLE_GGUF_FILE=Ripple-65B-Preview-AD-IQ2_XXS.gguf, RIPPLE_CONTEXT=16384 and RIPPLE_KV_TYPE=q8_0.
Timings
| Step | RTX A6000 | RTX 3090 |
|---|---|---|
ensure() to ready | 19.0 s | 19.3 s |
| llama.cpp tarball (169 MB) download and install | about 1 s | |
| Model load | about 8 s | |
| GGUF pre-download (not on the ready path) | 32 s (Q4_K_M) | 41 s (AD-IQ2_XXS) |
| Direct llama-server restart, warm | 7.0 to 13.4 s to /health |
Worker log on the A6000: install_llamacpp ok at 06:52:07, llama-server spawned 06:52:15, model ready 06:52:23 (UTC).
Speed and outputs (RTX A6000, Q4_K_M, 32K, f16 cache, streaming through the endpoint)
| Test | Completion tokens | Seconds | First token s | Decode tokens/s | Result |
|---|---|---|---|---|---|
| Capital of Australia x2 | 3 / 4 | 0.46 / 0.57 | 0.31 / 0.35 | 20.6 / 18.0 | Canberra, no thinking |
merge_intervals + 3 asserts | 174 | 12.37 | 0.33 | 14.4 | asserts pass in the sandbox |
execute_bash "Which directory am I in?" | 65 | 4.82 | 0.56 | 15.3 | {"command": "pwd"}, 154 chars of reasoning |
Lisbon or Oslo, get_weather | 93 | 7.1 | 0.88 | 14.9 | two parallel calls |
| Agent: fix the failing test | 410 in 6 turns | 35.2 | 14.5 to 15.5 per turn | <= to <, pytest 2 passed, tests untouched | |
| Needle, 25,930-token prompt | 6 | 48.53 | 48.16 (about 540 tokens/s prefill) | 16.3 | found |
SDK example runs: A6000 Q4_K_M ready 19.0 s, code 12.9 s (asserts pass), pwd call 4.47 s, final answer 1.22 s at 15.7 tokens/s. RTX 3090 AD-IQ2_XXS ready 19.3 s, code 9.0 s with a wrong third assert, tool call 3.02 s, answer 2.26 s at 25.9 tokens/s.
VRAM ladder
Peak VRAM from nvidia-smi sampled every 0.5 s. Budget rungs ran on the A6000 and peaked under the budget; their speeds are A6000 speeds.
| GPU or budget | Config | Peak VRAM | Speed | Output OK | Real or emulated |
|---|---|---|---|---|---|
| RTX A6000 48 GB | Q4_K_M, 32K, f16 (the example, through the endpoint) | 40,593 MiB | 14.3 to 16.3 tokens/s; agent 6 turns 35.2 s (take 5 turns, 439 tokens, 36.3 s) | yes; code 2 of 2 | real |
| RTX A6000 48 GB | Q4_K_M, 128K, q8_0 | 42,373 MiB | 13.5 to 14.3; needle 118,836 tokens in 292.3 s, 9.1 at depth | yes | real |
| RTX A6000 48 GB | Q4_K_M, 256K, q4_0 | 43,440 MiB | 13.5 to 14.3; needle 237,532 tokens in 760.4 s, prefill 312.9 average, 6.8 at depth | yes | real |
| 32 GB budget | AD-IQ3_XXS (28.0 GB), 32K, q8_0 | 28,395 MiB | 16.4 to 17.8; agent 5 turns 29.6 s; needle 25,930 tokens found | agent yes; code 1 of 2, wrong test [(5,7),(1,2),(3,4)] == [(1,2),(3,7)] | emulated on the A6000 |
| 24 GB budget | AD-IQ2_XXS (20.0 GB), 16K, q8_0 | 20,249 MiB | 20.6 to 21.9; agent 6 turns 36.7 s; needle 12,562 tokens found | agent yes; code 2 of 2 asserts pass, but one function never sorts its input | emulated on the A6000 |
| RTX 3090 24 GB | AD-IQ2_XXS, 16K, q8_0, through the endpoint | 20,901 MiB (about 130 W) | 23.6 to 30.9; agent 7 turns 32.0 s (take 5 turns 28.7 s); needle 12,562 tokens at 22.5; two weather calls 4.38 s | agent yes; code 2 of 3, wrong test [(5,5),(5,5),(3,4)] == [(3,5)] (function correct) | real |
| RTX 5090 32 GB | AD-IQ3_XXS (32K, q8_0 planned, never launched) | none | none | no result: download stalled at 14.49 GB (about 12 MB/s) | real card, no result |
| 16 GB | none | not tried: smallest file AD-IQ1_M is 18.5 GB |
Code totals across rows: Q4_K_M 4 of 4 (the 32K, 128K and 256K runs); AD-IQ2_XXS 4 of 5 with passing asserts across the 24 GB budget and the real 3090, one of them with the sort bug; AD-IQ3_XXS 1 of 2.
Not tried: the experimental NVFP4 checkpoint (57.2 GB; our estimate is a 96 GB Blackwell card such as the RTX PRO 6000, while Ricursive's card names the DGX Spark and the NVFP4 repo ships a spark.py); the authors' BF16 + DFlash2 recipe on 2x B200 (the DFlash2 drafter is a 4.04B model that drafts 16-token blocks to speed up writing); the authors' benchmarks; 512K or 1M context; AD-Q4_K_M and AD-IQ4_XS (better top-token rates at a similar size); an L40S; multi-request throughput; a real RTX 5090; the CUDA 13.4 tarball on Blackwell (sm_120).
Remaining problems
- The worker builds llama.cpp from source on NVIDIA by default.
asset.rssays the release publishes no Linux CUDA tarball, which is no longer true since b12167 ships two. PinningINFERENCEKEY_LLAMACPP_ASSETworked on both cards. Open: prefer the CUDA tarball when the driver and libraries allow it. - The container-disk environment variable is no longer read by the manager; the disk size came from the request's
min_disk_gb=100(87 GB of GGUFs, 82% used). Open, documentation to update. - Two unusable hosts: one RTX 3090 host exposed no direct TCP SSH and the manager terminated it after 180 s; one RTX 5090 host downloaded at about 12 MB/s and was deleted after about 16 minutes without a result. The hosts of the runs that worked downloaded at 1.0 to 1.2 GB/s.
- Quality on the 3-bit and 2-bit files: one wrong test each, and one 2-bit answer that never sorts its input. The bug-fix agent task does not exercise this.
- Workload display name hard-coded to "Q4_K_M" in
main.pywhile serving the 2-bit file on the 3090. Fixed in the example before the commit; masked in the video.
Demo video
The 165-second narrated demo: the authors' material first (model card, benchmark table next to the public board, the coding rows where Ripple is not first, AtomicChat's file sizes), then the deployment in the panel on the RTX A6000, the sandboxed bug fix, the long-context results, and the 24 GB RTX 3090 with the key comparison.
Sources
- ricursiveAI/Ripple-65B-Preview (model card, config, chat template, server recipe).
- ricursiveAI/Ripple-65B-Preview-NVFP4.
- ricursiveAI/Ripple-65B-Preview-DFlash2.
- AtomicChat/Ripple-65B-Preview-GGUF.
- llama.cpp PR #31692 and release b12167.
- Ricursive launch post.
- BenchLM mirror of the Vals Terminal-Bench 2.1 board, updated 2026-11-07.
- Our earlier tests of Nanbeige4.3-33B and Clover-35B-A3B, both on an RTX 4090 24 GB.
- AI Search news video, 2026-11-08 (where we spotted it).
- SDK example, commit
ea32931f8486a5ff164c57a7a6c3abaea64cfc90.