Frontier model pricing has stopped following the simple downward trajectory that defined the early years of the LLM era. The most capable models from the top providers are now meaningfully more expensive than they were a year ago, even as a wide ecosystem of capable mid-tier and open-weight alternatives has matured underneath them. The economics have pushed enterprise architecture in a specific direction: most production AI systems shipped in 2026 are no longer single-model deployments. They are routing systems that pick a model per request based on cost, capability, and latency. The architectural shift is sensible from a finance perspective, but it has created a new class of security and reliability problems that most teams have not yet built controls for.
What The Pricing Curve Actually Looks Like
The headline that "AI is getting cheaper" was true for several years and is now misleading. Mid-tier and open-weight models continue to drop in cost. But the top-end frontier models — the ones organizations reach for when reasoning quality matters most — have stayed flat or risen as providers price for the cost of training and serving the next generation of capability. The result is a widening gap between the cheap models and the expensive ones. A few cents per million tokens at one end, dollars per million tokens at the other, with the gap growing.
Enterprise teams responded predictably. If a request can be handled by a cheaper model, send it to the cheaper model. If the request needs frontier capability, pay for it. Build a router that decides on a per-request basis. The router became a core architectural component. By early 2026 most enterprise AI deployments we have audited use some form of routing — sometimes a vendor product, sometimes a homegrown layer, sometimes a hybrid.
The Architectural Pattern
The mature pattern looks roughly like this. A request arrives at the application. A router classifies it — usually with a smaller model — into one of several tiers. Easy requests go to a cheap model with a tight latency budget. Medium requests go to a mid-tier model with reasonable cost and capability. Hard requests, complex reasoning, or anything tagged high-stakes by the application go to the frontier model. Some routing systems also include feedback: if a cheap-model response fails a quality check, escalate to the next tier.
This works. Cost dashboards show meaningful savings — typical reports we see are 40 to 70 percent reductions versus all-frontier deployments — without large user-visible quality drops. The savings are real and the engineering pattern is reproducible. The reason the trend matters for security is what the routing layer does to the system's properties.
Where The Security Properties Slip
Five distinct issues recur in our audits of multi-tier deployments.
Inconsistent guardrail coverage across tiers. The cheap model and the frontier model have different abuse profiles, different jailbreak resistances, and often different vendor-side safety controls. A guardrail rule tuned for one tier may not catch the same input in another. Teams sometimes build guardrails against the frontier model's behavior, then find that the cheap model — which handles the majority of traffic — is doing something the guardrail does not check.
Routing decisions as a control surface. The router decides which model handles each request. If an attacker can influence that decision — by crafting an input that makes the classifier mark a high-stakes request as easy — they can route a sensitive query to a model with weaker safeguards. Several disclosed incidents involve exactly this pattern. The fix is to apply policy at the request level independent of the routing tier, but most early routers do not.
Provider sprawl. A multi-tier system often involves multiple model providers. Each provider has its own data handling terms, its own incident posture, and its own audit interface. Procurement and security review for one provider does not transfer to another. Teams that started with a single-provider deployment and added tiers over time often have not re-completed vendor diligence for the additional providers.
Inconsistent prompt construction across tiers. The system prompt for the cheap model is often shorter than the one for the frontier model, on the assumption that the cheap model needs less context. But a shorter prompt may omit safety instructions that the frontier prompt carried. The result is uneven safety posture across the routing layer.
Telemetry fragmentation. Logs and traces are often siloed by provider. A request that bounced between three models leaves three separate audit trails, none of which contain the full picture. Investigating an incident becomes a reconstruction exercise.
The Operational Problem
The cost-saving routing layer also creates a quieter operational problem. Performance is no longer measured against a single model. It is measured against a distribution of models, each of which can change on its provider's schedule. When the cheap model gets quietly upgraded by its provider, downstream behavior changes. When a mid-tier model is deprecated, the routing logic has to be updated, often without clear migration guidance from the provider.
This is not unique to AI — it is the same problem any heterogeneous third-party-dependent system has — but the rate of change at the model layer is much higher than what teams are used to in other categories of dependency. A model deprecation notice at 60 days' lead time is a tight schedule for a system that integrates several models from several providers.
What Better Programs Are Doing
The teams that have absorbed this trend and are managing it well share a few practices.
They treat the router as a first-class component. It is code, tested, version-controlled, and reviewed. Routing logic changes go through the same review as any other production change. The router has explicit policy hooks that apply independent of the chosen tier — high-stakes requests always get certain checks regardless of which model handles them.
They enforce a consistent prompt and guardrail floor. A baseline system prompt and a baseline set of guardrails apply to every tier. Tier-specific additions sit on top of that floor. The floor is what guarantees that "the cheap path" is never weaker on safety than "the expensive path," only on capability.
They maintain unified telemetry. Every model call, regardless of provider, is logged through a single observability pipeline that correlates routing decisions, prompt content, model identity, response, and any policy events. Reconstruction of a session works the same way no matter which models were involved.
They track providers as a portfolio. Each provider in the routing system is enumerated with current contract terms, data handling commitments, incident response track record, and a model deprecation calendar. The portfolio is reviewed quarterly. New providers go through the same diligence as the original choice.
They plan for model deprecation. The routing logic includes fallback paths that can be activated quickly if a model is deprecated or degrades. The fallback is tested.
What To Watch
The pricing trend is unlikely to reverse. Frontier models will remain expensive because training and serving cost is genuinely high. The mid-tier and open-weight ecosystem will keep maturing. Multi-tier routing will become more prevalent, not less, and the practices around it will follow a similar trajectory to multi-cloud — a category that started as an architectural choice and ended up requiring its own discipline.
Within the year we expect router-specific products to proliferate, with corresponding security features — policy at the routing layer, telemetry unification, guardrail consistency. By the end of 2026, "we run a homegrown router" will be a starting position that gets upgraded to a managed product under audit pressure.
How Safeguard Helps
Safeguard treats every model in your routing system as a tracked component, with provider, version, contract terms, deprecation status, and observed behavior all enumerated in your AI bill of materials. Routing decisions are observable end-to-end, so a request that bounced through three providers leaves a single correlated trace rather than three siloed ones. Policy gates can require a baseline guardrail set across all tiers and flag any tier-specific configuration that weakens the floor. When a provider issues a deprecation notice, when a new tier is added, or when routing logic changes in a way that affects safety properties, Safeguard surfaces the change as a finding. The frontier-pricing pressure that pushed your architecture toward multi-tier routing should not push your security posture backward; Safeguard gives you the unified inventory, telemetry, and policy enforcement to keep the savings without trading away the controls.