When Intelligence Becomes a Utility, Do You Still Need to Own the Model?

ASTRA 6.1 at roughly one-fifth the price makes me question one of the most repeated arguments in enterprise AI today: that companies should own their models.
For the last few years, the custom SLM argument has been compelling. Train a smaller model on your own data, fine-tune it for your domain, run it on your own infrastructure, control the weights, reduce inference cost, avoid vendor lock-in and keep sensitive workloads within your environment. Technically and economically, this has made a lot of sense.
But I increasingly think one part of that argument is going to weaken very quickly: cost.
The analogy I keep coming back to is electricity.
If electricity generation, storage and distribution become highly optimised, reliable and cheap, most of us would rather pay the bill than buy and maintain a generator. Owning a generator still makes sense in certain situations. You may operate somewhere unreliable, need complete independence, have unusual continuity requirements, or simply not trust the grid. But for the majority, ownership becomes unnecessary complexity.
AI inference may be moving in exactly that direction.
The original economic argument for SLMs was partly straightforward: why repeatedly pay expensive frontier-model API costs when you can train a specialised model, host it yourself and serve a narrower task far more cheaply?
That equation changes if frontier intelligence itself keeps becoming dramatically cheaper.
ASTRA 6.1 is interesting to me less because of its absolute price and more because of what it suggests about the trajectory. Models are becoming more capable while inference gets cheaper. Serving infrastructure is improving. Hardware is improving. Caching is improving. Competition is pushing prices down. Distillation, quantisation and better architectures keep reducing the amount of compute needed to produce useful intelligence.
If that curve continues, we eventually reach a point where an enterprise has to ask a different question: why exactly are we training this model ourselves?
Because owning a model is not simply about owning weights. It means owning the entire lifecycle around those weights: dataset preparation, fine-tuning, training pipelines, evaluation, GPU infrastructure, serving, quantisation, security, observability, regression testing, model upgrades, drift management and continuous maintenance. It also means assigning highly skilled engineers to keep that machinery running.
That cost is often missing from the comparison.
It is easy to compare API token pricing with GPU compute and conclude that self-hosting is cheaper. The more meaningful comparison is total system cost, including engineering effort, infrastructure complexity, model operations and the opportunity cost of maintaining something that may not itself be the source of competitive advantage.
At a certain point, the question changes from “Why would we rent intelligence forever?” to “Why are we manufacturing intelligence ourselves?”
That does not mean SLMs disappear. Quite the opposite. Smaller models will probably become more common, but increasingly for architectural reasons rather than purely economic ones.
There are still many situations where owning or deploying a specialised model makes complete sense: edge devices, offline systems, defence environments, regulated workloads, ultra-low-latency systems, highly repetitive high-volume tasks, sovereign deployments, private networks and workloads where data simply cannot leave a controlled boundary.
Those are strong reasons to own the model.
“API tokens are expensive” may gradually stop being one.
And that leads to what I think is the more important enterprise AI question.
Perhaps the moat was never the model.
If intelligence becomes increasingly commoditised, then enterprise value moves elsewhere. It moves into proprietary data, context, workflows, domain knowledge, evaluation systems, integrations, permissions, business processes and the ability to reliably convert probabilistic model output into deterministic business outcomes.
In that architecture, the model becomes increasingly replaceable.
One workload may run on a frontier model. Another may use an open-weight model. A classifier may run locally. A small specialised model may handle millions of repetitive decisions. Sensitive workloads may stay on-premise. More complex reasoning may be routed to whatever model currently performs best.
The enterprise advantage then comes from owning the orchestration layer around all of this.
That means owning your data, your context, your workflows, your IP, your evaluation layer, your customer relationships and, perhaps most importantly, your ability to swap the underlying intelligence whenever something faster, cheaper or better arrives.
This is why I increasingly think model-agnostic architecture matters more than model ownership.
Cloud computing went through a similar transition. Companies once considered owning infrastructure strategically important. Then infrastructure became reliable, elastic and inexpensive enough that the conversation shifted from “Which servers should we buy?” to “What should we build?”
AI may eventually follow the same path.
We may stop thinking about intelligence as something every enterprise must manufacture and start treating it as another infrastructure primitive: compute, storage, networking and intelligence, all available on demand.
If that happens, the winning enterprise AI strategy may not necessarily be to own your model. It may simply be to own everything that makes the model useful.
If electricity is extraordinarily well optimised across generation, storage and distribution, most of us would rather pay the electricity bill than buy a generator.
AI may be heading there faster than we think.
Keep reading
Models That Choose, Not Generate: Why the Decision Layer Is Becoming Its Own Category
TypeSafe AI released Jev on 15 September. Within a fortnight there were open alternatives. The interesting part is not any single model — it is that the industry has started treating 'decide' as a different problem from 'generate', and building separate infrastructure for it.
Laya-MLX as a Sub-15 ms Decision Layer for Orchestrating Specialised SLMs on Apple Silicon
Multi-model systems built from specialised Small Language Models need something that decides, for every request, which model should answer. Using a generative model for that spends latency, tokens and parsing effort on what is fundamentally a classification problem. A research paper on typed decisions as a routing primitive.
Training a Small Language Model: What I Learned About Probability, Context and Bias
A language model does not need a perfect description of reality to be useful. Training a small one made tokens, probability distributions, context windows and bias stop being buzzwords — and made the difference between statistical correctness and judgement surprisingly tangible.