What is AI model lock-in?
AI model lock-in describes an application that can no longer change model without a rewrite. The model identifier, the expected response format and prompt-specific quirks are scattered through business code, so moving to a newer version takes the shape of a project to fund, settled in the next budget cycle.
On 30 July 2026, OpenAI cut the price of Luna, the cheapest model in its GPT-5.6 range, by 80% (OpenAI announcement reported the same day by CNBC), and applications already calling Luna benefited without a line of code moving. On 10 August, Anthropic made the Claude Sonnet 5 introductory rate its standard rate, dropping the increase planned for 1 September, so applications already on Sonnet 5 keep that rate without changing anything. Claude Opus 5, released on 24 July under an identifier nobody was calling yet, only reaches applications ready to switch identifier, and that is where architecture comes in.
The coupling stays invisible while the provider stands still. It surfaces the day a version is deprecated, or when a more capable model ships under a different identifier. In 2026, both happen several times a year.
The term covers two distinct situations. Provider lock-in comes from contracts, hosting and tooling. Model lock-in comes from the way code calls one specific version, and it is the harder of the two to spot in an architecture review, because it lives in application code rather than in diagrams.
What does an application frozen on a model identifier lose?
An application frozen on one identifier only benefits from price cuts applied to that identifier, as with Luna. New versions require switching identifier, with their capability gains and sometimes lower rates, and a frozen application sees none of it.
Capability gains arrive under a new identifier
Claude Opus 5 shipped on 24 July 2026 at the Opus 4.8 rate, $5 per million input tokens and $25 per million output tokens (Anthropic announcement of 24 July 2026), with a higher capability level, and became the default model on Anthropic’s Claude Max plan. An application calling claude-opus-4-8 pays exactly what it paid before, and will never see any of that generation. The gap shows on price too: an application still on Claude Sonnet 4.5 pays $3 per million input tokens and $15 per million output tokens, while Claude Sonnet 5 is billed at $2 and $10 (Anthropic public pricing, checked on 16 September 2026). The real saving has to be measured on your own volumes, because Sonnet 5 uses the newer tokenizer described below.
Token prices moving in opposite directions
The Luna cut describes no general trend either. In its 15 September 2026 update (methodology v1.1, page checked on 16 September 2026), BenchLM’s Token Price Index, which tracks 40 models across three tiers, puts the frontier tier up 72% year over year, the budget tier up 7.4% and the mid-tier down 7.7%, with Claude Sonnet 5 counted at $2 and $10 per million tokens. Prices follow different slopes from one tier to the next, and the automatic catch-up only applies to the identifier that got the cut.
At the top of the range, Claude Fable 5.1, released on 1 September 2026, keeps Claude Fable 5’s rates of $10 per million input tokens and $50 per million output tokens, twice the blended Opus 5 rate. On the price list, only cache reads got cheaper, at $0.25 per million against $1 on Fable 5 (Anthropic public pricing, checked on 16 September 2026), and that saving is also reserved for applications calling the new identifier.
Version deprecation and retirement dates
The other deadline is harsher. Anthropic retired six versions from its API between February and August 2026, from Claude Sonnet 3.7 and Claude Haiku 3.5 in February to Claude Opus 4.1 in August, and a request to a retired model fails. Anthropic commits to at least sixty days’ notice before retiring a publicly released model, so an active version can disappear as soon as two months after its retirement is announced. As of 16 September 2026, the Claude documentation gave each active version a floor date before which it will not be retired: 29 September 2026 for Claude Sonnet 4.5.
An application delivered in spring is already running on a previous generation, and nobody can price the switch: engineering does not propose one, and the decision slides to the next budget cycle. Take, as an illustration, a claims triage agent shipped in March on Claude Sonnet 4.5: it may well be working fine today, yet once that version’s retirement is announced, the team may have as little as two months to rewrite its prompts, revalidate its outputs and redeploy it.
Where does coupling hide in an AI application?
Coupling sits in implementation details that are rarely documented: how the identifier is written, how prompts are tuned and how responses are parsed.
Hard-coded identifiers and their copies
A model name written into a service’s code is rarely alone: the same string turns up in a batch script, an analysis notebook, a scheduled job or the settings of an automation tool. Each copy is one more place to change on switch day, and the copy you miss keeps calling the old version until it is retired.
Prompts tuned to one version
A prompt refined on one version carries the marks of its weaknesses: repeated instructions to stabilise a format, examples picked to steer around a recurring error, length constraints. On a newer version those patches become useless and sometimes counterproductive, and an inherited prompt can hold back a more capable model. Reading the migration guides Anthropic publishes for its latest models avoids carrying over instructions that no longer serve any purpose.
Response parsing and call parameters
The code that reads a response often expects an exact structure, such as a field in a given place. A newer model that phrases things differently breaks that parser quietly, and the error only shows up downstream, in a wrong dashboard figure. Call parameters raise the same issue: on Claude Opus 4.7 and later models, Anthropic’s API returns an error when temperature, top_p or top_k are set to a non-default value (Claude documentation, checked on 16 September 2026).
How do you know your architecture is coupled to one model?
A handful of questions is enough to locate the coupling. The healthy position is a single configuration file, switching without redeploying, an evaluation set, per-use-case measurement and a named decision owner, and every gap from that position makes changing model more expensive.
- How many files contain a model identifier? Beyond a single configuration file, you are coupled.
- Can you move one use case to a different version without redeploying the application?
- Do you have an evaluation set that replays your real cases against a candidate model?
- Do you know consumption per use case, or only the monthly invoice?
- Who decides on a model change, and against which written criteria?
Who decides on a model change
The last question is the only one on the list that cannot be settled in code. Where nobody owns it, the model in production is still the one picked by the team that shipped the first prototype, and that choice has never been reopened. We advise handing that decision to engineering leadership, against a written grid reviewed on a fixed cadence.
What does a model abstraction layer do?
The abstraction layer is a single point of passage between your applications and the models. Its job is to decouple, route, measure and govern AI calls.
Decoupling business code from the model name
Business code calls a capability, say “summarise a claims file”, and the mapping between that capability and a model lives in versioned configuration. Changing model then means editing one reviewed line, with a history and a rollback path, like any other infrastructure setting.
Routing each use case to the right model
Each use case goes to the model that fits it. Triaging inbound tickets and reviewing contracts do not demand the same reasoning depth, and a single provider’s range often covers the gap: Anthropic’s documentation points simple tasks to Haiku, most production workloads to Sonnet and the most complex reasoning to Opus.
Measuring at use-case level
Latency, failure rate, consumption and quality are attributed use case by use case, at the level where the trade-off is actually made. That measurement shows which use case costs too much for what it delivers and provides the baseline any future migration will need.
Governing from a single point
Logs, guardrails and approval trails sit in one place, which makes an inventory of AI systems maintainable. It is also where a supervision method such as LOOP™ applies, assigning each possible action of an agent to a trust zone, from autonomous execution to an immediate block. A model change alters how the agent behaves, so the zones assigned to its actions are worth reviewing before it goes back into production.
The AI system inventory and Article 50 of the EU AI Act
That last function carries a regulatory deadline. Article 50 of the EU AI Act has applied since 2 August 2026: a system designed to interact with people must tell them they are dealing with an AI, and providers of generative systems must mark generated content in a machine-readable format. For that article, the Digital Omnibus on AI, in force since 27 July 2026, allowed only one grace period, limited to the marking obligation (Article 50(2)), according to the European Commission’s quick facts on transparency rules (29 July 2026): providers whose system was placed on the market before 2 August 2026 have until 2 December 2026 to comply (Commission FAQ of 24 July 2026).
To find the systems concerned, an inventory showing which system runs on which model is a practical tool, and the abstraction layer keeps that inventory current without extra investigation. According to Deloitte (State of AI in the Enterprise, 2026 edition), only 21% of enterprises have mature governance of their agents.
Does this mean going multi-provider?
No. Multi-provider is a means, sometimes useful, often expensive in skills and tooling: every provider you add brings its own evaluation harness, prompts, supervision and security review. Committing to a reference model remains a defensible architectural decision, with one evaluation harness to maintain and one learning curve to fund.
Koneetiv works exclusively on Claude, and the switches described above, from Opus 4.8 to Opus 5 or from Sonnet 4.5 to Sonnet 5, all happen within a single range. For us, choosing Claude as the foundation goes hand in hand with versioned configuration, where the model identifier appears in one place only. Versioned configuration leaves you free to reopen the decision at a moment of your choosing.
The risk of an abstraction that levels everything down
A badly designed abstraction carries its own risk: it levels everything down. If your layer only exposes what every provider has in common, you lose whatever made you pick that model, such as long-context handling or structured tool calls. A useful layer exposes the advanced capabilities and documents the ones that are not portable.
Which mistakes make a model migration expensive?
A migration gets expensive when the candidate is evaluated on demo cases, when rates are compared instead of consumption, or when all traffic switches at once.
Evaluating on demo cases
A candidate model tested on the examples used to sell the project will pass. The evaluation set has to replay real production cases, anonymised, with their edge cases and the errors already fixed, and it has to set in advance the quality threshold that authorises the switch. Without that written threshold, the decision is made on impression.
Comparing rates instead of consumption
The rate per million tokens does not give you the cost of a use case. Two models at the same rate can consume very different volumes for the same task, depending on response length, extended thinking and tokenisation: Anthropic’s documentation states that Claude models from version 4.7 onwards use a newer tokenizer, which produces more tokens for the same text. Only a measurement on your own cases tells you whether the switch costs more or less.
Switching all traffic at once
A safe switch goes in stages: the candidate model first runs in shadow mode on live traffic, with its answers left unused, then takes a fraction of the traffic, then all of it if the indicators hold. Rollback has to remain possible at every stage, which assumes the old version is still available, and a migration started after a retirement notice runs against the clock.
Where should you start?
With an inventory, which is a short exercise once you know where to look. List the AI applications running in production, the model each one uses, and the date that choice was last reviewed. For Claude API traffic, the Claude Console lets you export usage broken down by API key and by model, which gives a first list of the identifiers still being called (Claude documentation, checked on 16 September 2026). The inventory can surface forgotten use cases, or applications running on a version the team would no longer pick today.
Lifting the model identifier out of your most critical application
Then lift the model identifier out of the code on your single most critical application, and build the evaluation set that will tell you whether a candidate performs as well on your own data. S&P Global reported in 2025 that 46% of AI proofs of concept were abandoned before production. In our view, clearing that bar means treating AI as an architectural component, held to the same reversibility standards as your core systems, and deciding your AI agent architecture against written criteria.
To see where your organisation stands, the AI maturity assessment scores six axes in three minutes, including technical foundations and governance, using the Koneetiv framework (2026 edition).
Our page on AI agents in the enterprise covers the technical building blocks of an agent and its governance in production.
To industrialise your agents, our Claude agent deployment and operations programme runs from technical audit to agents in production.
The other articles in the AI agents in production section take these architecture questions further.