---
title: "Models Below the Frontier Are Commodities"
slug: "chapter-5-models-below-the-frontier-are-commodities"
kind: "chapter"
order: 6
label: "Chapter 5"
chapter: 5
part: "The Model Layer"
partLabel: "Part II"
partNumber: 2
epigraph: "The frontier is where the headlines are. The work is done a few months behind it, at a hundredth of the price."
summary: "Every quarter a new model arrives that is, by some benchmark, the best in the world. The announcement is covered as if it mattered to the institution running an advising assistant or a contract-rev…"
words: 1117
topics:
  - "What the frontier is for"
  - "The six-month rule"
  - "Pricing power and where it goes"
  - "The design consequence"
  - "How to test the claim in your own house"
---

Every quarter a new model arrives that is, by some benchmark, the best in the world. The announcement is covered as if it mattered to the institution running an advising assistant or a contract-review agent. Usually it does not. This chapter is about why, and about the single architectural decision that follows from it.

## What the frontier is for

Frontier models earn their name by doing things that were previously impossible: long multi-step reasoning, research-grade synthesis, code that compiles on the first try across an unfamiliar codebase. A small number of workloads in any institution genuinely need that. A research group pushing on a hard problem. An engineering team using an agent to refactor a system. A one-off analysis where the cost of being wrong is high and the volume is low.

The overwhelming majority of institutional AI work is not that. It is answering a student's question about a degree requirement from a document the institution already has. It is drafting a first version of a letter. It is extracting fields from a form, summarizing a meeting, classifying a ticket, translating a page. These tasks were solved, to a standard most people cannot distinguish from the frontier, by models that are now two or three generations old. The frontier matters to them only in the sense that it keeps pushing the floor upward.

## The six-month rule

A rule of thumb has held for several years now and shows no sign of breaking: whatever the best model can do today, a model costing a tenth as much will do adequately in about six months, and an open-weight model you can run on your own hardware will do adequately in about a year.

The mechanism is competitive. There are now at least a dozen serious model developers, commercial and open, and each new capability is matched by the others within months. Prices for a given level of capability have fallen by roughly an order of magnitude a year since 2023. Open-weight releases from Meta, Mistral, DeepSeek, Qwen and others have repeatedly reached the capability of commercial models from a year earlier, and they can be downloaded and run by anyone with the hardware.

For a CIO the consequence is that the question "which model should we standardize on" is malformed. Any answer is wrong within two quarters. The right question is "how do we make sure we can use whichever model is good enough and cheapest for each task, as that changes."

## Pricing power and where it goes

When a model is a commodity, pricing power leaves the model and moves to whoever controls the interface to the user. That is the economic logic behind every per-seat AI product. The vendor buys tokens at commodity prices, or trains its own model, and sells access to it at a price unrelated to token cost, because the institution is not buying tokens. It is buying a chat window, a set of connectors, an identity store and a brand, and the model inside is interchangeable.

Follow the money and the lesson is plain. If the institution owns the interface, the connectors and the identity store, then the institution captures the falling price of models. Every time a cheaper or better model appears, the institution's bill goes down or its capability goes up, by changing a setting. If the vendor owns those things, the vendor captures the savings and the institution's bill stays flat.

This is not a small effect. An institution paying a per-seat price negotiated in 2024 is, in 2026, paying for a model that costs the vendor a small fraction of what it cost two years earlier, at the same price. The difference is margin. A sovereign deployment, paying providers directly, would have seen most of that decline on its own invoice.

## The design consequence

The architecture that captures commodity pricing has one rule: the model is a setting, not a dependency.

Every call to a language model passes through one interface inside the platform. That interface speaks a standard request format, which almost every commercial provider and every mainstream open-weight inference engine now accepts. Prompts are written against that interface, not against a specific model's quirks. The provider, the model name, the endpoint and the credentials are configuration values an administrator can change for the whole platform, for one agent, or for one class of request, without touching code.

Three practices make the rule real rather than nominal.

The platform maintains a catalogue of available models with their prices, context limits and capabilities, refreshed from the providers, so an administrator chooses from facts rather than memory. Each agent carries an evaluation set, a few dozen representative prompts with expected properties of a good answer, that can be run against any model on demand. And the default model for routine work is chosen deliberately as the cheapest one that passes the evaluations, with the frontier reserved for the agents that have shown they need it.

A platform built this way treats a new model release the way a procurement office treats a new supplier quote: run the evaluations, compare the price, switch if it wins. A platform built around one provider treats a new release as news.

## How to test the claim in your own house

A CIO does not have to take the commodity argument on faith. It can be tested in a week with the institution's own workloads.

Take the three agents or use cases that generate the most volume. Collect fifty real prompts for each, with the answers people considered good. Run those prompts through the frontier model the institution is using or being sold, through a model one generation older from the same provider, through the cheapest capable commercial model from a different provider, and through a leading open-weight model served on a rented GPU. Have the people who own the use case grade the answers blind.

In my experience the result is consistent: for routine institutional work, the graders cannot reliably tell the frontier from the tier below it, and the open-weight model is acceptable for most tasks and clearly worse on a few. The price difference across the four is typically fifty to a hundred times.

That exercise does two things. It tells the institution what it actually needs, which is usually less than it is being sold. And it produces the evaluation set that makes model switching a routine operation thereafter. An institution that has done it once is in a different negotiating position with every vendor it meets, because it knows what the model inside is worth.

The next chapter is about what to do with that knowledge: routing among models continuously, rather than choosing one.