How a model gets into a curated catalog

The complaint arrives early and it is always the same. A well-regarded open-weights model has been released. It runs everywhere else. It is not in the Foundry Local catalog. The obvious inference is that the catalog is behind, and the obvious next question is when it will catch up.

Both the inference and the question skip a step. The catalog is not a mirror of what exists — it is the output of a process, and the process is documented, public, and has a defined place where anyone can push on it. Knowing the shape of that process converts a wait into a decision.

The Foundry Catalog is a cloud-hosted model registry, and what it stores is not a model. It stores hardware-optimized variants — pre-compiled ONNX artifacts tuned for particular hardware configurations across CPU, GPU, and NPU.

That distinction explains almost everything downstream. Adding a model to the catalog is not uploading a file. It is producing, testing, and publishing a set of compiled artifacts, one per supported target, each of which has been through quantization and compression, and each of which has to behave on hardware nobody in the room owns.

The runtime then handles acquisition on the application's behalf: download on first use, cached locally for instant subsequent launches, version-aware updates, and automatic selection of the best-performing variant for the machine it finds itself on.

Seen that way, the catalog is closer to a package feed for compiled binaries than to a model hub. Comparing its breadth to a repository that hosts raw weights is comparing a distribution channel to a source archive.

Microsoft answers the "why not every model" question directly in the product FAQ instead of treating it as a criticism to be deflected. The reasoning, compressed: the product is designed for shipping production applications, not for general-purpose model experimentation. Catalog models are tested across a range of consumer hardware and are small enough to distribute to end users. The stated goal is that every model in the catalog delivers reliable performance when embedded in an application, rather than offering a broad selection with unpredictable on-device behaviour.

Whether that trade is the right one depends entirely on what the software is for — which is the theme this whole series keeps returning to.

For a developer exploring what is possible this week, curation is friction and nothing else. For a team shipping an application to an install base it cannot inspect, "tested across a range of consumer hardware" is the entire value proposition. The variance that on-device inference has to absorb is genuinely brutal: a model that is comfortable on a current workstation may be unusable on a four-year-old laptop with integrated graphics, and both machines are in the install base.

Breadth is a feature when the machine is a developer's. Predictability is a feature when the machine belongs to someone who will never file a bug report.

Three identifiers do different jobs, and mixing them up produces confusing results on a colleague's machine.

An alias is the short, hardware-agnostic name. Requesting a model by alias delegates the choice: the runtime selects the best variant for the hardware it detects — a GPU variant where a supported GPU exists, an NPU variant where a supported NPU does. This is the right default for an application shipped across a fleet, because the fleet is not uniform and the application should not care.

A model ID pins a specific variant. Naming a generic CPU identifier runs that exact artifact regardless of what accelerator is sitting idle nearby. This is the right choice for a reproducible benchmark and the wrong choice for a shipped default.

The CLI makes the distinction inspectable. foundry model list shows variants in priority order — the first entry is what an alias resolves to — and options exist to filter by device kind, by task, by cached or loaded state, and to include variants explicitly.

Versions are the third axis. Catalog models are versioned, so an application can pin to a specific version or take updates automatically. That choice deserves a deliberate decision, not a default: automatic updates mean a model can change underneath an application that was tested against a different one, and for a product with evaluation criteria, that is a silent regression waiting to happen.

Here is the part that gets consistently misread. The catalog is Microsoft-curated, and it is not a repository that accepts model submissions. Attempting to add a catalog entry by pull request is pushing on the wrong surface, and the result is a closed pull request and a reasonable conclusion that the door is shut.

The door is not shut. It is just somewhere else.

The public surface that feeds this pipeline is the olive-recipes repository — the per-model, per-hardware optimization configurations covered in the previous episode. A recipe is the reproducible statement of how a given architecture compiles to a given execution provider at a given precision. That is the artifact the pipeline consumes, and it is the artifact a contributor can actually produce.

The second surface is the discussion tracker on the runtime's own repository, where model requests are raised. The observable difference between requests that move and requests that sit is not enthusiasm. It is specificity: the hardware being run, the parameter sizes needed, why the gap matters for a real workload, and a link to the upstream weights. A well-formed request is a small piece of engineering work presented to maintainers who have to decide where finite compilation effort goes. A vote of agreement is not that.

When a needed model is not in the catalog, there are exactly three honest options, and they should be chosen deliberately rather than defaulted into.

Wait. Legitimate when the model is popular, the architecture is already represented, and the schedule has room. Curation has a cadence, and popular architectures do arrive.

Compile it. The documented path from Safetensors or PyTorch weights to a running local model exists, works, and produces an artifact that loads through the same lifecycle as a catalog entry. The cost is owning the compilation, the precision decision, and the testing across whatever hardware the application will meet.

Contribute the recipe. The most work and the only option that removes the problem for everyone who arrives next. If the compile succeeded, the recipe is already written — publishing it is the small remaining step. If it failed, the complete log against a specific architecture, precision, and provider is itself the useful artifact, and abandoning a broken attempt in silence throws away the only part of the work that had lasting value.

The reflex in the open-weights world is to treat a curated catalog as a closed door and go find an open one. Sometimes that is correct. But a curated catalog with a public optimization repository behind it is not a closed system — it is an open pipeline with an unfamiliar entry point. The lag is real. It is also, unusually, something an individual engineer can act on.