What Model Routing Changes Mean for UK AI Cost Control

Model Intelligence & News

12 June 2026 | By Ashley Marshall

OpenAI and Microsoft are making model selection more automatic. That can cut waste, but only if UK businesses treat routing as a measured finance control rather than a black-box promise.

Model routing has moved from product feature to finance control

The important shift in the latest OpenAI and Microsoft model changes is not simply that newer models are better. It is that model selection is being hidden, automated, and priced as an operational decision. OpenAI describes GPT-5 as a unified system with a fast model for most requests, a deeper reasoning model for harder work, and a real-time router that decides which route to use based on complexity, tool needs and user intent. Its release notes now show the same direction continuing through newer ChatGPT changes, including fallback behaviour for GPT-5.4 mini and the retirement of older selectable models. For a UK finance director, that changes the control question from "which model have we bought?" to "who decides which model handles each task, and how do we prove it was the right spend?"

Microsoft is making the same pattern explicit in Azure AI Foundry. The Microsoft model router documentation says the router analyses prompts in real time and can route between eligible models while honouring data zone boundaries. In Balanced mode it looks within a narrow quality band, such as 1% to 2% of the best quality model for the prompt, then chooses the most cost-effective option. In Cost mode that band widens to about 5% to 6%. That is cost governance written directly into the inference path.

What this means in practice is that AI cost control becomes a workload design problem, not a procurement spreadsheet. If a company uses one premium model for every support summary, sales email, contract clause, coding task and board report, it is almost certainly overpaying. If it lets a vendor route everything without logging the choice, it may save money but lose accountability. The sensible middle ground is to define task classes, expected quality levels, latency requirements, data sensitivity and maximum acceptable cost per completed task, then use routing only where it can be measured against those rules.

OpenAI changes show why model choice is no longer stable

OpenAI's recent release notes are a useful warning against treating any model menu as permanent infrastructure. On 28 May 2026, OpenAI said GPT-5.5 Instant was being updated in ChatGPT and the API to improve response style and quality. The same note said OpenAI o3 would be retired from ChatGPT on 26 August 2026 after a 90-day sunset period, and GPT-4.5 would be retired from ChatGPT on 27 June 2026 after a 30-day sunset period. Earlier 2026 notes retired GPT-5.1 models in ChatGPT and automatically continued conversations on newer equivalents. Those changes may be sensible product management, but they show that the user-visible model picker is no longer a reliable foundation for enterprise cost planning.

The API pricing picture reinforces the same point. OpenAI's current API pricing page lists a wide spread between model tiers. GPT-5.5 standard short-context pricing is listed at $5.00 per 1 million input tokens and $30.00 per 1 million output tokens. GPT-5.4 nano is listed at $0.20 per 1 million input tokens and $1.25 per 1 million output tokens. Cached input pricing can be materially lower, and OpenAI's prompt caching guidance says caching can reduce input token costs by up to 90% and latency by up to 80% for repeated prompt prefixes. That means the biggest saving may come from routing, caching and prompt architecture together, not from a single vendor discount.

The common misconception is that "auto" always means cheap. It does not. Auto routing can protect users from underpowered models, but it can also route more work to expensive reasoning paths when prompts are vague, too broad, or stuffed with unnecessary context. A UK business that asks every workflow to "think deeply" and sends full customer histories into routine classification tasks should expect a higher bill. The discipline is to write prompts and data pipelines so routine work stays routine, while genuinely high-value reasoning gets the stronger model.

Microsoft routing makes multi-model buying easier, but not effortless

Microsoft's model-routing move matters because many UK organisations already run their identity, documents, meetings, data platforms and security controls through Microsoft. The route into AI is therefore often Microsoft 365 Copilot, Copilot Studio, Azure OpenAI, Azure AI Foundry or a partner solution built on those services. Microsoft 365 Copilot pricing also shows the mixed commercial model: Copilot Chat is included for eligible Microsoft Entra account users with qualifying Microsoft 365 subscriptions, but agents need an Azure subscription or Copilot Studio capacity, and Microsoft 365 Copilot Business is priced separately per user. The cost base can quickly become a blend of seats, capacity, API calls, storage, data movement and operational support.

Azure AI Foundry's router is attractive because it lets teams call a single deployment and route underneath it. The how-to guide says the model router can be used through the Foundry Responses API or the OpenAI Python SDK, and that the playground shows which underlying model was selected. It also warns that the effective context window is limited by the smallest underlying model unless a subset is chosen, and that some parameters are ignored or dropped when a reasoning model is selected. Those details are not footnotes. They are exactly where production costs and quality drift appear.

What this means in practice is that Microsoft routing should be treated as an operating control with a test plan. Start with a narrow set of workloads, such as ticket classification, meeting summaries, proposal drafting or contract triage. Compare the routed output with fixed-model baselines. Record selected model, prompt size, output size, latency, retry rate, human correction rate and final task outcome. Then decide whether Balanced, Cost or Quality mode is right for each route. A routed deployment that saves 20% on tokens but doubles review time has not saved money. A route that keeps quality within tolerance while reducing premium-model calls is real cost control.

UK cost control needs unit economics, not AI enthusiasm

The UK context matters because adoption is rising faster than management discipline in many firms. The Office for National Statistics reported that about 25% of businesses were using some form of AI technology in late December 2025, up 15 percentage points since the question was first introduced in September 2023. For businesses with 250 or more employees, the proportion was higher at 44%. DSIT's 2026 AI Adoption Research painted a more cautious picture, saying around 1 in 6 UK businesses were using at least one AI technology, while a further 5% planned to adopt. The exact number depends on survey method and definition, but the business pattern is clear: more teams are using AI, and many are still learning how to budget it properly.

Recent government work also points towards practical adoption support, not blind spending. The UK AI Adoption Plan for Professional and Business Services says sector-level engagement will help SMEs understand barriers to adoption and inform an AI security health check and digital twin tool, so businesses can model the impact of AI adoption before committing resources. That wording is useful for cost control. The goal is not to buy the most impressive AI assistant. It is to model expected productivity, risk, skills, workflow change and cost before scaling usage.

The practical finance question is cost per completed business outcome. For customer support, that might be cost per resolved ticket after human review. For sales, cost per qualified account brief. For legal operations, cost per clause reviewed with acceptable risk. For software teams, cost per pull request merged. Token cost is only one input. Licence cost, implementation time, data preparation, failed runs, human checking, incident handling and supplier management all matter. Model routing helps when it lowers the full cost of the completed task, not merely the visible API line.

The counterargument: let the platform optimise it for us

The strongest counterargument is reasonable: OpenAI and Microsoft have more telemetry, more benchmarks and more engineering capacity than a normal UK business. If the platform can route intelligently, why not let it optimise model selection and stop worrying about the details? For individual users and low-risk internal work, that may be enough. A good router can reduce waste, improve responsiveness and protect people from choosing an underpowered model. It can also simplify application code by giving teams one endpoint rather than a brittle set of manual rules.

The problem is that the platform's optimisation objective is not automatically the same as the customer's. A router may optimise for a blend of response quality, latency, capacity, safety, availability and provider economics. The customer may care about unit cost, UK data handling, audit evidence, repeatability, contractual risk, sector regulation or human review burden. Those are related goals, but they are not identical. Microsoft says its router honours data zone boundaries and routes only to eligible models. That is useful, but the buyer still needs to decide which models are eligible, which workloads can use them, and what evidence is retained.

There is also a repeatability issue. If the same prompt can route differently over time because supported models, quotas, safety policies, quality bands or vendor defaults change, then production teams need monitoring. For a marketing draft this may not matter. For a regulated financial services summary, legal review support, HR screening workflow or public sector decision aid, it matters a great deal. A routed answer can still be correct, but the governance record should show which model produced it, what version of the prompt was used, which sources were retrieved, and who approved the output. The right conclusion is not "avoid routing". It is "use routing with observability".

A practical control model for UK AI buyers

The right response is not to freeze AI work until routing is perfect. It is to add a light, explicit control model before usage grows beyond visibility. First, segment work by complexity and consequence. Low-risk, high-volume tasks such as tagging, extraction, rewriting and summarisation should have a cheap default route, a maximum context size and a retry policy. Medium-risk tasks such as customer email drafting, proposal support and spreadsheet analysis should have quality checks and human review. High-risk tasks such as legal, finance, health, HR, security and regulated advice workflows should have stronger model requirements, logging, approvals and fallback plans.

Second, make routing measurable. Store the requested route, selected model where available, token counts, cached-token share, latency, errors, retries and human corrections. For Microsoft Foundry, use the playground and API telemetry to confirm which underlying model was selected during tests. For OpenAI API workloads, track the model requested, whether caching is being used, the prompt prefix design and the ratio of input to output tokens. Pair those technical metrics with commercial numbers: licence spend, API spend, Copilot Studio capacity, Azure consumption, implementation costs and staff review time.

Third, set budget guardrails in business language. A support summariser might have a target of pence per ticket and no more than a defined correction rate. A board pack assistant may justify a premium route because the output is low-volume and high-value. A coding assistant may justify a stronger model for complex debugging, but not for routine comment generation. This is where model-routing changes become useful for UK SMEs and mid-market firms: they allow differentiated spend. The business no longer has to choose between cheap AI and good AI as a single policy. It can decide where quality is worth paying for, where speed matters, and where a smaller model is good enough.

Frequently Asked Questions

What is model routing in AI?

Model routing is the process of sending each prompt or task to a suitable AI model rather than using one model for everything. A router may consider task complexity, cost, latency, model availability, data-zone rules and quality requirements before choosing the route.

Why does model routing matter for AI cost control?

It matters because different models can have very different costs. Routine tasks may be handled well by smaller models, while complex reasoning may justify a more expensive one. Routing lets a business reserve premium models for work where the quality gain is worth the cost.

Does OpenAI auto routing always reduce costs?

No. Auto routing can reduce waste, but it can also send vague, complex or overstuffed prompts to more expensive reasoning paths. Cost control still depends on prompt design, context management, caching, monitoring and clear task policies.

How is Microsoft Foundry model router different from manually choosing models?

Manual selection requires developers or users to pick a model for each workload. Microsoft Foundry model router lets teams deploy a single routing endpoint that selects among eligible underlying models according to routing settings such as Balanced, Cost or Quality mode.

What should a UK SME measure before trusting model routing?

Measure selected model, token volume, cached input, latency, retry rate, error rate, human correction effort, final task outcome and total cost per completed business process. Token price alone is not enough.

Is Microsoft 365 Copilot a substitute for AI cost governance?

No. Copilot can be valuable, but it introduces its own mix of licences, agent capacity, Azure usage and governance choices. Businesses still need to decide which workflows justify paid capability and how value will be measured.

What is the biggest misconception about AI model costs?

The biggest misconception is that the cheapest model always wins. A cheaper model can become expensive if it creates more failed runs, more human review, lower customer quality or more operational risk. The right metric is cost per acceptable outcome.

How often should model-routing policies be reviewed?

Review policies after major model releases, price changes, workload changes, supplier changes, incidents, unexpected cost spikes or regulatory updates. For active production systems, a monthly cost and quality review is a sensible starting point.