Closed-Source Model

The Technical Definition

A closed-source model is a model accessed only through the vendor’s API. The weights, the training data, the training process, and the architecture are all proprietary. The customer sends inputs in, gets outputs back, and pays per token of usage. GPT-4 (OpenAI), Claude (Anthropic), and Gemini (Google) are the dominant closed-source frontier models in enterprise. The customer never sees the model. The vendor controls every dimension of it — the version, the pricing, the data-handling policy, the rate limits, the deprecation timeline, and the changes that get pushed without notice.

What This Actually Means for Your Business

The case for closed-source is real. The frontier capability comes from the closed labs. The smartest, most reliable, most instruction-following models on the market today are closed. Calling an API is faster to deploy than self-hosting — minutes instead of months. There is no infrastructure to run, no GPU procurement, no ops team to staff for inference. For most operators most of the time, closed-source is the correct default. The argument is not against closed-source. The argument is against the lock-in dynamics that come with it, which most teams do not price in until the second contract.

Here is what the vendor controls and you do not. Pricing — the vendor can change the per-token price, the tier structure, or the rate limits at any time, and your only leverage is to leave. Deprecation — the model you built against is retired on the vendor’s timeline, not yours, and the replacement may behave differently in ways your prompts cannot absorb without rework. Data flow — your inputs go to the vendor’s servers, run through their infrastructure, and may pass through subprocessors you did not contract with directly. Policy — the vendor can change the acceptable-use policy, the data-retention rule, or the commercial-use terms, and your contract follows their template, not yours.

The lock-in compounds quietly. Six months in, you have prompts tuned to this model’s behavior. Eval sets calibrated against this model’s outputs. Retrieval indexes built around this model’s context window. Your team’s intuition about what works is intuition about this specific model. The switching cost is no longer “rewrite the API call.” It is “rebuild the system.”

The data question deserves its own paragraph. Most closed-source vendors now offer enterprise tiers with data-handling commitments — your data is not used for training, retention is bounded, processing happens in defined regions. The default consumer-grade API does not include those terms. If your team is calling the consumer API on production data, you have a compliance problem you have not surfaced yet.

Reality Check

What the vendor says: “Use our API to access state-of-the-art AI with no infrastructure required.”

What that means in practice: You get state-of-the-art AI in exchange for accepting their pricing, their deprecation timeline, their data-handling defaults, and their right to change any of those terms with notice. The convenience is real. The dependency is also real. Both are priced in.

What Operators Actually Do

Operators who deploy closed-source well do three things differently from the default.

First, they pick the closed-source vendor based on production fit, not on the demo or the leaderboard. They run the candidate models — usually GPT-4-class, Claude, and Gemini — against a representative eval set under realistic conditions. They measure cost per useful output, latency at production volume, and behavior on the edge cases that matter to the business. The frontier models trade leadership across categories, and the right pick depends on the workload.

Second, they negotiate the enterprise tier, not the consumer API. The enterprise contract is where the data-handling, retention, deprecation-notice, and rate-limit commitments live. The consumer API is for prototyping. Production on the consumer API is a compliance and concentration risk that does not need to exist.

Third, they build for portability without paying the full cost of multi-vendor. Prompts are stored in a model-agnostic format. The eval set runs against at least one alternate model on a quarterly cadence, so the team always knows what “good” looks like elsewhere. Orchestration logic — retrieval, tool use, guardrails — sits outside the vendor’s platform. When the day comes that the vendor reprices the contract or deprecates the model, the migration is measured in weeks, not quarters.

The Questions to Ask

1. Which tier of the API are we calling, and what are the data-handling terms? Consumer API and enterprise API have different terms. If the team cannot say which one is in production, the answer is consumer, and the compliance review is overdue.

2. What is the deprecation and pricing-change policy in writing? Notice period, ability to stay on the prior version, sandbox access to the replacement. If the contract does not address it, the vendor can change the model under your workflow on their schedule.

3. How portable is our system if we had to switch vendors in ninety days? Prompts, eval sets, orchestration, retrieval. If the answer is “not portable at all,” the lock-in is the contract, and the contract belongs to the vendor.