The Trade

Lesson 3 of 3 in Open vs Closed Weights.

Strip the ideology away and open-vs-closed is an engineering trade, decided per workload.

What open weights buy you. Control: you pin the exact version in your artifact store; no one retires it, no one silently updates it under your Golden set. Privacy and locality: prompts and outputs never leave infrastructure you control — the cleanest possible answer to data-residency and confidentiality requirements. Cost shape: you pay for capacity (hardware and utilization) rather than per token, which can win at sustained high volume — a claim to verify against your own traffic, never assume. Portability: the same weights run on any cloud, on-prem, or at the edge; your serving stack, fine-tunes, and quantized variants move with you.

What open weights cost you. Ops burden: GPUs, an inference server, autoscaling, patching, on-call — the full weight of the managed-vs-self-hosted trade, now on your side of the line. Capability: historically, the strongest capability at any given moment has tended to appear first behind closed APIs. Treat that as a pattern to re-verify against current Benchmark evidence and your own evals — not a law, and the gap for your task may be zero.

The trade at a glance — qualitative orientation only (historically-typical patterns, not vendor facts). Verify capability and cost claims against your own evals and traffic; platform data-handling behavior against the platform’s own documentation.
Dimension	Open weights, self-hosted	Closed weights, API	Managed open (cloud catalog)
Control & versioning	You pin the version; nothing retires without your consent	Provider controls the lifecycle; deprecation happens on their timeline	You pick the model; the platform serves it — catalog listings can still change
Data flows	Prompts stay inside infrastructure you control	Prompts transit the provider, governed by its terms	Depends on deployment type — check the platform’s data-handling docs, not the marketing page
Ops burden	Yours: GPUs, serving stack, scaling, patching, on-call	The provider’s	Mostly the platform’s
Capability access	The open frontier — historically has tended to trail the closed frontier; re-verify per task	Frontier models, available the day they launch	Both open and closed families through one catalog
Cost shape	Capacity-shaped: hardware and utilization, regardless of traffic	Usage-shaped: per token, scales to zero	Either: per-token serverless or committed capacity
Portability	Maximum — the weights go where you go	Bounded by the provider’s API; prompts and evals are your portable assets	In between: open models move; closed catalog models do not

What closed APIs buy you. Frontier capability on launch day, zero serving ops, elastic scale, and the provider’s integrated tooling. For a small team, “no GPUs, no on-call” is not a detail — it is often the whole decision.

What closed APIs cost you. Lock-in: your prompts, few-shot examples, and quality tuning quietly specialize to one model’s behavior; the mitigation is a portable Eval harness and Golden set that can score any candidate model, not just the incumbent. Data flows: your tokens transit the provider under its terms — a fact your security review must own, not discover. Deprecation exposure: the provider retires models on its schedule, and a retirement notice is a forced migration with a deadline. The discipline is twofold: watch release and deprecation announcements as a routine (this site’s Model Release Log models the habit), and treat every model change — voluntary or forced — as a regression event that reruns your evals before traffic moves. The production-evals module turns that into machinery.

Neither column wins in general. That is the point: the trade is real, so the decision unit has to be the workload, not the company.

Open, closed, or mixed — walk it per workload

Interactive decision tree — outcomes:

Self-hosted open weights
Control and locality, maximum portability, capacity-shaped cost. Read the license first (custom terms attach even to downloadable weights), and budget the ops honestly — the serving stack is now a product you run.
Open weights through a managed catalog
The middle path: an open-weights model, served by a cloud platform, optionally behind a private endpoint in your own boundary. Verify the deployment type’s data-handling documentation against your requirement — and the model’s license still applies to you.
Closed-weights API
Frontier capability with zero serving ops. Guard the exits: keep a portable eval harness, watch deprecation notices, and treat any model change as a regression event.
Closed API for now — re-evaluate on a schedule
With no residency constraint, no proven open candidate, and moderate volume, the managed API is the low-risk default. Put a recurring date on re-running your evals against open candidates — this map moves.

In production

The open-vs-closed choice is architectural, not platform-forced: every hyperscaler’s model catalog serves both open and closed families side by side, so choosing a cloud does not choose your answer.

AWS

Amazon Bedrock’s Model Catalog lists 100+ foundation models from providers including Amazon, Anthropic, DeepSeek, Moonshot AI, MiniMax, OpenAI, and xAI — closed API families and open families through one console and one invocation API. Amazon Bedrock Marketplace adds 100+ more specialized models on managed endpoints, and Custom Model Import serves open-source weights you bring yourself through the same standard APIs — the full spectrum, one platform.

Azure

Azure AI Foundry’s model catalog is organized into “Foundry Models sold by Azure” (Microsoft-hosted, including Azure OpenAI models) and “Foundry Models from partners and community” — Anthropic’s Claude family alongside open models from the Hugging Face hub, with named providers spanning Microsoft, Azure OpenAI, Anthropic, DeepSeek, Meta, Mistral, Cohere, NVIDIA, and Hugging Face. The open/closed distinction becomes operational at deployment time: serverless where Microsoft hosts, managed compute where the weights run on VMs you control.

Google Cloud

Vertex AI’s Model Garden groups Google models (Gemini and companions), partner models (Anthropic Claude, Grok, Mistral AI), and open models (Gemma, Llama, DeepSeek, Qwen, gpt-oss, and more) in one library. Open models can be consumed as managed serverless APIs or self-deployed into your own project and VPC network — meaning even the self-host-vs-managed fork of the decision tree is available inside a single catalog.

Tool: Cloud Model Selection Matrix — See the sourced, current version of this picture — which catalogs carry which families, and under which consumption modes — in the Cloud Model Matrix tool.

Key terms: Open weights, Closed weights, Gated distribution, Community license, Deprecation

Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.