What Remains When the Model Is Gone
Everyone builds it the same way around. The frontier model at the center, a local model as a stopgap behind it. If the provider fails — blocked, priced out, discontinued — the weaker model steps in, and quality drops noticeably. You have a fallback, but one you dread.
What if the direction is backwards?
Flip the dependency around: the local model is the foundation, the frontier model the teacher. It doesn’t run in production — it makes the local model better. If it disappears, you don’t lose the foundation, only what went beyond it. Not a crash, but a standstill at the level already reached. That’s a fundamentally different risk profile — and it’s the difference between an architecture a company can take responsibility for and one it only permits itself as long as everything goes well.
The problem isn’t the AI, it’s the dependency
The blocking of Fable rightly caused unease. Not because the model would be irreplaceable, but because of the lesson: a production system standing on infrastructure that can vanish overnight has a single point of failure that no technical redundancy covers. That’s not an AI problem, it’s an architectural error — the same one you wouldn’t let slide with a database provider that has no exit strategy either.
On top of that comes the point that gets discussed less often: the cost per token. Irrelevant for occasional use; for an agent system that processes thousands of tickets a month, the difference between a viable business case and an expensive experiment. Both problems — availability and cost — point in the same direction: away from permanent dependence on the frontier model, toward something you operate yourself.
What a local model can really learn
The next tier is a deliberately less capable AI — say a Qwen model — that you host yourself, in a European data center, under your own control. The frontier model stays in play, but in a different role: it corrects the results of the local model, and those corrections become training material. The local model learns to adopt the patterns of the stronger one.
Does that work? Partly — and the place where it works can be named precisely. A small model cannot learn beyond its own capacity; it simply has fewer parameters and therefore an upper limit on what it can represent. What training can certainly do is concentrate that capacity. A frontier model spreads its ability across thousands of domains. If you only need a narrow slice — your kind of tasks, your style, your conventions — then that slice no longer has to compete with a thousand others for the limited parameters. On this narrow, recurring distribution, the small model can come surprisingly close to the large one, sometimes indistinguishably so.
So the narrowing shifts the boundary — it doesn’t erase it. What it shifts is breadth: many similar tasks instead of all tasks. What it shifts only with difficulty is depth: a single task that demands genuine multi-step reasoning over implicit context stays hard — multi-step reasoning can be distilled to some degree, but nowhere near as reliably as structured routine. Structured, clearly delineated work distills well. Penetrating a grown, under-documented codebase remains the preserve of the stronger model.
From this follows the honest, robust statement — and it is stronger than a blanket promise precisely because it names its own limit. The work splits into two parts: the distillable one — structured, recurring, clearly delineated — and the hard remainder that demands genuine penetration. The first part the local model can take over, and with typical enterprise workloads it’s the larger one. The second stays with the frontier model. If it disappears, the part taken over remains stable and reproducible — the model has it in its weights and doesn’t forget it when the teacher leaves. What disappears is not what was achieved, but the ability to still handle the hard remainder and to keep learning.
The dependency therefore doesn’t vanish overnight — it declines by design. The longer the teacher has taught, the more the local model carries on its own. This is not a stopgap you hide in embarrassment. It’s an architecture in which the expensive, foreign model works itself, piece by piece, out of the critical path.
One caveat belongs here, in honesty: this teacher mechanism lives on using the frontier model’s outputs as training material — and that is exactly what some providers prohibit in their terms of service once the goal is to train a competing model. Whoever builds their head start on distillates whose creation is contractually forbidden merely trades a technical dependency for a legal one. The licensing situation is therefore part of the architecture, not a footnote: you need a model with clear usage rights for precisely this purpose — they exist — instead of relying on a gray area that quietly rebuilds the same single point of failure through the back door.
The excavator needs a driver
Frontier models create the impression that they can work autonomously — as if human oversight were a transitional phenomenon that vanishes with the next model generation. That’s a fallacy, and not a technical one but a categorical one.
Picture an excavator. With it, a single person moves loads they could never lift by hand. The machine provides the force, the human steers — and bears responsibility. No one would think of leaving out the driver because the hydraulics are strong enough. The stronger the machine, the more important the one who decides what that force is used for.
With AI it’s exactly the same, but with a difference you must not overlook: the excavator fails visibly. If the arm doesn’t grip, the driver sees it immediately. AI fails differently — it produces plausible, good-looking output that is wrong. A force multiplier with clouded feedback multiplies the errors too, until someone notices them. From this follows the actual engineering task: the human can only steer what they can see. With the excavator this visibility is free — physical reality. With AI you have to build it.
That is exactly what the infrastructure delivers that belongs to any serious system anyway: traceable, bounded units of work instead of one large, inscrutable effort; automatic checks that make part of the failure visible immediately; a chain of responsibility that records who approved what and when. This isn’t bureaucracy imposed on the AI. It’s what enables the human to be the driver in the first place, and not a passenger.
That’s also why the human’s place doesn’t simply disappear when the models get better — even though the opposite is being pursued in many places right now. People are being replaced, on a large scale, and part of that is justified: where a task is narrow, repeatable, and automatically verifiable, the machine rightly takes it over. The error lies elsewhere — where replacement happens because the AI is believed to be autonomous, at points where judgment and responsibility matter. There it isn’t an activity that disappears, it’s a responsibility that’s orphaned. It doesn’t show immediately, because AI failure looks plausible — but it does show, and then the one who should have seen it and borne it is missing.
Responsibility is something a machine cannot take on; only a human can. The more capable the tool, the higher the value of the one who wields it and answers for it. Whoever rationalizes that away doesn’t save a position — they build a system that, at the decisive moment, has no one to stand behind it. Oversight doesn’t get cheaper as the AI gets stronger. It gets more expensive.
The light at the end of the tunnel: your own pond
That leaves the question hanging in the room: isn’t this all just damage control? An admission that you’ve missed the boat and are now settling for second best?
No — and that’s the actual point.
It’s not about swimming in the same pond against bigger fish — against models built with billions of dollars in compute and a talent pool that sits elsewhere. That race is decided, and saying so honestly is not defeatism but the precondition for seeing the right race at all.
Because the value creation isn’t in the model at all. The frontier model is the excavator’s hydraulics — you buy those in, no one rebuilds them themselves. What’s valuable and defensible is what you build with them: the pipeline that shapes a local model out of the teacher’s corrections; the inspection layer that makes failure visible; the auditability; the domain knowledge in versioned, inspectable documents instead of opaque weights; the integration into real, regulated enterprise processes. That’s engineering work. And at that, this country was never bad.
Your own pond isn’t smaller — it’s different. It’s called: AI systems that a regulated company can actually take responsibility for. In your own data center, with no shutdown risk, with the human at the lever, with traceable decisions and a cost structure that supports a business case instead of devouring it. In this pond, the frontier labs’ core business isn’t located — they do increasingly offer fine-tuning, distillation, and enterprise deals, but their focus remains the horizontal model, not the vertical, independently operable system that a single regulated company owns and answers for. The pond isn’t empty. It’s just not yet occupied.
And there’s a side effect that is more than a side effect. Whoever operates, adapts, and evaluates a local model and embeds it into an inspection pipeline understands how these systems work — in a way that merely consuming a foreign interface never conveys. You don’t learn to cook by reheating ready meals. The know-how built up isn’t the by-product of the exercise, it’s the actual gain: the ability to exercise judgment and not be held hostage.
This is not a catch-up chase. It’s the better position. While the pure interface users pay the full price and bear the full dependency, the frontier labs — through the teacher mechanism — work for whoever masters the architecture. As their model gets better, your own distillate gets better too. You’re not panting along behind — you take the others’ head start as raw material and refine it into something you own and answer for.