A plain-language explainer on model “openness” and AI model customization

When people talk about "AI models," they often treat them as a single category, but behind the scenes, there are meaningful differences in how these models work, who controls them, and what you can do with them. When an AI company releases a model, they make choices about access and transparency. Those choices determine whether an organization can customize an AI system for their own needs or whether they are locked into rigid use restrictions. This primer explains the distinctions between model selection types and why they matter beyond the technical details.

News sources, policy stakeholders, and the public often use “open-source,” “open-weight,” and “closed” as imprecise adjectives to define AI model types. The distinctions between them become straightforward once you understand that every AI model has three layers that can be shared or withheld:

access to use the model,
the model itself, and
the recipe (training code and data) used to build it.

A model's weights are a type of numerical setting that encode everything the model “learned” during training. In practice, “weights” and “model” are used interchangeably when discussing model releases. An open-weight release usually includes not just the numeric weights themselves but also all the pieces of code needed to actually make the model run. So “releasing the weights” means releasing a complete, runnable package. (Even more confusingly, oftentimes “weights” and “parameters” are used interchangeably, but strictly speaking, weights are a type of parameter. The other type of parameter is “bias.” Weights vastly outnumber biases, which is why “weights” became the shorthand, but an open-weight release includes the biases too.)

Closed Models

With closed models (OpenAI's GPT, Anthropic's Claude, Google's Gemini), users interact with the model only through the company's app or application programmer interface (API), much as one hires a service instead of buying the equipment. (An API allows software developers to access a model using code only, instead of through a chatbot interface.) The provider keeps the weights and the recipe, controls safety guardrails centrally, and can update or retire the model at any time. Every query passes through the provider's infrastructure.

Open-weight Models

With open-weight models (Meta’s Glimmer, Kimi K3, Inkling, DeepSeek), the company publishes the weights for anyone to download, usually on a repository like Hugging Face, under a license that typically permits commercial use. Organizations or even single users can run the model on their own hardware, keep sensitive data entirely in-house, and fine-tune the model for their needs. (More on fine-tuning later.) And depending on the use case, an internet connection isn’t even required, which reduces the exposure to external threats. The recipe stays private: because the training data and code are withheld, the public can use and modify the model but cannot fully audit or reproduce how it was made.

Open-source Models

Truly open-source models (such as the research models OLMo and Pythia) release everything: weights, training code, and documentation of the training data. This maximizes transparency and reproducibility, since researchers and auditors can verify exactly what went into the model — checking whether copyrighted or sensitive material was used, tracing the source of biases or errors in the model's outputs, or confirming a developer's claims about how the system was built. These projects are mostly academic, however, and lag frontier performance.

Note: headlines often say “open-source” when they technically mean “open-weight.”

Of course, these categories are a simplification. Many models fall somewhere in between, like Meta's Llama models, which release their weights with license restrictions—but the open-source/open-weight/closed distinction remains a useful shorthand for understanding who can access and run a model.

*The three tiers of model openness, by what is shared and what is withheld.*

Why Openness Matters: Customization

The reason organizations care about all this is customization. Inkling's entire premise is that a capable model adapted to an institution's documents, workflows, and rules can be more valuable in practice than the single most powerful general-purpose system. There are four main ways to change how an AI model behaves, ranging from surface-level to fundamental:

System prompt

Written instructions that tell the model what role to play and what rules to follow for a conversation or set of conversations, like asking a person to act as a teacher, coach, or lawyer. This is the easiest change to make and works with any model, closed or open.

Retrieval-Augmented Generation (RAG)

Connecting the model to a trusted set of documents it consults while answering, like letting someone use an encyclopedia or their notes during a conversation to increase their knowledge. RAG grounds answers in your materials without changing the model itself, and it works with both closed and open models. For an explainer on how RAG works and why it matters for legislative use cases, see our primer on RAG.

Fine-tuning

Additional training that adjusts the model's weights using your own examples, like someone practicing a skill until it becomes natural. This produces deeper, more durable changes in behavior, style, and domain knowledge. Closed providers offer limited fine-tuning as a managed service. Full control over fine-tuning, on your own infrastructure and with data that never leaves your systems, requires access to the weights. This is the capability open-weight releases unlock, and it is the market Thinking Machines is targeting with Inkling and its companion fine-tuning platform.

Training from scratch

Building the whole model, like a person growing up with particular experiences, education, and memories. This is the deepest form of change and requires the data, computing power, and expertise of a major lab, so it remains a realistic option for only a handful of organizations.

Four ways to change an AI model, from easiest (system prompt) to deepest (training).

Understanding these distinctions matters because the choice of model is a choice about tradeoffs. Closed models offer convenience, centrally managed safety, and frontier performance without the burden of physical or digital infrastructure. Open-weight models trade some of that convenience for control — the ability to run a model in house, keep sensitive data private, and fine-tune deeply for specialized needs. Truly open-source models add full transparency, at some cost to raw capability. Across all of them, the same four levers of customization, from system prompting to training from scratch, determine how closely a model can be shaped to serve an organization's work.

Open, Closed, and Customizable: A Primer on Model Selection