There is minimal downside to switching to open models
The Low Cost of Migrating to Open-Weight Models
By Andrew Marble | June 21, 2026 | marble.onl | andrew@willows.ai
Not long ago, opting for Linux was viewed as a genuine professional gamble. The risks were tangible:
- Compatibility Hurdles: Rendering a PowerPoint or Word document accurately was a struggle; you had to gamble on whether Open Office's export functions would maintain the intended formatting.
- Siloed Formats: Certain proprietary file types were simply inaccessible, hindering seamless collaboration.
- Unpolished Tools: The ecosystem was filled with ambitious but incomplete open-source projects that felt
unusable"rough around the edges" compared to industry standards.
Personally, my transition was delayed by a single piece of software: Matlab. I clung to Windows for years because of it, an admission I now find somewhat embarrassing.
Today, the landscape has shifted. With the ubiquity of web-based productivity suites and the maturation of the Linux kernel, open-source software is no longer a "sacrifice." While niche fields like CAD might still necessitate a Windows environment, the gap has effectively closed.
The Current State of AI: Proprietary vs. Open
Currently, the "Intelligence Leaderboards" (such as Artificial Analysis) are dominated by closed-source models. As of June 2026, Claude and GPT remain the gold standard.
"Claude code just works."
The "Big Two" offer polished APIs that are easy to integrate. Furthermore, there is a general industry consensus that these providers are "trustworthy" enough to handle standard LLM queries without undue alarm.
Comparison of Model Access
| Feature | Proprietary (API) | Open-Weight (Third-Party/Self-Hosted) |
|---|---|---|
| Performance | State-of-the-Art (SOTA) | Very Close (Trailing by months) |
| Ease of Use | High (Plug-and-play) | Moderate to Low |
| Privacy | Generally Accepted | "Dodgier" (via OpenRouter, etc.) |
| Control | Low | High (if self-hosted) |
While open models can be accessed via third parties like OpenRouter, these routes often feel less secure regarding data privacy. For confidential client data, I lack the same confidence I have in the major providers.
The Self-Hosting Trade-off: Running models locally solves the privacy dilemma, but it introduces a new set of burdens:
The Catalyst for Change
For a long time, open models were merely a hobby. I tinkered with them following the initial Llama leak and used them for edge cases, but my professional workflow remained tethered to the Big Two.
That changed with the introduction of ID verification for Claude.
Between the rollout of identity checks, the increasing prevalence of restrictive "safeguards," and the "Mythos" situation, the trajectory for the user experience has been clear: things are getting worse. I refuse to participate in ID verification (or the performative "LARPing" that accompanies it).
This raises a critical question: What is the actual professional penalty for abandoning the top-tier proprietary models?
The Transition Logic
Final Assessment
I am already equipped to deploy open models in the cloud or locally, and the available coding harnesses are robust. Most importantly, the performance delta is shrinking. The leading open models are now nearly on par with the leaders, usually trailing by only a few months of development.
This is not the 2008 era of Linux vs. Windows. The gap is narrow.
While I expect a slight dip in efficiency, it isn't a deal-breaker. It is certainly not as catastrophic as switching from Matlab to GNU Octave would have been during my research days.
My current migration checklist:
- Set up local inference engine
- Configure cloud GPU instances
- Integrate open-model coding harnesses
- Accept short-term productivity dip
A Note on Terminology
I use the term open to refer to models where weights are available. While I've argued previously that this doesn't strictly make them "open source," it serves as a useful shorthand. Notably, many current leading open models use the MIT License, which I do consider truly open source.
Assumption: This analysis assumes a technical role involving general productivity software (e.g., MS Office).
The productivity loss can be modeled simply as: Where is a small, manageable value.