Own The Data Loop

The moat moved twice, and most people still defend the first one

The piece opens by retiring its own earlier argument. The old claim was that value was migrating from the raw model to the harness — the scaffolding around a model that turns it into a working product (the prompts, the tools it can call, the retry logic, the memory). Now it goes further: the harness isn't the moat either.

What's left is the data. Not the training corpus everyone already scraped, but the exhaust your system produces while people use it: which answers got accepted, which got edited, which got overridden. That stream comes from users doing real work inside your product, and no vendor is watching it.

There's a name for the failure mode: data communism — everyone rents the same intelligence from the same three providers and therefore owns none of it. The blunter version is that enterprises are paying for tokens that create "no value" and quietly worry the labs will end up holding their alpha (the proprietary edge that makes a business theirs and not a competitor's). The essay is careful to flag the commercial interest of the person making that blunt claim — a fair-minded move worth remembering when the piece reaches its own citations.

Frontier models are for finding out, not for running

The practical split is the strongest part of the essay. Use the expensive frontier model when you don't yet know whether a capability is even possible, or on the hardest slice of the work. You get world-class reasoning without maintaining, securing or fine-tuning anything (fine-tuning = training an existing model further on your own examples so it gets better at your specific job and worse at everything else).

The cleanest example is a company doing both at once. It found product-market fit on frontier models for hard agentic coding, but its high-volume autocomplete runs on a model it trained in-house — because autocomplete has to come back in milliseconds thousands of times a day, and a model fine-tuned on that one job beats a general one that has to reason its way there.

The line that lands is that routing every step of an agent through a giant model is "architectural malpractice": you are "paying to send a 2KB message through a model that also knows Shakespeare and Python." Frontier for discovery, small and specialised for the hot path. Anyone who has put a database index on the one query that runs ten thousand times a day already knows this argument. It's the same instinct, applied to models.

The numbers are good, and every one comes from someone selling something

Two claims carry the economics. On speed, one support agent holds under 400ms p95 latency (how long the slowest 5% of requests take — the number that decides whether software feels alive or broken) at roughly 6x lower cost per turn than closed models, by fine-tuning small models for the job. On cost, a fine-tuned small model is reported at $3 per million requests against $6,241 for a frontier model, while still landing top-three of eight models tested.

Now read where those come from. The speed figure sits on a serving vendor's customer page, the cost figures on a distillation vendor's own blog, the inference-saving on another serving vendor's customer story. Every one of them sells the exact thing the piece recommends. The essay was scrupulous about naming one skeptic's incentive, then cited three vendors whose product is its own recommendation, without the same flag.

That doesn't make the numbers false. It does mean they are best cases, published by the people who produced them. And "top three of eight models tested" is doing quiet work: it is not "beat the frontier model," it is "close enough, on a narrow task, for a fraction of the money." Still a real result. A smaller one than the headline implies.

The flywheel: the one part that actually compounds

Here is the mechanism, worth reading slowly because it is the whole argument in four steps. A small model beats a frontier model on your task because it is fine-tuned on your data. Running it in production generates more data: corrections, edge cases, reasoning traces. That data fuels the next round of fine-tuning. Cost efficiency funds scale, scale generates data, data sharpens the model, a sharper model deepens the moat.

What makes this a flywheel (a loop where each turn makes the next turn easier, so advantage accumulates instead of resetting) rather than a cost-cutting exercise is the direction of travel. Cheaper inference is a one-off saving. A correction stream is an appreciating asset: every override a user makes is a labelled example of where the system was wrong, produced for free, by someone who knew the right answer.

The gap never addressed is volume, and volume is doing all the work. A flywheel needs turns. If your system runs a hundred times a month, the loop produces a trickle, and a trickle of corrections is a log, not a dataset. Quality goes unmentioned too: a loop that faithfully compounds bad corrections compounds error just as efficiently. The flywheel is a mechanism, not a guarantee, and the piece sells it as the latter.

Open weights are the ownership clause, and the bill is unpriced

The last move is the sharpest. You can fine-tune a closed model — the big labs sell that service — so why bother with open weights (models whose parameters are published, so you can download, modify and run them on your own machines with no per-call bill)? Because a fine-tuned closed model is still rented. "You're still renting compute, metered per token, exposed to their pricing and their kill switch." The framing: the difference between improving a rental and owning an asset.

The catch gets named and then dropped. Running your own models means owning the security and compliance for how proprietary data is stored and trained on. That is a far larger surface than calling an API, and very few teams can fine-tune, serve and maintain these models well. It's called "a real constraint we are monitoring," and the piece moves on.

So the $3-versus-$6,241 comparison is inference cost against inference cost, with the training run, the serving infrastructure, the ops burden and the compliance surface all sitting outside the frame. The honest figure is total cost of ownership, and it never appears. Which is the tell that this is a thesis written by an investor: the argument that a data loop is ownable by a startup is also the argument that the portfolio is defensible.

Vocabulary

• data flywheel (data loop) — A loop where using the system produces data that makes the next version better.
• harness — The scaffolding around a model — prompts, tools, memory — that makes it a product.
• fine-tuning — Training an existing model further on your own examples so it excels at one job.
• open weights — A model whose parameters are published, so you can run it yourself, no per-call bill.
• p95 latency — How long the slowest 5% of requests take; the number users actually feel.
• TCO (total cost of ownership) — The whole bill — training, serving, ops, compliance — not just the per-call price.
• alpha — Finance term: the proprietary edge that makes your returns yours, not the market's.

If you're building — what to watch for

• Keep the corrections. Every time a human edits, rejects or overrides an AI output, that is a free labelled example of a failure — and most systems throw it away. Log it before you know what you will do with it.
• Split model calls by job, not by habit. The rare, hard, exploratory call earns the expensive model. The one that fires ten thousand times a day usually does not, and that is where the bill actually lives.
• A flywheel needs turns. Below a certain usage volume a correction stream is a log, not a dataset — so if you are pre-traction, capture the signal and hold off building a fine-tuning pipeline around it.
• Before moving off a rented model, price the whole bill. Inference cost is the visible number; the training run, the serving infrastructure, the ops burden and the compliance surface of holding your own training data are the ones that decide it.
• Volume is not quality. A loop that faithfully compounds bad corrections compounds error at the same rate — build the check on the correction before you build the loop around it.

Reading it critically

• Every economic citation is a vendor case study — serving vendors and a distillation vendor, each selling the exact thing the piece recommends. It flags one skeptic's commercial incentive and never flags its own sources'.
• The $3 vs $6,241 figure is inference cost only. Training, serving, ops and compliance — the constraint it names itself — go unpriced. The real comparison is total cost of ownership.
• "Top three of eight models tested" is not "beats the frontier model." It's "close enough on a narrow task," a smaller and more useful claim than the headline.
• The flywheel needs volume to turn. Below some usage floor a correction stream is a log, not a dataset, and that floor is never named.
• The author is an investor writing a thesis. An argument that says the moat is ownable by startups is also an argument that the portfolio is defensible.