Ollama released version 0.40.16 of its model runtime on November 9. The update brings Ripple-65B Preview, an open-weight coding model developed by Ricursive Intelligence, into its library. In the same release, Ollama reports that Qwen3.8 Flash Next uses about 27 GiB less memory on Apple Silicon. The library addition and the memory reduction are two changes that apply to different models.
Ripple joins the Ollama library
Ricursive Intelligence had already published the Ripple weights. The November 9 change integrates the model into Ollama, where it appears under the name ripple-preview. The library lists files of about 39 to 46 GB for the model variants. The official model card identifies Apache 2.0 as the license for the weights. The Preview variant is tuned to follow instructions and belongs to a family that also includes a separately published base model.
Ripple has 65 billion parameters and a dense architecture. Its parameters participate in processing each token, the unit into which text is split. The model was designed and trained for multi-step programming work. In an environment connected to developer tools, a task might involve reading project files, proposing a change, and running a test. The application hosting the agent supplies those tools and controls which actions the agent can carry out.
Ricursive Intelligence says it pretrained the model on 12 trillion tokens, primarily English text and code. The authors describe a context capacity of up to roughly one million tokens for the model they published. In Ollama, the context actually used in a session depends on the model variant, the runtime settings, and the available memory. Tool responses are also part of the context, so a long test log can occupy a substantial share of the session.
Ricursive reports a score of 80.52 on Terminal-Bench 2.1, an evaluation involving tasks performed in a terminal. That figure comes from the model authors' own evaluation. The Ripple model card also shows results obtained with a common testing harness for several models, under which their ordering changes. Both measurements apply to the respective tasks and environments. Response time on a particular Mac or workstation with a dedicated GPU depends on the local implementation, the weight format, and the size of the task.
What the 27 GiB memory reduction means on a Mac
The release notes attribute the saving of about 27 GiB to Qwen3.8 Flash Next on Apple Silicon systems. It is the reported difference from the previous version of the application. Ollama lists an MLX variant of the model separately in its library, with a file of about 105 GB. Memory used during a task includes the weights loaded into the runtime, intermediate data, and the state needed to preserve context. The on-disk file size is a separate measurement.
Qwen3.8 Flash Next is described as an experimental preview of the architecture behind Qwen4. It is multimodal and uses a mixture-of-experts architecture. Ollama lists 125 billion parameters in total and about six billion active for each token. That selective activation describes how much computation is performed at a generation step. The installed variant still holds the weights of the experts it can select, and how they load depends on the runtime and configuration.
For the MLX variant, the catalogue lists a 256K-token context window and support for text or image input. The window is the published limit for that variant. The size of an actual request depends on what the client sends, including image inputs processed by the model and the conversation history.
On Apple Silicon, the processor and graphics unit access the same unified memory. The model uses a portion of the capacity shared by the operating system, code editor, and other applications. The difference reported by Ollama is especially relevant when the earlier version was using nearly all the memory available. Capacity requirements still depend on the model loaded and the context in use. A short session and a session with many files and test results place different demands on the system.
Changes for clients using Ollama as a local runtime
In this release, the Ollama integration that starts Claude Code routes it to the model selected at launch, according to the release notes. The model selection determines where inference requests are sent. A coding client can use a local model for generation while separately offering its own features, extensions, or commands that communicate with other systems. Model routing and the network connections made by the rest of the application are separate aspects of the same setup.
The update also changes the handling of overlong inputs on the compatible /v1/responses route. Ollama says the runtime respects the truncation option and stops silently dropping part of the input by default. In an integration that sends large logs or the history of a task, the truncation policy determines whether the runtime can shorten the input. The /v1/models route also returns an empty list when the installation has no models, a detail that matters for applications that populate a model picker automatically.
The change list includes an update to the llama.cpp engine and support for CUDA 13.5 on Windows on ARM. On the Mac, the memory figure specifically concerns Qwen3.8 Flash Next. For Ripple, the separate details in this release are its arrival in the catalog, the downloadable formats, and its coding focus. A comparison of the two in a local project can hold the task and context length constant and record the exact configuration used for each model.
