The Commoditisation of Model Capability

A commodity is not a cheap thing or a simple thing. It is a thing whose suppliers are interchangeable at the point of purchase. That definition is testable, and applying it carefully gives a much less sweeping answer than the usual one.

A definition you can test

An input is commoditised for you when two conditions hold: several suppliers meet your requirement, and moving between them costs you approximately nothing. Both halves matter, and the second is the one that is usually assumed rather than measured.

The test is concrete. If the ranked list of suppliers changed tomorrow — a different model became the cheapest one clearing your bar — how much work would it take you to be running on it, and what is the probability that something breaks silently? Write both down. That is your switching cost, and it is the only thing standing between you and treating models as a commodity.

Switching is worth doing when

  S  <  (c_old - c_new) * V * T

  S        one-off cost of switching: engineering time,
           re-running evals, the risk premium you attach
           to a silent regression
  c        cost per unit
  V        units per month
  T        months you expect to stay on the new model

Assume S = $12,000, a saving of $0.004 per request,
and 900,000 requests a month:

  monthly saving = $3,600  ->  payback 3.3 months

If your expected time before the next switch is
shorter than the payback, the saving is not real.

That last line is the one people miss. In a market where a better and cheaper option appears frequently, T is short, which raises the bar every individual switch has to clear. Rapid improvement can make switching less attractive, not more, unless the cost of switching is itself driven down.

Where switching costs actually live

The assumed switching cost is the API integration: different SDK, different parameter names, different error shapes. That is real and it is the cheap part, and it is the part an abstraction layer or a common schema removes entirely.

The expensive part is everything that was fitted to the old model without anyone deciding to fit it:

Two conclusions follow. For a buyer: the way to make models a commodity is to invest in the things that lower S — an evaluation suite you trust, prompts kept portable, a provider-agnostic call layer — and each of those is a one-off cost that pays off on every future switch. For a supplier: the durable stickiness is not in the model, it is in everything a customer builds around it, which is why suppliers work so hard to be the place that evaluation, tuning, storage and agent state live.

Commoditisation is drift, not competition

Here is the argument that reframes the whole subject. Commoditisation of model capability is usually attributed to competition — more entrants, so prices fall. That is a contributor and it is not the main mechanism.

The main mechanism is that your requirement is fixed and the frontier is not. Your task needs some capability level to be done acceptably. That level does not move: a support classifier that needed a certain quality in one year needs the same quality the next. Meanwhile the frontier advances, and each advance drags the cheap tier up behind it, because techniques that produced last year’s frontier become available to smaller and cheaper models.

Let q* be the capability your task requires.
Let n(t) be the number of models available at
capability >= q* at time t.

n(t) is non-decreasing and, historically, rising.

Your task is commoditised when n(t) is large.
Nothing about the market caused this. The frontier
moved and your requirement did not.

Two consequences fall straight out, and both are actionable. First, the rate at which your workload commoditises is a property of your task’s difficulty, not of the industry. An easy task is already commoditised; a task that only the very best model can do is not, and will be in some number of years. Second, being on the frontier is a permanently renting position rather than an owned one: whatever you are doing that requires the best available model will not require it indefinitely, and your product needs a reason to exist afterwards.

What a new tier does to the old tier’s price

When a materially more capable tier arrives, the older tier does not simply keep its customers at a lower price. Something more specific happens, and it is derivable from who leaves.

The customers who move up are those whose value from extra capability exceeds the price difference — which is, by definition, the least price-sensitive part of the old tier’s demand. What remains is the residual: buyers who chose the old tier precisely because of its price. A seller facing a more price-sensitive residual demand curve maximises revenue at a lower price than before.

Before the new tier:
  demand for tier N spans buyers who value capability
  highly and buyers who value price highly.

After tier N+1 arrives:
  the first group migrates upward.
  Remaining demand is more elastic.

More elastic demand -> lower profit-maximising price,
and the floor is the marginal cost of serving, which
for already-purchased hardware is close to energy.

So the price of tier N falls for two independent
reasons: cheaper to serve on displaced hardware, and
facing a more price-sensitive set of buyers.

This is why the arrival of a new frontier model is good news for a budget even if you never intend to use it. The thing you were already using gets cheaper, and the mechanism has nothing to do with generosity — it is what happens to any product line when the segment above it is created. The same dynamic explains where displaced accelerators go, which is covered in the capex and depreciation page.

What each side should do about it

• If you buy capability: spend on the evaluation suite before you spend on the migration. It converts a scary switch into a routine one, and it is the only asset here that appreciates.
• If you buy capability: re-test the cheap tier against your bar on a schedule. Commoditisation only pays the people who go and collect it; nothing reprices your traffic automatically.
• If you sell something built on models: assume the model is a commodity input on a horizon of a couple of years and ask what remains. If the answer is nothing, that is the finding, and the wrapper question is about exactly this.
• Either way: do not confuse commoditisation of capability with commoditisation of the whole stack. Serving at scale, distribution and trust are not on the same trajectory, which is the subject of where value gets captured.