Ollama v0.35.1-rc0 Update: Explicit Model Capability Declaration Mechanism Explained

Ollama has released v0.35.1-rc0, a preview build centered around PR #18708 — introducing an explicit model capabilities declaration mechanism into the model creation pipeline. While this may look like a low-level engineering detail, it has real implications for scheduling accuracy and the standardization of model metadata management in the local LLM ecosystem.

Core Changes in This Update

The main change in this release can be summarized in one sentence: let models declare what they can do, rather than having the framework guess.

Specifically, the update adds a CAPABILITY declaration field to the Modelfile, along with an additive capabilities field in create requests. This means developers can explicitly annotate which features a model supports when building it, instead of relying on the framework to reverse-engineer capabilities from architecture metadata.

More importantly, these capability declarations are preserved end-to-end across multiple stages: model creation from both GGUF and safetensors formats, model inheritance, and Modelfile export — none of the declared information is lost along the way. This kind of end-to-end consistency is critical for model distribution and reuse scenarios.

Why Replace Metadata Matching with Explicit Declarations

In the previous implementation, Ollama determined whether a model possessed a certain capability by matching against model architecture or renderer metadata. The release notes specifically call out a typical example: when scheduling System One requests, the decision was made by matching against the Qwen architecture and its renderer metadata.

The problem with this approach is that it's brittle and insufficiently general. Implicit signals like architecture names and renderer identifiers are essentially heuristic guesses — the moment a new architecture or variant appears, the matching logic can break down or produce false positives.

The new version requires models to explicitly possess the decision capability before being scheduled to handle System One requests. In other words, the scheduling decision shifts from "fuzzy architecture recognition" to "a clear capability contract" — a genuine improvement in the predictability of runtime behavior.

GGUF (GPT-Generated Unified Format) is a model file format defined by the llama.cpp project that bundles model weights and architecture metadata into a single file. safetensors is a secure tensor storage format introduced by Hugging Face, prioritizing safety and loading speed. The metadata field definitions across these two formats are not unified — which is the fundamental reason why capability inference based on "architecture recognition" was prone to errors. The same capability might be represented by different field names across formats, or have no corresponding field at all. Explicit CAPABILITY declarations lift capability descriptions out of the format layer, making them a semantic contract independent of the underlying storage format, thereby eliminating ambiguity in cross-format matching.

Incremental Evolution and the MLX Foreshadowing

Also worth noting is the deliberate pacing of this change. The release notes explicitly state that the GGUF-only scoring restriction from the main branch has been preserved for now, pending the landing of a separate MLX runtime effort.

Looking at the commit history, this capability foundation was actually extracted from commit 36d46a0c3 on the system_one_mlx branch, while the MLX scoring logic and manifest-list-related changes were intentionally split out to be developed separately.

This split strategy reflects mature engineering governance: stabilize the general capability declaration mechanism first, lay the groundwork for future MLX runtime support, and avoid introducing too many tightly coupled changes at once. For users focused on local inference on Apple Silicon, this is also a clear signal — native MLX runtime support is on the way.

MLX is an open-source machine learning framework from Apple, designed specifically for Apple Silicon (M-series chips). It fully leverages the Unified Memory Architecture, allowing the CPU and GPU to share the same memory pool with zero-copy operations. Compared to general-purpose inference frameworks, MLX delivers lower memory usage and higher throughput for local inference on Mac. Ollama currently relies primarily on llama.cpp's GGUF format for quantized inference. Introducing an MLX runtime means Ollama will support an additional native Apple platform inference path. Since the scoring and scheduling logic differs between the two runtimes, the integration must wait until the capability declaration mechanism is stable — to avoid behavioral inconsistencies across runtimes.

What This Means for Developers

For developers using Ollama day-to-day, this rc release has a few direct implications.

First, Modelfiles are now more expressive. When building a custom model, you can explicitly declare its capabilities, allowing downstream callers and frameworks to accurately understand what the model supports.

Second, the preservation of capability declarations across the inheritance chain means that when building on top of an existing model, you don't have to worry about critical metadata being lost through layers of wrapping — good news for teams maintaining internal model libraries.

Third, as an rc0 (release candidate) build, it's aimed at early adopters willing to test and provide feedback. Production environments should wait for the official stable release before upgrading.

Summary

Ollama v0.35.1-rc0 is not a flashy end-user feature update — it's a foundational architectural refinement. It replaces brittle metadata matching with explicit capability declarations, unifies capability preservation across formats and inheritance chains, and lays the groundwork for future MLX runtime support.

For the local LLM ecosystem, this kind of infrastructure-level polish may not be glamorous, but it often determines a framework's long-term maintainability and extensibility. Users following Ollama's development should keep an eye on the upcoming stable release and the progress of MLX runtime integration.