M
Maira
Guest
On 10 August, Meta released Muse Glimmer, a compact open-weight model designed to handle reasoning and agentic tasks on a Mac or PC equipped with a single graphics card. Glimmer was distilled from Meta's more capable Muse Spark model, and Meta says it also plans to release the weights of Muse Spark 1.2.
The important part is not simply that Meta released another model. It is that the model can leave Meta's infrastructure.
That distinction points to a broader shift in AI. For the past several years, the industry has treated the foundation model as its centre of gravity. Whoever trained the most capable system appeared to control the stack. Enterprises rented intelligence through APIs, start-ups built products around those APIs, and governments worried about which countries possessed frontier models.
Open-weight AI is weakening that assumption.
Meta is not alone in recognising the opportunity. IBM and Together AI recently signed a $240 million multi-year agreement to build a large inference cluster on IBM Cloud using Nvidia HGX B300 systems. The initial deployment is expected to use roughly 2,000 Blackwell chips and support open-model inference workloads.
These developments illustrate the same shift from opposite ends of the stack. Meta is making model capability more portable. IBM and Together AI are building the infrastructure required to operate portable models at scale.
The strategic question is therefore changing. It is no longer only: who can train the best model? Increasingly, it is: who can deploy, adapt, route and operate models most effectively?
Foundation models will not disappear. Training the most capable systems still requires extraordinary capital, compute, data and engineering talent. Stanford's 2026 AI Index found that industry produced more than 90% of notable frontier models in 2025.
What is changing is what happens after a model has been trained.
A model contains capability. Inference turns that capability into a reliable service. That requires far more than loading weights onto a GPU. The operational layer includes serving engines, quantisation, batching, request scheduling, caching and model routing. It also includes access controls, fallback policies, monitoring and the evaluation systems needed to decide whether a response was useful enough to justify its cost.
Every one of those choices affects the service delivered to a user. Quantisation may reduce memory requirements but alter output quality. Batching can improve throughput while increasing latency. Caching can lower cost but creates questions about freshness and data separation. Routing can send routine work to an efficient model and reserve a more capable model for difficult cases, but only if the system can recognise which case it is handling.
Open weights make this operational layer more strategically important because they separate a model from its original provider.
OpenAI, for example, makes its gpt-oss models available under the Apache 2.0 licence. Organisations can run them on infrastructure they control, use an independent hosting provider, and adapt or fine-tune them. The weights carry no API fee, although operators still pay for compute, storage, engineering, security and hosting.
Open weights do not make intelligence free. They make it portable.
An API bundles a model with infrastructure, security controls, updates, pricing and a commercial relationship. That simplicity has real value, but it also gives the provider control over variables such as prices, model retirement, usage policies and where workloads run.
With downloadable weights, organisations gain another option. They can operate a model themselves, use an independent inference provider, fine-tune it for a specialised task, or move it between infrastructure providers.
That creates competition around a different question: how cheaply and reliably can a model be turned into useful work?
The IBM–Together AI agreement suggests that businesses already see inference as a significant infrastructure market. Together AI was valued at $8.3 billion in July, and the IBM cluster is explicitly intended to provide production-scale open-model inference.
This is also why model routing matters. A company processing insurance claims does not need the strongest reasoning model for every document. A small model might extract standard fields. A specialised model might detect anomalies. Only an uncertain or unusually complex case may justify an expensive frontier system.
For enterprises, portability must be designed into the application. Business logic should not be tightly coupled to one provider's endpoint or response format. Teams need model-independent interfaces, task-level evaluation suites, standardised telemetry and explicit data boundaries.
They should also measure what matters operationally: cost per successful task, p95 latency, error rate, fallback frequency and the proportion of cases requiring human review. A cheaper model is not cheaper if its failures create more manual work. A faster model is not faster if unreliable output delays the wider process.
The aim is not to swap models constantly. It is to preserve the option when economics, performance, policy or risk changes.
Once several models can solve the same routine task, benchmark leadership becomes only one consideration alongside cost, latency, privacy, reliability and switching friction. Models do not become irrelevant, but they become more substitutable for particular workloads.
Governments are reaching a similar conclusion.
Sovereign AI is often presented as a race to build national foundation models. Yet owning a model achieves little if a country lacks the compute, energy, skills and deployment infrastructure required to run it.
The UK's Compute Roadmap commits more than £1 billion to expand the AI Research Resource twentyfold by 2030 and supports a Sovereign AI Unit with up to £500 million. The roadmap treats domestic compute capacity as strategic infrastructure rather than an incidental input.
A government does not need to invent every model it uses. It does need enough control over compute, data, deployment and procurement to retain meaningful choices.
Open weights can help. They allow a country or regulated organisation to run a foreign-developed model under domestic jurisdiction rather than sending sensitive data permanently through a foreign API. They may also make it easier to inspect, adapt and replace a model when requirements change.
But open weights do not eliminate dependence. Chips, energy, cloud infrastructure, networking and engineering talent remain concentrated resources. The Center for a New American Security's Sovereign AI Index tracks national projects across infrastructure, models and data, with infrastructure representing the largest category.
Sovereignty is therefore less about owning every component than maintaining credible alternatives across the stack.
There is a powerful argument against pushing this logic too far.
Once capable weights circulate, the original developer loses many of the controls available through an API. Users can alter safeguards, fine-tune behaviour or operate models without central monitoring. OpenAI itself notes that determined attackers can fine-tune open-weight models to bypass refusals in ways that a developer can no longer revoke centrally.
Government testing shows why this matters. The UK AI Security Institute found that GLM-5.2, released in June 2026, was the most cyber-capable open-weight model it had tested at the time. It performed similarly to leading closed models released roughly four to seven months earlier. That gap had narrowed from the six-to-ten-month lag the institute measured through much of 2025.
This is not a minor concern. Wider access to capable weights can widen access to harmful capabilities as well.
However, it does not follow that the only safe approach is to keep intelligence permanently tied to a handful of APIs. Risk also depends on what tools a model can access, how much compute it receives, whether it can act autonomously, what data it can reach and where it is deployed.
Safety policy therefore has to follow the architecture. Organisations need capability evaluations, secure infrastructure, model provenance, deployment controls, least-privilege tool access, monitoring and clear accountability for high-risk uses. Those controls matter whether the underlying model is open-weight or closed.
Executives should stop designing AI systems around the assumption that one model provider will remain central forever.
Applications should allow models to be replaced without rebuilding the surrounding workflow. Teams should measure business outcomes rather than relying on benchmark reputation. Efficient models can handle routine work, while expensive frontier systems are reserved for problems that genuinely require them. Proprietary data, customer workflows and evaluation systems should remain separate from any single model vendor.
Policymakers should make the same adjustment. Investment is needed not only in models, but also in compute capacity, interoperability, evaluation infrastructure, open standards and the ability to move workloads between providers. Sovereignty should mean retaining meaningful options, not attempting to build every component domestically.
Engineers, meanwhile, should treat the model as a component rather than the whole architecture.
The foundation model remains important, but it is no longer the entire strategy. Competitive advantage is moving towards the systems that select, adapt, evaluate and operate models effectively.
The next contest in AI will not only be about who creates intelligence. It will be about who can put that intelligence to work reliably, safely and economically.
The important part is not simply that Meta released another model. It is that the model can leave Meta's infrastructure.
That distinction points to a broader shift in AI. For the past several years, the industry has treated the foundation model as its centre of gravity. Whoever trained the most capable system appeared to control the stack. Enterprises rented intelligence through APIs, start-ups built products around those APIs, and governments worried about which countries possessed frontier models.
Open-weight AI is weakening that assumption.
Meta is not alone in recognising the opportunity. IBM and Together AI recently signed a $240 million multi-year agreement to build a large inference cluster on IBM Cloud using Nvidia HGX B300 systems. The initial deployment is expected to use roughly 2,000 Blackwell chips and support open-model inference workloads.
These developments illustrate the same shift from opposite ends of the stack. Meta is making model capability more portable. IBM and Together AI are building the infrastructure required to operate portable models at scale.
The strategic question is therefore changing. It is no longer only: who can train the best model? Increasingly, it is: who can deploy, adapt, route and operate models most effectively?
The model is becoming one layer of the stack
Foundation models will not disappear. Training the most capable systems still requires extraordinary capital, compute, data and engineering talent. Stanford's 2026 AI Index found that industry produced more than 90% of notable frontier models in 2025.
What is changing is what happens after a model has been trained.
A model contains capability. Inference turns that capability into a reliable service. That requires far more than loading weights onto a GPU. The operational layer includes serving engines, quantisation, batching, request scheduling, caching and model routing. It also includes access controls, fallback policies, monitoring and the evaluation systems needed to decide whether a response was useful enough to justify its cost.
Every one of those choices affects the service delivered to a user. Quantisation may reduce memory requirements but alter output quality. Batching can improve throughput while increasing latency. Caching can lower cost but creates questions about freshness and data separation. Routing can send routine work to an efficient model and reserve a more capable model for difficult cases, but only if the system can recognise which case it is handling.
Open weights make this operational layer more strategically important because they separate a model from its original provider.
OpenAI, for example, makes its gpt-oss models available under the Apache 2.0 licence. Organisations can run them on infrastructure they control, use an independent hosting provider, and adapt or fine-tune them. The weights carry no API fee, although operators still pay for compute, storage, engineering, security and hosting.
Open weights do not make intelligence free. They make it portable.
Portability changes the economics
An API bundles a model with infrastructure, security controls, updates, pricing and a commercial relationship. That simplicity has real value, but it also gives the provider control over variables such as prices, model retirement, usage policies and where workloads run.
With downloadable weights, organisations gain another option. They can operate a model themselves, use an independent inference provider, fine-tune it for a specialised task, or move it between infrastructure providers.
That creates competition around a different question: how cheaply and reliably can a model be turned into useful work?
The IBM–Together AI agreement suggests that businesses already see inference as a significant infrastructure market. Together AI was valued at $8.3 billion in July, and the IBM cluster is explicitly intended to provide production-scale open-model inference.
This is also why model routing matters. A company processing insurance claims does not need the strongest reasoning model for every document. A small model might extract standard fields. A specialised model might detect anomalies. Only an uncertain or unusually complex case may justify an expensive frontier system.
For enterprises, portability must be designed into the application. Business logic should not be tightly coupled to one provider's endpoint or response format. Teams need model-independent interfaces, task-level evaluation suites, standardised telemetry and explicit data boundaries.
They should also measure what matters operationally: cost per successful task, p95 latency, error rate, fallback frequency and the proportion of cases requiring human review. A cheaper model is not cheaper if its failures create more manual work. A faster model is not faster if unreliable output delays the wider process.
The aim is not to swap models constantly. It is to preserve the option when economics, performance, policy or risk changes.
Once several models can solve the same routine task, benchmark leadership becomes only one consideration alongside cost, latency, privacy, reliability and switching friction. Models do not become irrelevant, but they become more substitutable for particular workloads.
Sovereign AI is also an infrastructure question
Governments are reaching a similar conclusion.
Sovereign AI is often presented as a race to build national foundation models. Yet owning a model achieves little if a country lacks the compute, energy, skills and deployment infrastructure required to run it.
The UK's Compute Roadmap commits more than £1 billion to expand the AI Research Resource twentyfold by 2030 and supports a Sovereign AI Unit with up to £500 million. The roadmap treats domestic compute capacity as strategic infrastructure rather than an incidental input.
A government does not need to invent every model it uses. It does need enough control over compute, data, deployment and procurement to retain meaningful choices.
Open weights can help. They allow a country or regulated organisation to run a foreign-developed model under domestic jurisdiction rather than sending sensitive data permanently through a foreign API. They may also make it easier to inspect, adapt and replace a model when requirements change.
But open weights do not eliminate dependence. Chips, energy, cloud infrastructure, networking and engineering talent remain concentrated resources. The Center for a New American Security's Sovereign AI Index tracks national projects across infrastructure, models and data, with infrastructure representing the largest category.
Sovereignty is therefore less about owning every component than maintaining credible alternatives across the stack.
The safety objection is real
There is a powerful argument against pushing this logic too far.
Once capable weights circulate, the original developer loses many of the controls available through an API. Users can alter safeguards, fine-tune behaviour or operate models without central monitoring. OpenAI itself notes that determined attackers can fine-tune open-weight models to bypass refusals in ways that a developer can no longer revoke centrally.
Government testing shows why this matters. The UK AI Security Institute found that GLM-5.2, released in June 2026, was the most cyber-capable open-weight model it had tested at the time. It performed similarly to leading closed models released roughly four to seven months earlier. That gap had narrowed from the six-to-ten-month lag the institute measured through much of 2025.
This is not a minor concern. Wider access to capable weights can widen access to harmful capabilities as well.
However, it does not follow that the only safe approach is to keep intelligence permanently tied to a handful of APIs. Risk also depends on what tools a model can access, how much compute it receives, whether it can act autonomously, what data it can reach and where it is deployed.
Safety policy therefore has to follow the architecture. Organisations need capability evaluations, secure infrastructure, model provenance, deployment controls, least-privilege tool access, monitoring and clear accountability for high-risk uses. Those controls matter whether the underlying model is open-weight or closed.
Build for a world of more interchangeable intelligence
Executives should stop designing AI systems around the assumption that one model provider will remain central forever.
Applications should allow models to be replaced without rebuilding the surrounding workflow. Teams should measure business outcomes rather than relying on benchmark reputation. Efficient models can handle routine work, while expensive frontier systems are reserved for problems that genuinely require them. Proprietary data, customer workflows and evaluation systems should remain separate from any single model vendor.
Policymakers should make the same adjustment. Investment is needed not only in models, but also in compute capacity, interoperability, evaluation infrastructure, open standards and the ability to move workloads between providers. Sovereignty should mean retaining meaningful options, not attempting to build every component domestically.
Engineers, meanwhile, should treat the model as a component rather than the whole architecture.
The foundation model remains important, but it is no longer the entire strategy. Competitive advantage is moving towards the systems that select, adapt, evaluate and operate models effectively.
The next contest in AI will not only be about who creates intelligence. It will be about who can put that intelligence to work reliably, safely and economically.