You Built a Swappable Model Layer. Your Cache Just Locked It Back In.

The cheapest way to run AI agents is now also the stickiest, and most second-source plans don't have a line for it. Agent workloads resend enormous context on every call, the system prompt, the tool definitions, the documents, the conversation so far. Providers price a cached re-read of that context at a steep discount against a fresh one, commonly a tenth of the input rate and on some tiers far less. So teams do the rational thing and design the whole workload around one provider's caching scheme. Then they discover the switching cost moved. It isn't in the weights anymore. It's in the context layout, and leaving means re-paying for every active context at the full rate while you redesign it for someone else's cache. We call that exit cost the cache mortgage. You pay a context down once and ride cheap thereafter. Moving means refinancing.

What is the cache mortgage?

It's the bill for leaving a provider whose cache your agents were built around, and it's missing from almost every switching-cost model.

The cache mortgage is the sum of two things. The first is a one-time re-prefill of every live context at the uncached rate, because the new provider has never seen any of it. The second is the engineering to lay your context out the way the new provider's cache wants, since cache behavior differs by vendor in what gets cached, how long it lives, what breaks it, and what it costs to write. Neither is catastrophic. Both are real, and neither shows up when a team estimates what it would take to switch, because the estimate was built for a world where the model was the dependency. We've argued for a long time that swap-ready architecture turns a model change into a config change. That's still true at the model socket. The mortgage sits one layer down, in how the socket is fed.

Why did the cache become the lock-in?

Because agent workloads are input-heavy, and on input-heavy work the cache discount decides more of the bill than the model does.

Think about what an agent actually sends. A human chat turn is a sentence against a short history. An agent turn is the same two hundred pages of standing context against one new tool result, dozens of times per task. Most of the compute on a call like that goes to reading the input, not writing the answer, which is why providers can discount a cache hit so aggressively and why a workload with a high hit rate costs a fraction of the same workload cold. The spread between a miss and a hit on one provider ran past a hundredfold earlier this summer before being repriced to a merely large multiple. When the discount is that steep, the practical advice going around engineering teams is to design agents cache-first around a single provider, and the advice is correct on the invoice. It also builds the mortgage. Every optimization that raises your hit rate on one vendor raises the cost of the day you leave.

Doesn't a swap-ready architecture already handle this?

No. The socket keeps the model replaceable. It says nothing about whether the context on the other side of the socket is portable.

Here's the distinction that matters. Swap-ready architecture puts a boundary between your workflows and any one vendor so the model is a guest. The cache mortgage is about the shape of what you hand the guest. If your prompts, tool schemas, and document ordering are arranged to maximize one provider's cache behavior, the boundary still works, and the first month on the new provider costs multiples of what you budgeted while the contexts rebuild and the layout gets reworked. It's a close cousin of rented optionality, where the flexibility you thought you held turns out to be leased from the vendor you wanted flexibility from. No portability standard for cached context exists. Nobody has even proposed one. Until that changes, this cost grows by default as context sizes grow, and context sizes only move one direction.

Is self-hosting the way out?

Partly, and it got more expensive this year for a reason most finance teams haven't connected to AI yet.

Hosting an open-weight model inside your own walls removes the vendor's cache pricing from the equation, and that's a real rung on the control ladder. It doesn't remove the physics. A cache is memory, and memory is the component whose price went the wrong way in 2026 while tokens kept getting cheaper. Data-center demand pulled wafer capacity toward the high-bandwidth memory that frontier training wants, and ordinary DRAM, the kind a self-hosted inference box runs its working set on, got scarce and expensive as a side effect. So the two curves crossed. Rented inference per token fell. The hardware cost of running your own cache rose. That doesn't kill the self-host case, it just means the case has to be made on the cache math and not only on the per-token math, and the teams that climb the ladder on last year's hardware quotes will be surprised.

What's the one lever the customer fully controls?

What goes into the context, and in what order. That discipline now has a name, context engineering, and it's worth more than model selection on most agent workloads.

Vendors control the cache price. They control the hit discount, the time-to-live, and the write fee. The customer controls one thing, and it's the thing that drives the bill. A context laid out so the stable material sits first and the volatile material sits last will hit the cache on every turn. A context that interleaves a timestamp into the system prompt will miss on every turn and pay full freight. Same model, same vendor, same task, a very different invoice. This is also where the mortgage gets cheaper to carry. A context designed with a stable prefix and volatile suffix is portable in principle, because every provider's cache rewards the same shape even when the specifics differ. The teams paying the most for their cache are usually the ones who never looked at what they were resending, which is the same oversight we described in the frontier freeze, one layer deeper. The sorting there was by task. The sorting here is by what inside the task changes.

How should the mortgage change your vendor planning?

Price the exit before you take the discount, and keep one lane cold on purpose.

The question you're really asking is whether you can take the cache discount without taking the lock-in. You can, mostly, and the answer has a shape. First, put a number on the mortgage for each production agent. Count the live contexts, multiply by the uncached rate, add an engineering estimate for the layout rework, and write it next to the vendor's name in the same document where you keep the crossfire exposure. A cost you've written down is a cost you can decide about. Second, design context for portability first and hit rate second. Stable prefix, volatile suffix, no provider-specific tricks in the layout that a competitor's cache would punish. You'll give up a few points of hit rate and keep the ability to move. Third, keep one workload running warm on a second provider or an open-weight floor at all times, not as a disaster plan but as a running measurement of what the refinance would actually cost. The teams that do this treat the cache discount as what it is, a rent reduction with a lease attached. The teams that don't will find out the lease terms the week they try to leave.

If you want your agent contexts laid out so the discount is yours and the exit is priced, start with an AI Blueprint or reach us at contact@theyor.com