Open-weight models on the appliance

A model is a set of weights and the code that runs them. If the weights live on a server you do not control, every question you ask travels to that server. If the weights live on an appliance in your rack, the question stays in the building. That is the whole reason Substrate serves open-weight models and nothing else.

This article explains what open weights make possible on the Czar appliance, which kinds of model Substrate serves, and how a site decides which to load.

What open weights change

An open-weight model is one whose parameters the site can obtain, hold, and run. Nothing about it requires a remote endpoint. Loaded on the appliance, it answers from the rack over the facility network, and the request, the response, and any record of either stay where the site keeps them.

Open weights also make three further things possible that a closed endpoint cannot offer. The site can inspect the model it is running, which matters when an auditor asks what influenced a machine's decision. The site can adapt the model on its own data with the Adaptation service, producing an adapter that is the site's property. And the site can keep running a model indefinitely, regardless of what any outside vendor decides to do with their service.

The kinds of model Substrate serves

Substrate serves several families of open-weight model, all behind the same API.

Language models answer questions, draft documents, summarize records, and drive the reasoning in agents. On a facility they appear in planning tools, in maintenance assistants grounded by the Retrieval service, and in the agent layer on the appliance.

Vision and perception models look at camera feeds and images: identifying items, reading labels and placards, detecting damage, and giving mobile robots a shared view of the floor. These are the models most often called with short budgets.

Speech models transcribe and understand spoken audio, which on a floor usually means radio channels, voice notes, and hands-free interfaces for workers who cannot stop to type.

Embedding models turn text and images into vectors that the Retrieval and Memory services use. They do their work quietly in the background, indexing the site's documents and the agents' memories, and they are the most batch-friendly workload on the pool.

Vision-language-action models connect what a robot sees and is told to what it should do next. They are the newest family and the one with the most to gain from a shared pool, because they are too heavy for many machines to carry well on board.

Choosing a model for a task

The API is stable and does not describe the hardware underneath it. A caller asks for a task and a budget; the site decides which open model fulfils it. That decoupling is deliberate. It means the site can start with one model, measure it in the Evaluation traces, and replace it with a better open model later without a single robot or application changing its code.

The decision is usually a balance of three things: the quality the task needs, the budget the callers declare, and how the model batches on the Grid. A larger model may answer better but miss short budgets. A smaller one may serve the arms on time and leave the larger one for the planners. The placement article discusses how this plays out across nodes.

Models and the sealed image

It is worth separating two things that can be confused. The platform's software image is sealed, signed, and read-only, and it changes only through signed update bundles. The models the site loads are not part of that image. They are the site's choices, loaded and changed by the site, and recorded in the traces by name and version so that any answer can be traced to the model that gave it.

An adapter trained on site through the Adaptation service sits alongside the base model in the same way. It is the site's, it stays on the appliance, and it is named in every trace that used it.

Why this matters for posture

A site that runs air-gapped has no choice but open weights; there is nothing else that can run with no path out. A connected site that has declared a route to its warehouse system through Local Bridge has a choice, and the platform makes the same one on its behalf: the model runs here. The connection carries the site's business data to the site's own systems. It does not carry prompts to anyone's cloud.

That is what the phrase on the security page means in practice. What leaves the building: nothing, including the question you asked the model.

Fine-tuning an open model on the site's data is described in adapting a model on the site's own data. The robot-facing family is covered in vision-language-action models served from the rack. Distributing models across nodes is in which model runs where on a Grid. The posture choices are summarized on the security page.