Something changed this year in who actually gets the best AI. The newest frontier models aren't just expensive anymore; some have become hard to get at all. In June 2026, Anthropic released Fable 5, and a U.S. government export-control order forced it offline three days later, after a reported jailbreak of its safeguards; its sibling Mythos model was suspended at the same time. The same month, OpenAI previewed GPT-5.6 not to the public but to roughly twenty pre-approved organizations, vetted by the government under a new framework for clearing frontier models before release. While the frontier narrowed, the open-weight models kept climbing. GLM 5.2 shipped free, under an open license, landing within about a point of the top closed models on real work.
Put those two trends next to each other and an uncomfortable question falls out, one we keep landing on with the companies we talk to. If the newest frontier models are increasingly gated, released slowly and to a privileged few, sometimes withdrawn entirely, and the open models are now this good and this cheap, what is your AI strategy actually built on? Most companies aren't on a level playing field for frontier access; only a short list of vetted organizations gets the very newest models at all. Yet most are still paying frontier prices for the ones they can get, and, more quietly, wiring their whole operation around a single provider. That's the part worth slowing down on.
Quick answer: Cheap open models have broken the price of intelligence, but the next round of AI vendor lock-in won't happen at the model layer. It'll happen at the context layer. The durable, hard-to-replace asset isn't the model; it's the AI harness around it: your prompts, files, chat history, permissions, tools, accumulated memory, and workflows. Control that, and you can swap models freely. Don't, and you'll find the cheaper model exists but you can't actually reach it.
Step back and notice what those two trends have in common: the model layer is becoming something you control less. Which frontier model you can get, at what price, even whether it stays available, is increasingly decided by someone else: a vendor's roadmap, a government's security review, an export order written over a weekend. When the part you depend on is that unpredictable, the smart move is to tighten your grip on the part you can actually control. And the part you can control was never the model. It's everything around it: whether you can route work to a different model next quarter without rebuilding your whole operation. The more unstable the frontier gets, the more that freedom to switch is worth, and the more dangerous it is to have quietly wired yourself to a single provider.
So it's worth working through what actually changed, what didn't, and the one architecture decision most companies are about to make by accident.
Meanwhile, here come the open models
Start with the thing that's true. The open-weight models got good. Not "good enough if you squint," but genuinely good, and they got cheap at the same time. The one everyone has been passing around lately is GLM 5.2, an open-weight model you can download and run yourself. By published API rates it runs at roughly a sixth of the blended cost of a top closed model, and it's effectively free to run if you host the weights on your own hardware, while holding its own or winning on a large share of ordinary work. If you're standing up a routine internal tool, drafting first-pass copy, doing familiar synthesis, or writing code against a well-trodden problem, it's hard to argue you should be paying several times more for it.
The phrase a few people have used for that band of work is the "center of distribution": the fat middle of tasks where the pattern is common, the answer shape is predictable, and a human can eyeball the output in a few seconds. Most knowledge work, honestly, lives there. And in that band, the cheap models are not a compromise. They're often the better tool.
So the reaction writes itself. If a model that's a fraction of the price is as good for most of what I do, I'll build a router, send the bulk of my traffic to the cheap one, and keep the expensive model for the hard cases. Token costs fall off a cliff. Done.
Except almost nobody who tries this finds it that easy. Companies that obviously should be saving the money mostly aren't. The frontier vendors are still growing revenue at a pace that makes no sense if switching were a config change. That gap, between how easy the switch sounds and how rarely it happens, is the whole story. It's worth understanding before you make a decision you can't cheaply reverse.
Why you can't just switch the model
Here's the part the price comparison hides. When you move from one model to another, you are not swapping a single API call. You're replacing the entire system that made the model useful in the first place.
People in this space have started calling that system the AI harness, and it's the most useful word I've picked up all year. The model on its own is a brain in a jar. It's brilliant, and it's inert. What turns it into something your team relies on is everything wrapped around it: the prompts you've tuned, the files and documents it can reach, the chat history it remembers, the permission rules about who can ask it what, the tools it's wired into, the memory it's accumulated about how your work actually goes, and the review habits your people have built up around its output. That bundle is the product. The model is one swappable part inside it.
Once you see it that way, the switching math changes completely. The most honest public example I've seen is the Lindy team, led by Flo Crivello, who moved off Claude to a cheaper open model, DeepSeek, and wrote up the experience candidly. The headline wasn't "we flipped a setting and saved money." It was that the switch took a six-to-nine-month migration with significant prompt re-engineering. The prompts didn't carry over. The tool-calling behaved differently. The memory handling had to be redone. The payoff was real, and by their account inference costs fell by roughly 90%, but it came from rebuilding the system around the model, not from swapping the model. A cheaper model that's strong on common patterns is not the same animal as a frontier model, and it won't behave like a drop-in.
That work is real, and it's specialized. Knowing how a particular open model wants its tool calls structured, how its memory should be handled, how its system prompt has to shift because it's a center-of-distribution model. That's last-mile engineering, and the people who can do it well are scarce and expensive right now. Which produces a quiet irony: the intelligence got radically cheaper, but the labor to actually capture the savings did not. Plenty of companies will look at that trade, decide the rebuild isn't worth it this quarter, and stay on the frontier model. Not because the frontier model is the only thing that works, but because the harness they already have is wrapped around it, and rebuilding the harness costs more than the tokens they'd save.
That's a manageable problem when the harness is yours to rebuild. It becomes a different kind of problem when the harness isn't yours at all.
The warning sign: where your context goes to live
Watch where the frontier vendors are spending their attention, because it tells you where they think the next moat is. They are not only racing on raw model quality anymore. They're moving into the work surface: the place where a team's actual context lives.
The clearest example landed recently with Claude Tag, Anthropic's move to put Claude directly into Slack as something close to a team member. You add it to channels, connect it to your tools and data, and anyone can tag it to hand off work. It builds context from the channels it sits in, remembers what's relevant, and can carry tasks forward on its own. I want to be precise here, because this is genuinely good engineering and a genuinely useful product. Andrej Karpathy, who knows the difference, pushed back on people writing it off as a cute Slack bot and described it as something more like an org-level harness, a new way for a whole team to work alongside the model rather than a feature bolted onto a chat window. By Anthropic's own account, about 65% of one internal team's code now comes through their version of it. The thing works.
That's exactly why it's worth thinking about carefully, and not as a complaint about Anthropic. Put the model where the work happens and something subtle follows. The assistant doesn't just answer questions in a channel. It becomes the place where the channel's context accumulates. The half-decisions, the "here's why we did it that way," the tacit knowledge nobody ever writes into a system of record. All of it starts flowing through, and getting remembered by, a surface that one vendor operates.
We've told companies for decades that their data is their edge. If that's true, it's worth asking what it means to let your operating context (the live, messy, day-to-day memory of how your company actually works) accumulate inside a frontier provider's product. Even with an honest vendor and a clean privacy policy, even if none of it ever touches model training, you end up in a strange position. You're effectively renting back your own context, because the convenient place it now lives is a surface you don't control.
Here's the sharp version of the risk, and it's not the obvious one. The danger isn't that an assistant reads a Slack thread. The danger is that the assistant becomes where the company's working context lives. The day a cheaper, perfectly capable model arrives, you'll do the math and find you still can't move. Not because the open model is too weak, but because your workflows, your team's habits, and your accumulated context are all wrapped around one provider's harness. And the better that harness is, the tighter the wrap. Usefulness is the mechanism, not the exception. The most helpful version of this is the hardest one to walk away from.
What deliberate enterprise AI architecture actually looks like
None of this is an argument against using good tools, and it's definitely not "switch to open source and feel virtuous." Open models are part of the answer, but swapping one provider's lock-in for a different set of constraints isn't sovereignty. The move is to be deliberate about enterprise AI architecture instead of letting it assemble itself one convenient feature at a time. A few principles have held up for me.
Know which of your work is mainstream and which is frontier. This is the unglamorous, foundational step almost nobody does on purpose. Sit down and actually sort your AI workload: which tasks are common-pattern, high-volume, easy to check, and which are genuinely hard, ambiguous, or high-stakes. You can't route intelligently until you've drawn that line, and most teams have never drawn it.
Route the mainstream work to cheaper models, on purpose. Once you know which tasks live in the fat middle, those are the ones that belong on the cheap, fast, open models. That's where the savings are real and the quality cost is near zero. Treat it as a standing policy, not a one-off experiment you run and forget.
Reserve the premium models for the work that earns them. Frontier models are worth their price on the edge cases: the ambiguous calls, the high-risk output, the problems where being wrong is expensive. Pay up there without flinching. The goal isn't cheapest-everywhere. It's matching the cost of the intelligence to the stakes of the task.
Keep the parts that are actually yours outside any single provider. This is the load-bearing one. Your memory, your permission rules, and your workflow logic (the harness) should live in a layer you own, with the model as a component you plug into it, not the other way around. For a smaller team, that doesn't have to mean a full platform group; it can start as a thin routing-and-memory layer that logs prompts, permissions, source files, and model choices outside the vendor's surface. If your context only exists inside one vendor's product, you don't have an architecture. You have a dependency wearing an architecture's clothes. When the abstraction is yours, switching models is a Tuesday. When it isn't, switching models is a migration project you'll keep postponing.
Treat company context as infrastructure, with an owner and a plan. Your operating memory, how your company works and the decisions and reasons behind them, is a strategic asset. Decide on purpose where it accumulates, who can reach it, and how you'd get it back if you changed vendors tomorrow. That's not a tooling preference. It's the same category of decision as where your source code or your customer data lives, and it deserves the same seriousness.
I'd call the goal context sovereignty: the model is a part you can change, and the system around it is yours. That's the difference between an AI setup you operate and one that quietly operates you. Model routing is the tactic. Owning the harness is the point.
The mistake worth not making
So, back to where we started. The frontier is narrowing to a privileged few, the open models keep getting better and cheaper, and the easy instinct is to wait for the picture to clear. Wait for what, exactly? The intelligence is already cheap and getting cheaper, and frontier access isn't something most companies control anyway. Neither of those is the variable that should be holding you up. The thing worth deciding now, while it's still cheap to decide, is where your context is going to live.
Because the next expensive mistake in enterprise AI won't be overpaying for tokens. Token prices are falling on their own; that problem is solving itself. The mistake will be quieter and harder to undo. It'll be letting one provider become the place where the company brain lives, and then, the day you want to move, finding out what it costs to get your own memory back.
The cheap model is a gift. Take it. Just don't let the convenience decide your architecture for you. Decide it yourself, while it's still yours to decide.
