Ollama v0.40.5 and rc1: Nemotron 3.5, Cloud Tags, and Import Fixes

The problem: upgrades that break in small places #

Most inference server upgrades fail in narrow ways. A conversation that worked on the first turn returns an error on the second. A cloud request fails with a message that does not say why. A quantized checkpoint loads, but its scales are wrong and the outputs drift. Release notes are where these changes get named, and this round deserves a careful read because two tags, v0.40.5 and v0.40.5-rc1, touch the same model family from different directions.

The v0.40.5 notes describe NVIDIA Nemotron 3.5 Super as a vision-language model for coding, reasoning, tool use, and document understanding. According to the notes, it pairs a 120B-parameter hybrid Mamba-2/Transformer mixture-of-experts backbone, with 12B parameters active per token, with a C-RADIO vision encoder. The model supports tool calling, an on/off thinking mode, and context up to 1M tokens. The notes also describe Nemotron 3.5 Bolt, a compact sibling distilled from Super to 74B parameters with 9B active. It is tuned to fit a 24 GB NVIDIA GPU and uses speculative decoding through its included drafter.

Model descriptions tell you what a model can do. The "What's Changed" list tells you what the server now does differently, and that determines whether existing code keeps working. The table below maps each item to the people it affects. Every row names the version whose own release notes list that change.

Key changes at a glance #

What v0.40.5 changes for running models #

The first change is cloud access for decision models. The v0.40.5 notes say you can use clef:cloud and clef-flash:cloud to run decision models through ollama.com cloud without pulling them locally. The notes use the term "decision models" but do not define it, so treat these as the names Ollama publishes for this capability and check what each one does in your own tests. The notes also do not state whether these tags require a signed-in account, although the same release describes cloud sign-in errors. Verify that requirement on a test host before you script it into a deployment. Pricing, latency, and quota behavior are not described either, so measure them before you depend on the cloud path for production traffic.

ollama run nemotron-3.5-super
ollama run clef:cloud

The second change addresses multi-turn tool use. The notes state that continuing an OpenAI-compatible Responses conversation that includes custom tool calls no longer fails with an error. If your agent loop worked on the first request and broke on the second, retest that exact flow. The notes do not give the original error text or its precise trigger, so the most reliable check is to replay a saved conversation that contains a custom tool call and confirm that each turn completes.

The third change concerns cloud error reporting. The v0.40.5 notes say that sign-in problems, payment issues in the desktop app, and upstream access errors from the ChatGPT gateway now come with clearer explanations. This is a usability improvement, but it affects your operational playbook. A payment message and a sign-in message call for different responses. If your monitoring matches older strings, those rules may stop firing, so review them as part of the upgrade. The notes do not list the new strings, so capture real responses from a test environment rather than guessing at them.

The fourth change is a dependency update. The notes say Ollama updated llama.cpp, adding Nemotron 3.5 support, and updated MLX. They do not list the upstream versions or describe behavior changes inside those dependencies. The safe conclusion is that the Nemotron 3.5 support in v0.40.5 is described as coming through the llama.cpp update, and that the MLX update is listed separately.

What v0.40.5-rc1 changes for MLX and quantized Nemotron #

The v0.40.5-rc1 notes are commit-level and more technical. They matter most if you run Nemotron through the MLX backend or import NVFP4 weights. These items are listed under the rc1 tag. The rc1 page does not say that they appear in v0.40.5, so do not assume they do until you confirm it in the v0.40.5 build you actually run.

The main MLX block covers Nemotron. The rc1 commit message says the change accepts published Nemotron layer names while retaining legacy aliases. It also says it fixes layer-count inference and detached MTP quantization. Other items in the message are stabilizing Mamba softplus, preserving FP32 vision normalization, and compiling Mamba gate and norm scaling. The same release notes include a separate commit that adds Nemotron 3.5 Super to MLX. Because the alias handling is the part most likely to matter for existing files, test both naming schemes if your conversion pipeline renamed layers.

The rc1 notes also cover global scales. They say the build supports per-expert F32 global scales and preserves activation-scale companions during ModelOpt and compressed-tensors NVFP4 imports. Reciprocal globals are normalized, invalid scales are rejected, and activation scales are kept separate from weight-only inference. This is a correctness change. Rejecting an invalid scale is safer than silently producing wrong output, but a checkpoint that imported before may now fail. Treat an import test as a required gate rather than an optional check.

The rc1 notes include one build change for Windows source builders. The commit message says the change keeps nested shader-generator compiler probes below Windows path limits in checkouts with longer repository names. In other words, it shortens the build path used by those nested probes so that longer checkout directories are less likely to break the build. The notes give no path-length threshold, so you cannot assume a specific length is covered. Test your real checkout path in CI. This change affects people who compile Ollama on Windows, not people who install a binary.

Release order and what the notes leave open #

The two pages carry dates that do not follow the order you might expect. The v0.40.5 page lists a publication date of 14 October, while the rc1 page is dated 15 October and describes a tag that was created after the release. Do not conclude from these dates that rc1 was built on top of v0.40.5, that it was a backport, or that it skipped or included any specific fix. The sources do not say so. The useful question is simpler: does the build you deploy contain each change you depend on? Check that with your own version output and tests.

The notes also leave several practical questions unanswered. They give no throughput or latency figures for Nemotron 3.5 Super or Bolt. The only memory figure is the 24 GB GPU target for Bolt. They do not describe pricing or quotas for the cloud decision-model tags. They do not give the exact Responses error text from before the fix, and they do not describe a migration path for checkpoints that already use legacy layer names. Treat each of these as an open item for your own testing.

Use the v0.40.5 notes to plan behavior changes in server and client code. Use the v0.40.5-rc1 notes to understand the MLX and quantization details that decide whether a Nemotron import succeeds, and verify both on your own checkpoints.

Upgrade checklist #

1. Inventory which workloads use the Responses API with custom tools, which run Nemotron through MLX, and which import NVFP4 or other quantized Nemotron weights. These three groups carry the most risk.
2. Upgrade a non-production instance to v0.40.5 first. Confirm that the server starts and that existing models still respond.
3. Replay a saved multi-turn Responses conversation that includes a custom tool call. Confirm that the second and later turns complete without error.
4. If you use cloud access, test one decision model through the clef:cloud or clef-flash:cloud tag. Check whether your setup needs a signed-in account, since the notes do not say. Record the sign-in, payment, and upstream responses you actually see, then update alert rules and runbooks that match older error text.
5. Run ollama run nemotron-3.5-super on a test host with your typical prompts. Compare tool calling and the thinking mode setting against your previous baseline.
6. If you build from source on Windows, test your real checkout path in CI after the v0.40.5-rc1 Vulkan build change. Do not assume a specific path length is covered, because the notes give no threshold.
7. If you import Nemotron checkpoints through MLX or NVFP4, run the import tests on a build that you have confirmed contains the rc1 changes. Test both published and legacy layer names, confirm that invalid scales are rejected, and compare outputs against a known-good run.
8. Only after these checks pass, roll the upgrade out to production, and keep the previous binary available for a fast rollback.

Treat these notes as a map rather than a guarantee. The v0.40.5 page describes changes that affect server and client behavior, and the v0.40.5-rc1 page describes changes inside the Nemotron, MLX, and NVFP4 paths. Start your testing with multi-turn tool use, cloud error handling, and quantized imports, because those are the areas where the notes describe changes that can break existing workloads.