Your Cost Optimiser Has No Spending Limit. DigitalOcean Just Shipped One.

X-Routing-Max-Switch-Spend-Pct: 20. That header, shipped by DigitalOcean in its Inference Router and described in an announcement by Salman Paracha in August 2026, tells the router it may spend at most 20% above the baseline model cost on the accumulated consequences of switching models. Set it, and an automated optimiser that would have chased a cheaper sticker price now has to justify the move against a budget it can exhaust.

The control is small. What it represents is a buyer bounding an automated optimiser’s authority to act, expressed as a request header rather than as a line in a contract.

Why a Cheaper Model Can Cost More

The failure mode DigitalOcean describes is specific. A router optimising on per-token price switches models partway through a session. The new model has no warm prompt cache for that conversation, so the full accumulated context is reprocessed at uncached rates. The next turn pays for everything the previous model had already amortised.

The size of that penalty comes straight from the price sheet. DigitalOcean cites Claude Sonnet 5 at $2.5 per million input tokens against $0.2 per million cached tokens. A factor of 12.5 separates a cache hit from a cache miss on the same tokens. A router that saves any amount short of that 12.5x gap on the nominal price of the next model and discards a warm cache to do it has made the session more expensive, and the accounting that would show this sits in a different column from the one the router is watching.

Cache hit rates on real workloads are high enough to make this a live risk rather than a theoretical one. Z.ai reported 90.9% on coding workloads, per the DigitalOcean write-up, and DigitalOcean reports “90%+” across its own workloads. OpenAI, quoted in the same post, states that cached prompts “reduce latency by up to 80%”. Those are the conditions a mid-session switch throws away.

Two Headers, Two Different Jobs

The announcement describes two controls, and they are not variations on the same idea.

X-Model-Affinity binds requests to a session or task identifier so the router keeps related traffic on one model and one cache. Where the header is absent, DigitalOcean says the router infers a stable session key from request context. This is a correctness control. It answers “which requests belong together” and gives the router the grouping it needs to know what a switch would break.

X-Routing-Max-Switch-Spend-Pct is the economic control. It caps cumulative switching cost relative to baseline model cost, using the documented example of 20 for a 20% threshold. The router stays free to switch. It simply cannot switch past the point where the accumulated cost of switching exceeds what the caller authorised.

The second header is the interesting one because of what it takes as its subject. Its subject is the optimiser’s discretion. It leaves total spend and model choice alone, and puts a ceiling on how far the optimiser can go before its own optimising becomes the expense.

A Budget on Behaviour

A monthly ceiling on inference spend answers a finance question: how much can this cost in total. It says nothing about how the money was spent, and it fires after the damage. A per-switch cap answers a different question: how much authority does the automated component have to make a decision on my behalf before it has to stop.

That distinction matters because the decision volume is not human-scale. A router makes model-selection calls continuously while work executes. Reviewing them individually is not available to anyone. Setting a bound on their aggregate cost, expressed in the same unit the router is already optimising, is available, and it is enforceable at the request level rather than at the reconciliation.

This is the shape most agent-governance controls will eventually take. The thing being constrained is an automated agent’s licence to act, the constraint travels with the request, and the enforcement point is the runtime that would otherwise act unilaterally. Cost is simply the easiest dimension to express first, because it already has a number and a unit everyone agrees on.

Treat the Performance Numbers as Vendor Claims

The customer results in the announcement are DigitalOcean’s own or its customers’. Coinbase is reported to have improved its cache hit rate “from 5% to 60%”, and LawVo to have reduced inference costs “by more than 40%”. Neither figure comes from independent measurement, and neither tells you what your workload would do, since the whole mechanism depends on how much context your sessions accumulate and how often your router would have switched.

What survives the announcement is the two header names and the semantics attached to them, verifiable from the documentation whether or not any customer’s number holds up. A header that exists can be requested from other vendors. A case study cannot.

What To Do Now

Ask your inference vendor one question. “What bounds the cost of a routing decision your optimiser makes on my behalf, and can I set that bound per request?” A vendor with an answer names a control. A vendor without one is routing on sticker price and reporting savings in a unit that excludes the penalty.

Separate the two controls when you ask. Session affinity and switch-cost caps solve different problems, and a vendor may have one without the other. Affinity without a spend cap keeps sessions coherent while leaving the optimiser’s budget unbounded. A cap without affinity bounds spending on a grouping the router guessed at.

Measure your own cached-token ratio before tuning anything. The value of any of this scales with how much of your input is normally served from cache. If your sessions are short and your prompts do not repeat, a switch costs you little and the header buys you little. If a large share of your input tokens are cached today, a router free to switch is a live cost risk you currently cannot see.

Log the switches alongside the totals. A per-request cap you cannot observe being hit is only a setting. Ask what telemetry exists for routing decisions and switch-cost accumulation, and treat the unobservable portion as an attribution risk rather than as zero.

Cost governance already moved into the runtime, and cache economics already became a per-provider policy question. What is new here is a knob the buyer holds. Ask for it by name, and when the next class of automated decision arrives with its own optimiser, ask what bounds that one too. The pattern generalises well beyond variance in a monthly bill.

---

This analysis synthesizes The cheapest model isn’t always the best deal: cache-aware routing in the Inference Router (DigitalOcean, August 2026).

Victorino Group helps organizations write the controls that bound what automated systems are allowed to spend and decide on their behalf. Let’s talk.