Ricursive Releases Ripple-65B: Model Scores 80.5% on Terminal-Bench 2.1

When an agent fixes a bug, money and time go into the whole route: reading files, finding the cause, making the change, running tests and dealing with a new error. Ricursive offers Ripple-65B Preview for this kind of work. The practical interest is clear: to check whether the model can handle your repository at acceptable latency and cost. For example, whether it can fix a broken API handler on its own and confirm the result with a test.

This is an open-weights model with 65 billion parameters. In the assessment published by the developers, it scored 80.52% on Terminal-Bench 2.1. Reflection Beam gets 80.1% in the same table. The difference is small, so a headline about an outright victory would be excessive here. What is more interesting is the chance to get one more candidate for a coding agent. Source: Ricursive.

What exactly was released

Ripple uses a dense architecture: unlike mixture-of-experts models, it uses all of its parameters when processing each token. That is why comparing by total size alone can be misleading. In a larger mixture-of-experts model only some of the parameters are active at any one time; a smaller number in the name does not by itself promise a cheaper response.

The developers state a context window of up to 1,048,576 tokens. The weights are published under Apache 2.0, with BF16 and NVFP4 variants available. For teams with requirements on where code is hosted, this widens the choice: self-hosted deployment can be considered. But the size of the context does not yet show how reliably the agent will find the right dependency among hundreds of files. Source: model card.

It is useful to separate two tasks here. The first is hosting the model and achieving acceptable response speed. The second is building an agent that correctly uses search, the terminal and tests. A good result on the first does not guarantee success on the second. A long context also does not remove the need to choose which files to pass to the model.

Why the benchmark result cannot be transferred directly to your repository

The authors themselves describe how sensitive agentic evaluations are to run conditions. The model card notes that changing the harness and context settings changed Terminal-Bench results. Their comparison table combines official figures from other labs with their own measurements where published data was lacking. This limits the accuracy of a direct comparison. Evaluation methodology.

Consider an ordinary bug: after a dependency update, user login stopped working. The agent must read the error message, find the changed call, fix the handler and run a suitable test. A nicely worded explanation of the cause is not enough here. What is needed is a working fix that preserves the existing behavior of the other scenarios.

Now add real-world conditions: the test database is unavailable, the documentation is outdated, and the error reproduces only with a certain configuration. This is where differences between models and agent setups show up. One will need a hint from a human, another will start changing unnecessary files, a third will correctly state what data it is missing. An overall benchmark score does not replace such a check.

How to check the value for your team

I would start with a small set of already solved tasks: fixing a bug, adding a test, changing an API and working with an unfamiliar module. Each needs the initial state of the project and a clear success criterion. Then give Ripple and your current model the same tools, time limits and access to the environment.

It is better to count the cost of an accepted fix. That includes retries, command execution time and human review. Cheap tokens help little if a developer then spends half an hour removing unneeded changes. Separately, it is worth recording cases where the agent declared a task solved even though the result was never verified.

For a product, this is a way to make a concrete decision: whether Ripple suits the chosen class of tasks, whether extra verification is needed and when to hand work to a human. Open weights make such an experiment more accessible in terms of control over deployment. The basis for switching should be results on your own code, together with time, costs and the quality of the fixes.