AI Model Dependency Is the New Vendor Lock-In
You didn't choose one AI model. You got locked into one. Here's the dependency draining your build budget, and how to make any model a swappable, low-cost part.
Two years ago the smart move was obvious: point your code at the best frontier model you could get an API key for, and ship. It worked. It still works, right up until the day the price changes or the model disappears. Most teams built this way, including very good ones, and most are now carrying a form of vendor lock-in they never wrote down.
But "AI model dependency" isn't one problem. It's two, and they don't behave the same way. It's worth separating them before you decide how exposed you actually are.
Two kinds of dependency
The first is AI inside your product: features your customers use that call a model in production. Here, switching models is genuinely expensive. You've tuned prompts to one model's quirks, built evals around its behavior, and wired up observability to watch it in the wild. When that model gets deprecated or repriced, you re-engineer and re-test all of it under a deadline someone else set. This is the dependency everyone talks about, and it's real.
The second is AI in how you build: your team using AI to write and ship software. Here, switching models should cost almost nothing. There's no production prompt to migrate, no eval suite tied to live user behavior. You change a setting and keep going.
The second one looks safe. It's where most teams bleed the most money.
The dependency nobody prices in
Here's the trap in AI-powered development. Switching models is easy, but teams don't switch, because only the expensive frontier model produces output they trust. So every feature, every fix, every refactor runs on premium tokens. The bill scales with your team's output, and it never stops.
That's still a dependency, just an economic one instead of a technical one. You're paying frontier prices because nothing cheaper has been made good enough on your codebase.
And the ground under the frontier is moving anyway. Model lifecycles have compressed from 18-to-24 months down to 6-to-12. The budget tier you lean on gets retired, and the sanctioned replacement can cost several times more. Your cost of building software now carries a variable another company sets.
Availability isn't only about deprecation, either. A model can vanish from your region overnight for reasons that have nothing to do with you. In June 2026, a US export-control directive forced Anthropic to suspend worldwide access to its just-launched Fable 5 model three days after release, with access restored only weeks later. Export controls, sanctions, and regional restrictions are now part of the risk surface. If a model gets cut off in your market while competitors elsewhere keep theirs, you are competing on an uneven field through no choice of your own.
Call it the frontier-model tax. Inside your product it shows up as a migration tax. In your development it shows up as a "quality only comes from the expensive model" tax. Most founders are paying the second one without knowing the rate.
The fix is the layer around the model
The way out of the development version is to build the layer around the model, so a cheaper one performs like a premium one.
For software development, that layer is a repo-specific harness. It carries the context a raw model doesn't have: how your codebase is structured, your conventions, the decisions already made. It runs an automated code reviewer over every change, so quality doesn't hinge on the model getting it right first try. It maintains a knowledge layer so the model isn't re-learning your system on every task.
With that in place, the model becomes what it should be: a swappable, low-cost commodity. You run the cheapest one that clears the bar, and you switch on your terms: when a better one ships, or when one gets restricted in your market. That is the opposite of lock-in.
We didn't assume this would work. We measured it.
The test: $0.73 vs $5.00 for the same feature
We took one real Jira story, a Knowledge Base feature with 9 acceptance criteria, and built it against the same production codebase: 750+ files, 430,000+ lines.
Running inside our repo harness, Kimi-2.6, a light model, shipped the feature for $0.73. It met all 9 acceptance criteria and passed the harness's automated code review.
For comparison, we ran the same feature on Opus 4.8, a top frontier model, without the harness. It also delivered the feature, for $5.00. Nearly 7x the cost for the same result.
The model wasn't the reason the cheap run held up. The harness was. Strip the infrastructure away and you are back to paying frontier prices for frontier-only quality.
This compounds. That 7x isn't a one-time saving on one ticket. The harness holds the quality bar on every task, so the cheap model stays viable across the whole backlog. It repeats on every story and every fix for the life of the project, and a per-ticket difference becomes a structural difference in what it costs you to build anything at all.
This isn't a benchmark we cooked up to make a point. It's how we ship. Zapbook went from patchy, hardcoded software to a full SaaS product with multi-tenancy, custom workflows, and advanced reporting: 12 modules and 9 production releases, delivered in 63 working days by 4 specialists and AI, roughly 4x faster than traditional development, at the same production quality.
Use the best model. Just don't need it.
None of this is an argument against frontier models. Use the best one available, on the work that's worth it. The mistake is building a team whose output only makes economic sense while one expensive model stays cheap and stays available.
Build the layer around the model, and the model goes back to being a choice you make every week, not a bill you can't put down. That's the whole difference between renting your AI stack and owning it.
We built model-agnostic AI infrastructure that delivers Opus-level output on lighter models. If you want to see what that looks like on your stack, let's talk.