Choosing a model is no longer only about which one performs best today.
Once a model becomes part of your product or workflow (even life?) more practical questions arise, like "What happens if it is deprecated, repriced, or meaningfully changed?", "And am I cautious enough about the data that I am sending through it?", among many others you might've questioned yourself too.
This is not an argument against proprietary APIs per se. Those are excellent for quick experiments, day-to-day work, or really for whoever wants the fastest path to getting things done (even if not the best). But if a model becomes part of your stack, the question is no longer only about performance today, but also about control tomorrow.
And by control I mostly mean things such as stability, migration cost, observability, compliance, and predictability. Those things do not look exciting in a benchmark chart, but they matter a lot once the model is no longer an experiment and starts becoming part of actual workflows.
That is mostly why I think this comes down to choosing wisely i.e., not only choosing the best model today, but choosing the tradeoffs you are willing to live with tomorrow.
Are Proprietary APIs The Solution?
The main proprietary API providers are constantly revising their pricing structures, and costs can spike dramatically as models are updated or usage tiers are restructured, leaving your budget exposed to decisions completely out of your control.
And then there are model deprecations. Those can really hurt your workflows if you depend on specific model features or have spent significant time on prompt engineering that may behave differently on another model. A provider may consider the new model better according to benchmark scores, while it may still be worse for your actual use cases.
And the breakage is not always obvious. Sometimes it is output format drift, sometimes tool calling starts behaving differently, sometimes latency changes, and sometimes the model just becomes more or less strict in ways that affect your application.
There is also the very human side of this. People get attached to models, their style, their behavior, and the workflows they enable. OpenAI's announcement about retiring GPT-4o from ChatGPT is a funny but very real example of that, especially when you look at the replies on X and people pushing #keep4o. It may sound like a meme, but it also shows how fast dependency forms once a model becomes part of someone's routine. See "Retiring GPT-4o, GPT-4.1, GPT-4.1 mini, and OpenAI o4-mini in ChatGPT".
Below is another example, this time around an OpenAI embedding model that was, thankfully, mistakenly flagged as deprecated.
What Do I Mean By Open?
Open models offer a meaningful answer to many of those concerns, but only if we are precise with the terms we use. Not every "open" release gives you the same level of freedom, and I think that is where a lot of confusion comes from.
To me, and I think this is closer to how the community tends to use these terms, open-weight means the weights are available and you can run them, but often under non-commercial terms. Open-source is a different thing, and this is where licenses such as MIT or Apache 2.0 matter more, because they let you use the weights much more freely, including in commercial settings. And then open-science goes one step further, it is about opening up the process behind the model, sharing how it was built, what worked, what did not, and enough detail to help accelerate both open-source and open-science itself.
That is why, at least to me, the ideal is not only open-weight but a truly open-source release, and if possible one that also leans into open-science. The more you understand about the data, the design choices, the training process, and the evaluation setup, the better you understand what you are building on top of.
A good example of that is OLMo. Ai2 introduced it as a "truly open" LLM and did not stop at releasing weights alone. They also released the pre-training data, training code, evaluation tooling, checkpoints, metrics, and logs, which is much closer to what many people actually mean when they say they want openness in AI. The first OLMo release dates back Feb, 2024 in "Hello OLMo: A truly open LLM", and is still really impactful to this day as it set a precedent on what "open" truly means for language models.
A lot of what people now take for granted around open models, reproducibility, inference, tooling, and distribution exists because many people kept pushing for more openness and better infrastructure instead of keeping everything behind APIs.
Should I Go Local Then?
I am a firm believer in local models and, like Armin Ronacher in "Pushing Local Models With Focus and Polish" and many others, I want local models to succeed. But as models grow larger and consumer-grade compute struggles to keep up, we need to look for alternatives. That is where managed cloud compute comes in: you do not need to own the hardware, fit a rack in your basement, or multiply your electricity bill (that's likely a flex nowadays).
For some use cases local is enough, and honestly that is still the nicest setup when it works, e.g., every time I travel long distances I have my company MacBook Pro M2 with llama.cpp + LM Studio, and a handful of models downloaded locally.
But once you need more memory, more concurrency, or just something a bit more stable for daily use, managed cloud compute starts looking like a very reasonable middle ground, specifically as models grow larger and larger, specifically they ones that compete with proprietary models, e.g.,
-
Benchmark chart for zai-org/GLM-5.1. Source: zai-org/GLM-5.1 on Hugging Face -
Benchmark chart for deepseek-ai/DeepSeek-V4-Pro. Source: deepseek-ai/DeepSeek-V4-Pro on Hugging Face
With a self-hosted deployment, you pull the model weights, you own the runtime, your traces stay within your infrastructure, and you decide when, or whether, to upgrade. Compared to purely local deployments, cloud-hosted open models can also scale horizontally to handle concurrent sessions and avoid bottlenecking on memory, as long as there is enough capacity available.
Of course, this also comes with more work. You need to care about setup, monitoring, scaling, configuration, serving stacks, and all the small operational details that proprietary APIs abstract away. That tradeoff is real, and I do not think it should be downplayed.
That is also why I think the work that open-source inference engines and libraries such as vLLM (with vLLM Recipes being a great resource for practical serving patterns), SGLang, llama.cpp, MLX, Transformers, Text Embeddings Inference, Diffusers, Sentence Transformers, and many others is so important. They reduce a lot of the friction around serving open models, and they make self-hosting or managed hosting much more realistic for normal teams.
I also think this is where my work at Hugging Face matters to me personally. A big part of the value in open-source is not only having access to the models, but also reducing the friction of taking them from "cool demo" to something you can actually run reliably on managed compute in the cloud. That is why I care about efforts that make open models easier to consume with sane defaults and validated configurations across platforms, whether that is through Amazon SageMaker JumpStart, the Microsoft Foundry model catalog, Google Cloud Vertex AI Model Garden, or the Dell Enterprise Hub. To me, all of that helps narrow the gap between the convenience of proprietary APIs and the control of open models.
Deploying your own agents on managed compute gives you a compelling middle ground. The scalability and availability you would expect from a managed service, without the same level of lock-in and opacity that comes with proprietary APIs.
When Open Is Not Really Open
At the same time, proprietary APIs might still win very often on convenience, speed of integration, and reduced operational burden. That is exactly why they are so useful. I just think it is worth being precise with the words we use when we compare them to "open" alternatives.
A recent example is MiniMax M2.7. It is a good reminder that downloadable or self-hostable does not automatically mean open-source in the permissive sense. MiniMax released the weights, but the official LICENSE states that commercial use requires prior written authorization from MiniMax. So yes, you may be able to run it, test it, or prototype with it, but that does not mean you are free to build and ship a commercial product around it without extra permission.
That is not a small technicality. It directly affects what kind of long-term ownership you really have. And it is also why I think it is important to distinguish between open-weight, open-source, and genuinely open releases instead of throwing everything into the same bucket.
There was also public discussion around the MiniMax M2.7 licensing expectations on X, which adds some useful context on how people interpreted the release and how MiniMax responded.
As per Ryan Lee, DevRel @ MiniMax, the reason for the licensing change was not that they wanted to stop people from running, fine-tuning, or researching the model, but that they kept seeing low-quality commercial deployments hurt the model's reputation. According to that explanation, badly configured hosted endpoints, aggressive quantization, wrong templates, and even swapped models were creating poor experiences while still carrying the MiniMax name. Their licensing change was their attempt to draw a line around commercial hosting, protect users from poor deployments, and make the broader ecosystem more sustainable for both serious hosting providers and for MiniMax itself.
Looking Ahead
In the end, it all comes down to choosing wisely. Proprietary APIs are useful, often excellent, and in many cases the right choice. Open models are usually more work, but they are worth taking seriously because they give you portability, control, and a more robust long-term foundation, whether you run them locally, in your own cloud, or on managed compute.
Nothing here is free of tradeoffs. Proprietary APIs are easier to start with and often easier to live with day-to-day. Open models usually come with more setup, more maintenance, and sometimes require a bit more assembly to reach the same level of polish or convenience. But if the goal is to build something that remains robust over time and is not overly controlled by others, then it is worth deciding which downsides you are more comfortable owning in the long term.