What happened
Ollama’s release notes for v0.40.16 identify Ripple Preview as a dense 65B model built for agentic coding and give the command ollama run ripple-preview. The release says the model is from Ricursive Intelligence. For an Ollama user, the practical change is a named command to fetch and run the model through the local runtime rather than manually locating an artifact or constructing an integration.
The notes are notably narrow about the model itself. Ollama does not include a model card, benchmark results, hardware requirements, quantization information, or configuration details for Ripple Preview. It also does not state the context window supported by the tag. The release therefore establishes an Ollama launch path, not the performance, capacity, or machine requirements that a team should expect in a particular deployment.
The same release makes changes to Ollama’s runtime and interfaces. ollama launch claude now always routes Claude Code to the selected model. That makes the selected model the explicit destination for the launch command. For developers using Claude Code through Ollama, this is a workflow-level change: model selection in the launcher should determine which model receives the coding-agent requests.
Ollama also says /v1/responses respects truncation and no longer silently truncates by default. This matters for integrations that consume generated output programmatically. A client that assumed a complete response without checking truncation-related behavior may need to validate its handling. The release notes do not describe every response representation or client interaction, so the exact effect remains something integrators must test in their own applications.
Other listed changes include about 27 GiB less memory use for Qwen3.8 Flash Next on Apple silicon; an explanation when a cloud model has been retired; /v1/models returning an empty list rather than null when no models are installed; CUDA 13.5 support for Windows on ARM; and an updated llama.cpp. GitHub records the release as published on November 9 and says there were 15 commits to main since v0.40.16. The notes state neither a price nor access restrictions for Ripple Preview.
What the archive adds
New Runtime covered Ripple-65B Preview’s initial release on November 4, 2026 and its Ollama availability on November 10, 2026. This is a new Ollama runtime release event rather than a new model announcement. It adds the specific ripple-preview command and related runtime behavior, but does not settle questions around reported context size or benchmark reproducibility.
Trend signal
This supports harness architecture outlives model choice. The release combines a model launch path with changes to routing and API output behavior. A model is only one part of an agent workflow; the runtime determines how a coding agent reaches that model and how downstream software receives its output. One release is a limited example, rather than proof that runtime design outweighs model quality in every deployment.
Why now
Ollama published v0.40.16 on November 9. That timing makes Ripple’s local-runtime path actionable for developers already using Ollama, while the Claude Code routing and response changes arrive in the same version. Ollama does not explain why the changes were grouped together or identify a wider release schedule.
Connections to other events
New Runtime’s earlier coverage of Ripple-65B Preview described Ricursive’s reported TerminalBench 2.1 result. An earlier New Runtime note on November 10 recorded its arrival in Ollama with a listed 2M-token context window. This release makes the operational layer more concrete, but does not independently validate either a long-context claim or a benchmark result.
Why it matters
For teams testing coding agents against local models, a one-command launch can reduce setup work and make it easier to include Ripple in a comparative evaluation. That has value even before a team considers production deployment: the same harness can run a controlled task set across models, prompts, context sizes, and machines. But a runnable tag is not evidence that a particular system can sustain the intended context length or workload.
The Claude Code routing and /v1/responses changes matter even when Ripple is not selected. Explicit routing can reduce configuration surprises when a team swaps models. A change to silent truncation behavior can expose assumptions in clients that parse, store, or evaluate generated output. Teams should test the whole harness—model selection, runtime routing, output handling, and task verification—rather than infer agent reliability from a model name or a successful initial launch.
What happens next
- Ollama users will publish practical reports on Ripple Preview’s local memory use and usable context length. (3 months, 65%). Watch for: reproducible commands, hardware specifications, and stated quantization.
- Integrators will update response-handling tests after the
/v1/responsestruncation change. (3 months, 60%). Watch for: client release notes or regression tests that inspect truncation conditions.
Limits and uncertainty
Ollama’s release notes do not state Ripple Preview’s quantization, memory requirements, supported context length, price, or access conditions. They do not report independent performance measurements or reproduce a benchmark score. The release establishes that ripple-preview can be invoked through Ollama, but it does not establish that long-context operation is reliable or practical on specific hardware.
The exact effect of the /v1/responses change depends on the application making the request and on how it detects incomplete output. Likewise, “always routes” describes the intended launch behavior but does not measure the absence of misrouting across configurations. The memory improvement cited for Qwen3.8 Flash Next is specific to Apple silicon and should not be generalized to Ripple or other platforms.
Skill to build now
Add a small integration test around your local-agent launcher this week. Run one fixed coding task with the selected model, log the model identifier received by the runtime, and save whether the response completed or encountered truncation. Repeat it with a deliberately constrained output limit. This separates three failures that otherwise look alike: wrong model routing, insufficient model capacity, and a client that mishandles incomplete output.
For Ripple specifically, record the tag digest, quantization if discoverable from the runtime, available memory, requested context length, elapsed time, and task outcome. Do not treat a successful short task as evidence that the same configuration supports a longer agent loop. A simple test record gives a team a basis for comparing local runs rather than relying on a model label.
Reader takeaway
Ollama v0.40.16 makes Ripple Preview easy to try and changes routing and response handling for agent workflows. Treat the launch command as an invitation to test, not as validation of model claims. Before relying on it, verify your hardware fit, actual context behavior, selected-model routing, and the way your client handles truncated responses.
Open question
What context length and quantization does the ripple-preview tag actually use in practice, and how does performance vary across local hardware?