Article — "Open-source inference share is falling — and Decagon says that's a sign of adoption, not defeat": Article — "Open-source inference share is falling — and Decagon says that's a sign of adoption, not defeat": Here is a data point built to fool you.
Open-source models just fell to 11% of enterprise LLM spend, down from 19% a year ago. If you run product, you read that as a verdict: the open-weight hype cycle peaked, the frontier labs won, standardize on a closed API and move on.
Now hold that against a second fact from the same company that flagged the first. Decagon — which runs AI customer service agents inside banks, airlines, and telcos — runs roughly 90% of its own production workloads on open-source models.
Both facts are true. The whole game is understanding why, because the answer isn't a market signal to read. It's a sequencing instruction to follow.
Start with the wrong conclusion, because it's seductive. The obvious story is a contest: closed versus open, smart versus cheap, and the money is voting closed. But the falling share isn't a contest result. It's a maturity-curve artifact.
Here's the mechanism Jesse Zhang lays out. When a use case is new, you want the smartest general-purpose model you can get, because you don't yet know the shape of the problem. You pay a premium for intelligence you might not end up needing — and at that stage, that's the correct trade.
Once the use case is fully built out — when you know the distribution of inputs, the behaviors you need, the failure modes to guard against — the trade flips. Now general intelligence is overhead, and you want the smallest, fastest model fine-tuned to do your one thing extremely well.
So why is the aggregate share falling? Because enterprise AI as a whole sits at the very beginning of that curve.
Last year enterprises stopped building and started buying, and thousands of brand-new use cases spun up at once. New use cases run on frontier models. So closed-source spend exploded — not because open source lost, but because the numerator of mature deployments couldn't grow as fast as the denominator of immature ones.
The 11% is a denominator problem. The pool of immature use cases is growing faster than the pool of mature ones, and every one of those prototypes is a future open-source migration waiting to happen.
The falling aggregate share is where the market is now; Decagon's 90% is where a matured use case ends up.
That reframing matters, but it's not the actionable part. The actionable part is that this is Decagon's own biography.
They did not start at 90% open source. "Started it was it was all closed source because you're just trying to figure out the use case," Zhang says. They only migrated once they knew the exact shape of the customer-service problem — the workflows, the volume, the failure modes.
Which tells you the two facts aren't a paradox at all. They're the same company at two points on one line. The falling aggregate share is where the market is now; Decagon's 90% is where a matured use case ends up. Customer service is simply one of the most obvious, well-understood, high-volume categories in the industry, so Decagon is further down the curve than the average deployment.
Read that way, the instruction is explicit: treat every new use case as a two-phase deployment. Frontier model to discover the shape. Fine-tuned open source to run it in production. Do not confuse the two.
And the biggest mistake right now is optimizing model choice for the phase you're not in.
There are two ways to make that mistake, and both are common.
The first is migrating too early — fine-tuning a small model before the shape of the agent is finalized. You lock in specialization against a workflow that's still moving, and you lose the thing frontier models are actually for at that stage: the freedom to iterate and experiment freely without owning any infrastructure. You bought efficiency you can't yet use, and you gave up flexibility you still need.
The second mistake is never migrating at all. Fine-tuning is real work. Most organizations don't have the resources or the expertise, so they leave a matured, high-volume workload sitting on a premium frontier API indefinitely, paying for general intelligence that has become pure overhead.
The discipline is knowing exactly when the trade flips. Zhang gives three preconditions, and all three have to hold.
The use case has to be very high ROI — high enough to justify the engineering. It has to be already fully deployed at scale, so you're optimizing something real, not a prototype. And you need enough data to be sure a smaller model can match the frontier one on that specific task.
Miss any one of those and it's simply easier to plug in a closed model, own no infrastructure, and keep iterating. That's not laziness. That's correct sequencing for an unfinished use case.
Notice what these preconditions do to the timeline. Because most use cases aren't at the point where the agent's shape is finalized, the aggregate open-source share won't inflect up soon — Zhang thinks it'll take years, longer than most people expect. The migration is slow because maturity is slow, not because open source is weak.
Now the part that dissolves the framing everyone started with.
The whole "dumb-cheap versus smart-expensive" trade-off is false. When you fine-tune a smaller model on a narrow task, you don't accept worse performance to save money. You get the opposite.
Ashwin Sreenivas puts it plainly: "When we fine-tune smaller, dumber models, it's that they're just not as general purpose, but on the specific task we want them to do, they actually outperform the large, smart, state-of-the-art models" ... "So we end up getting all three things. It is better at the task, it is cheaper, and it is faster."
Better, cheaper, faster — at once. The smaller model isn't dumber in any way that matters here; it's just less general-purpose, and generality is exactly what a matured use case no longer needs.
This is why, for Decagon, cost was never the driver. In customer service, latency makes or breaks the product — a conversation where every turn takes eight seconds is not a product anyone will use. Small, fast, fine-tuned models were the only way to hit the quality bar, and small-plus-fine-tuned means open weights. The cost savings were real but secondary, a downstream consequence of maturity rather than the reason for it.
So the question was never which model is smarter. A frontier model will always be smarter in general. That's precisely what makes it the right tool for discovery and the wrong tool for a task you've already mapped.
The question is which phase you're in.
If you're discovering the shape of a new workflow, pay for intelligence and iterate freely on a closed API — and don't let a cheaper-per-token number pull you into premature fine-tuning. If you've got a high-ROI workload fully deployed at scale with enough data behind it, the trade has flipped, and leaving it on a frontier model is money and latency you're lighting on fire.
The falling 11% isn't telling you who won. It's telling you the market is early. Your job isn't to bet on a side. It's to know, for each use case you own, exactly where it sits on that line — and to switch on purpose, not by default.