Open-weight vs API models for enterprise
A hosted model is usually more capable today. Open weights win when where the data sits matters more than the last few points of quality.
The short answer
An open-weight model is one whose weights you can download and run on infrastructure you control. A hosted API model is run by a provider, and you pay per use. Open weights give control over where data goes and which version runs. A hosted model usually gives more capability and less operational work. Many production systems use both, routing each task to the model it suits.
Decision table
| Question | Open-weight model | Hosted API model |
|---|---|---|
| What it is | A model you run on your own or chosen infrastructure | A model a provider runs and exposes through an API |
| Who owns the outcome | Your team, for hosting, updates and quality | Shared with the provider, within its service terms |
| Typical duration | Weeks to set up hosting and evaluation | Days to first call |
| What you get at the end | Control of location and version, with operating duties | Access to a managed model, with provider-side updates |
| Main risk | Running and securing infrastructure well | Data location and version changes outside your control |
| Best for | Strict residency, fixed versions, high steady volume | Fast delivery, top capability, low operations effort |
Use cases for open-weight model
- Records that must stay in one country. A workflow reads personal data and the policy requires processing in-country under your control.
- A fixed model version for a regulated process. The process must not change behaviour without a formal review, so the version is pinned.
- High, steady volume on a narrow task. A classification or extraction task runs constantly, and the cost per call matters more than peak quality.
- Offline or restricted network use. The system must run where external calls are not allowed.
Use cases for hosted api model
- Complex reasoning on varied tasks. The workflow needs the strongest general capability, and the team accepts the provider's terms for it.
- A prototype or pilot. A first version is best built on a hosted model to test the use case quickly.
- A small team with no capacity to host models. Running inference, monitoring and upgrades is more than the team can carry.
- Spiky or uncertain demand. Paying per use avoids reserving hardware for peaks that may not come.
Trade-offs
Open-weight model
Advantages. Control over data location and version. Predictable behaviour when the version is pinned. Cost can be lower at high steady volume.
Disadvantages. Hosting, monitoring and security are your responsibility. Capability may trail the strongest hosted models on hard tasks. Upgrades and evaluations take team time.
Hosted API model
Advantages. Usually the highest capability available for general tasks. No hosting to run, secure or upgrade. Quick to start and easy to change.
Disadvantages. Data goes to the provider under its terms. Versions can change on the provider's schedule. Cost rises with volume and is harder to predict.
How each option runs
Open-weight model, step by step:
- Step 1. Confirm the licence allows the intended use, and record the exact version.
- Step 2. Host it, then evaluate it on the workflow's own cases before any use.
- Step 3. Set up monitoring, security review and a schedule for version changes.
Hosted API model, step by step:
- Step 1. Check the provider's data terms and where data is processed.
- Step 2. Evaluate it on the workflow's own cases, and record the version it returned.
- Step 3. Watch for version changes, and re-run the evaluation when they happen.
What drives the effort
- Where the data must be processed, and under whose control.
- How much volume the workflow runs, and how steady it is.
- How much hosting and security work the team can take on.
- How much capability the task needs, measured on its own cases.
Model prices change, so check the provider's current pages before any cost decision.
This site does not publish prices. The engagements page describes what each shape includes.
A checklist before you choose
- Must the data stay in a location or under a control a provider cannot give?
- Does the process need a fixed model version for a long period?
- Can the team run and secure the hosting?
- Does the task need top general capability, or a narrow one?
If the first two are yes and the last is yes, open weights are the likely fit. If the last is no and the first two are no, a hosted API is the usual start.
What people get wrong
- They pick open weights for cost, without measuring the cost of their own operations.
- They pick a hosted model without checking where the data is processed.
- They compare models on a public benchmark rather than on their own cases.
A hybrid that often works
Route routine, narrow tasks to an open-weight model where residency or cost requires it, and send hard tasks to a hosted model where the data terms allow. Keep one evaluation set across both, so a routing change is measured, not guessed.
Common questions
Is an open-weight model always cheaper?
Not necessarily. Hosting, monitoring and upgrades cost time and money. Compare the total cost of running each option, not only the price per call.
What does the licence of an open-weight model allow?
It varies by model. Read the licence for the specific model and version before use, including any restriction on commercial use.
Can I switch between the two later?
Yes, if the prompts, tools and evaluation set are kept separate from any one model. Model routing makes the switch a configuration change.
How do I compare models fairly?
Score each on the workflow's own cases, with the same evaluation set and the same prompts. Record the version and the date of each run.