The model is free to download. The bills start coming afterward. For a company looking to summarize contracts, support developers or query its documentation, open-weight AI models offer an appealing promise: taking back control. But replacing an API with a self-hosted model does not eliminate dependencies. It shifts them to chips, software and teams. Looking ahead to September 2026, this question deserves more than a showdown between virtuous openness and cloud lock-in. The historical facts presented here provide a foundation; the developments discussed remain prospective.
Open weights do not necessarily mean free and open-source software
The first pitfall is terminology. An open-weight model allows users to obtain the parameters learned during training and, depending on its license, to run or adapt it. That does not mean its training data, code and development recipe are fully accessible. Nor does it mean that every use is permitted.
The releases of 2024 established this diversity. Meta released Llama 3 and then Llama 3.1 under a community license with specific conditions. Mistral AI distributed some models, including Mixtral 8x22B, under the Apache 2.0 license. Two downloads can therefore entail very different obligations, even when both models are described as “open.”
Checks must focus on the exact version. Commercial use, redistribution, adaptation, attribution and any industry-specific restrictions: the legal department must read the license, not just the marketing material. Access to the weights guarantees neither the absence of protected content in the training data nor indemnification in the event of litigation. For APIs, contractual protections also vary by provider and offering.
Hosting: the GPU is only the beginning
Imagine a distributor deploying an assistant for its sales teams. With an API, it primarily buys requests or tokens, the fragments of text processed by the model. With a self-hosted deployment, it must plan capacity: accelerator memory, throughput, response times and concurrent user numbers. A model that works during a demonstration may become overloaded when the offices open.
A small, specialized model can run on relatively modest infrastructure. A large model, or a very long context, changes the equation. Reducing the precision of the weights through quantization saves memory, but its effects on quality must be measured. Storage, networking, monitoring, backups and redundancy add to the bill. Renting GPUs avoids the upfront purchase, not the recurring expenses.
The relevant comparison is therefore not “free versus paid,” but the total cost per correctly completed task. A cheap response that an employee has to correct may cost more than a response with a higher price tag. Conversely, a compact, well-adapted model can become cost-effective at high, steady and predictable volumes.
What a quote can easily leave out
- Unused capacity between traffic peaks and the reserve needed to absorb surges.
- The engineering time devoted to deployment, evaluations and incidents.
- Supporting processes: document retrieval, filtering, logging and human oversight.
- The cost of downtime or an undetected decline in response quality.
An API pools some of these costs at the provider level. In return, it leaves customers exposed to the provider’s pricing, quotas and product-line decisions. Self-hosting provides more levers, but requires knowing how to use them.
Security: keeping the data is not enough
The strongest argument for hosting under an organization’s control often concerns data. Sensitive contracts or internal files can remain in a chosen environment. Even so, organizations must check where logs, backups, monitoring tools and any telemetry go. A model deployed in an external cloud does not automatically mean data sovereignty.
A business API, meanwhile, may offer commitments on data retention, location or exclusion from training. These provisions must be verified contractually, rather than inferred from a consumer offering. The choice is therefore between two architectures and two chains of responsibility, not automatically between confidentiality and exposure.
In both cases, the risks inherent in assistants remain. A malicious document may contain an instruction designed to redirect the model: this is prompt injection. If the assistant can send emails or modify a database, the consequences extend beyond a poor response. Its permissions must be limited, tools isolated and human approval required for sensitive actions.
Self-hosting adds a software supply chain that must be secured: file provenance, libraries, containers and updates. Some repositories offer code to run alongside the model; accepting it without an audit creates a risk distinct from that of the weights themselves. Openness makes inspection easier; it does not replace it.
Maintenance: owning a version also means maintaining it
A team can keep a downloaded version for a long time, a genuine advantage over an API that may retire an older model. But that stability has a downside. Inference engines evolve, drivers change and vulnerabilities emerge. Even without retraining the model, its environment must be maintained and its performance checked.
Changing models is no simple file swap either. Message formats, tool behavior, context length and French-language quality can vary. An instruction that works well on one version may become unreliable on the next. Every migration calls for testing on real cases, using business criteria rather than just a general-purpose ranking.
With an API, the provider handles much of the operation. The company nevertheless remains responsible for its application: permissions, the quality of document sources, response checks and error tracking. Outsourcing inference does not mean outsourcing all responsibility for reliability.
Less dependence, or different dependencies?
Open weights offer an important option: switching hosting providers without necessarily abandoning the model. That portability remains subject to the license, available hardware and software compatibility. An optimization closely tied to a particular accelerator can recreate technical dependence. Vendor lock-in sometimes becomes dependence on in-house expertise.
To make a choice, it is better to test a clearly defined use case over several weeks. Measuring actual quality, turnaround times, total costs and operational effort reveals more than comparing advertised prices. A hybrid setup may also make sense: a model under the organization’s control for certain data, and an API for occasional needs, provided explicit routing rules are in place.
What now? Looking ahead to September 2026, it seems plausible that improvements in small models and deployment tools will broaden the uses of self-hosting. That is not a promise of cost-free autonomy. The best-positioned organizations will be those able to document their dependencies, test an alternative and fund day-to-day operations. Real bargaining power comes not just from owning the weights, but from being able to switch solutions without bringing the business to a halt.
