What is the difference between an open-weight and a proprietary LLM?

With an open-weight model the trained parameters are published under a licence, so you can download them, inspect them, run them on hardware you choose, and pin an exact version forever. With a proprietary model you send requests to an API and receive outputs — the parameters stay with the vendor, who controls versioning, pricing, availability and the jurisdiction the inference runs in. The first is something you hold; the second is something you rent.

How do I avoid AI vendor lock-in?

Choose a model whose weights you could take with you. Pin the exact version rather than a floating alias, keep an evaluation suite you can re-run against any host, and confirm the same model is served by more than one provider before you commit. If a swap means the same weights on a different host, customers see no behaviour change. If it means a different model, you are rewriting prompts, re-tuning tools and re-testing everything.

Can a closed AI API change its behaviour without warning?

Yes. A version deprecation or a quiet retune on the vendor's side can shift your product's output overnight, and you have no way to reproduce the previous behaviour because you never held it. This is not hypothetical risk management — it is the ordinary lifecycle of a hosted model. Pinning an open-weight version removes the class of problem entirely, because the artefact does not change unless you change it.

Are open-weight models good enough for production tool calling?

For most analytics workloads, yes — but be honest about the ceiling. The strongest proprietary models still lead on the hardest multi-turn agentic tool use, and closing that gap by self-hosting brings real operational cost: GPUs, capacity planning, upgrades and on-call. The relevant question is not which model wins in the abstract, but whether the open one clears the bar for your workload with room to spare.

Open Weights as an Exit Strategy: Never Be Hostage to an AI Vendor

Q: Does the EU AI Act favour open-weight models?

It gives models released under free and open-source licences partial exemptions from some general-purpose-AI provider obligations, and open weights materially improve auditability: the exact version can be pinned, inspected, red-teamed and reproduced. For a company deploying an AI feature, that reproducibility is the practical benefit — you can evidence what your system did, rather than describing an API whose internals you never saw.

July 24, 20266 min readBy Rafa Jiménez

Open weights are not a philosophical position. They are the ability to leave — to pin a version, inspect it, reproduce it, and move it somewhere else without your customers noticing. A privacy guarantee you cannot walk away from is not a guarantee.

Key Takeaways

A closed API means renting behaviour you cannot inspect, that can be retuned or deprecated under you, priced unilaterally, in a jurisdiction you did not choose.
Open weights under a permissive licence let you pin the exact version, red-team it, reproduce results, change host, or self-host — the exit is real, which is what makes the commitment credible.
The model inside Seal AI is Apache 2.0 and fits a single 80GB GPU, and the same weights are served by several EU-sovereign providers — so switching host means zero behaviour migration for customers.
Be fair about the trade-off: the very best proprietary models still lead on the hardest multi-turn agentic tool use, and self-hosting carries real operational cost.

Most arguments about open-weight models are arguments about values. This one is about leverage.

When you build a product feature on a closed model API, you are not buying software. You are renting a behaviour. The behaviour lives on someone else's hardware, is defined by parameters you will never see, can be changed without your involvement, is priced by a party with no obligation to consult you, and runs under whichever legal system that party happens to belong to.

None of that is malicious. It is just the shape of the deal. The question worth asking before you sign it is simple: if this arrangement stops working for me, what exactly can I do about it?

Four things you cannot control on a closed API

You cannot pin behaviour. Model endpoints get deprecated, and models get quietly retuned between versions. Either event can shift your product's output overnight — different phrasing, different tool-calling habits, different refusal boundaries — and you cannot roll back, because you never held the artefact. Your regression suite goes red and your only remedy is a support ticket.

You cannot inspect it. You can test the API's outputs, which is worth doing, but you cannot examine the weights, run your own red-team against the model itself, or reproduce a result from six months ago to explain to a customer what happened. For anything you may have to evidence later, that gap matters.

You cannot set the price. Inference pricing is set by one side. If a per-token price doubles, a feature that was comfortably profitable may not be, and rebuilding on another vendor's model is not a weekend of work.

You cannot pick the jurisdiction. An EU region is a residency choice, not a sovereignty one. If the company operating the inference answers to US law, so does the data it holds — a distinction we unpack in Residency Is Not Sovereignty.

What open weights actually buy you

An open-weight model published under a permissive licence changes the position on all four points, and it does so for an unglamorous reason: the artefact is a file, and you can have a copy.

Pin the exact version. The model your product shipped with is the model your product keeps, until you decide otherwise. Behaviour drift becomes a change you make, not a change that happens to you.
Inspect and red-team it. You can attack it, probe it, and characterise its failure modes yourself, rather than inferring them from an endpoint.
Reproduce results. Same weights, same sampling settings, same inputs — an evaluation you ran a year ago can be run again. That is the difference between an audit trail and an anecdote.
Change host, or self-host. If a provider's terms, price, latency or governance stop suiting you, the model moves with you.

Our own setup, concretely

Seal AI runs on gpt-oss-120b: open weights under the Apache 2.0 licence, 117B total parameters with 5.1B active per token in a mixture-of-experts arrangement, a 128k context window, and native MXFP4 quantization that lets it fit on a single 80GB GPU (H100 or MI300X) with first-class vLLM support.

That last detail is the one that does the strategic work. A model that needs a rack is a model only a few operators can serve. A model that fits one accelerator is a model many can — and in practice, many do. Besides our current host, Scaleway's Generative APIs in Paris, the same weights are served by other EU-sovereign providers: OVHcloud AI Endpoints, IONOS AI Model Hub with processing confined to Germany, and Nebius in Finland and France — though Nebius is US-listed, so it is a case for evaluating governance and not only geography.

The practical consequence for customers: a host change is a deployment detail. Same weights, same behaviour, same answers. There is no prompt migration, no re-tuning of the tool inventory, no "the assistant sounds different this week". Compare that with swapping one closed vendor's model for another's, which is a rewrite wearing a configuration change's clothing.

This is what makes the privacy claim survivable

Seal AI's privacy position is specific: inference in Paris only, on a French company with no US parent, zero data retention by default, no training on customer data, and — because nothing crosses a border — GDPR Chapter V is not triggered at all. No Standard Contractual Clauses, no Transfer Impact Assessment, no dependence on the EU-US Data Privacy Framework surviving its next court date.

A commitment like that is only as durable as your ability to keep it when circumstances change. If the model were closed and tied to one vendor, the promise would last exactly as long as that vendor's terms did. Because the weights are open and portable, the promise is ours to keep: if a host's posture changed tomorrow, we could move the same model to another EU-sovereign provider without asking customers to accept a different product.

Open weights also sit well with the EU AI Act. Models released under free and open-source licences receive partial exemptions from some general-purpose-AI provider obligations, and — more usefully day to day — open weights materially improve auditability. The exact version can be pinned, inspected, red-teamed and reproduced. A closed API can change under you silently.

The honest trade-off

Open weights are not free of cost, and they are not the top of every leaderboard.

On the hardest multi-turn agentic tool use, the strongest proprietary models are still ahead. On tau-bench retail, gpt-oss-120b scores 67.8 against a GPT-4o reference of 60.4-61.2 — respectable — while Claude Sonnet 4 reports 80.5, measured with extended thinking plus a prompt addendum per Anthropic's own footnote. Claude Sonnet 4.5 reports 86.2 on tau-2-bench, which is a different benchmark and not directly comparable. Those caveats matter, but so does the headline: for long agentic chains, the frontier closed models lead.

And the exit option has a price of its own. Self-hosting means GPUs, capacity planning, upgrade cycles and someone on call. Most teams should not do it — but they should be able to, and should know what it would take. An escape hatch you have never measured is a decoration.

What tipped it for us is that the gap does not bind on our workload. An analytics assistant answers grounded questions over your data with a well-defined tool inventory; it is not running twenty-step autonomous agent chains. Within the EU-sovereign serverless universe, gpt-oss-120b is the strongest model available, and the best open tool-callers outside it have no EU-sovereign managed offering at all — using them cleanly would mean self-hosting models in the 355B-to-1T parameter range.

The question to ask your vendor

Not "is your model open source?" That invites a philosophical answer. Ask the operational one: if I needed to leave, what would it cost me, and what would my customers notice?

If the answer is "a redeployment, and nothing", the relationship is a choice. If it is "a rewrite, and everything", it is a dependency — and dependencies get priced accordingly, sooner or later.

The reasoning behind our own model choice is documented in the Seal AI model selection audit, and the architecture around it in the private AI architecture documentation.