Why AI Infrastructure Matters More Than AI Models

Claude Opus 4 shipped in May 2025. It was retired in June 2026. Thirteen months. Claude 3.7 Sonnet lasted exactly twelve. Opus 4.1, twelve. You can check the dates yourself on Anthropic’s deprecation page; OpenAI keeps a similar list, where generally available models get six months’ notice, specialized variants three, and preview models “as little as 2 weeks”.

Now think about everything your team tuned around that model. The system prompts. The few-shot examples. The JSON-mode quirks you learned to work around. Much of that work will need retesting when the model changes. Your eval set is the exception: it should outlive the model and tell you whether the replacement is actually better.

This is the argument I want to make: the model is the least durable part of your AI stack. Picking the right one matters, but it matters far less than building an application that can survive its replacement. After two years of watching companies deploy generative AI, I am convinced that the teams shipping reliably in 2026 are not the ones that made a perfect model choice in 2024. They are the ones that kept model choice separate from application architecture.

If you need convincing, look at the last three months.

The summer of 2026 in twelve weeks

Here is what changed between June and August, in order:

• June 1: MiniMax releases M3, a natively multimodal model with a 1M-token context window; its weights followed later that month.
• June 9: Anthropic launches Claude Fable 5, the first Mythos-class model available to the public, at $10/$50 per million input/output tokens.
• June 15: Anthropic retires Claude Opus 4 and Sonnet 4.
• June 16: Z.ai ships GLM-5.2, with open weights under an MIT licence and a 1M-token context window.
• July 9: OpenAI launches GPT-5.6 in three tiers—Luna, Terra and Sol—after a limited preview that began on June 26.
• July 16: Moonshot releases Kimi K3, a 2.8-trillion-parameter, natively multimodal model with a 1M-token context window. Its full weights followed on July 27.
• July 24: Anthropic launches Claude Opus 5, which came within 0.5% of Fable 5 on Anthropic’s CursorBench run at half the cost per task.
• July 31: DeepSeek moves V4-Flash to public beta; on August 13, V4-Pro goes GA, followed by peak and off-peak pricing on August 16.
• August 3: Alibaba launches Qwen3.8-Max; on August 12, it publishes the first open-weight checkpoint derived from a Max-class Qwen.
• August 5: Anthropic retires Claude Opus 4.1.

Twelve weeks brought new closed and open-weight models, several price changes and three Claude API retirements. Benchmark leadership also varied by task: a model could lead on one coding or agentic evaluation and trail on another.

Three things stand out for anyone running AI in production.

The gap between open and closed narrowed sharply. Downloadable models moved close to the closed frontier on several coding and agentic evaluations. That changes the build-vs-buy question, the data residency question, and the negotiation with every closed provider.

The price map got rewritten monthly. Kimi K3 launched at $3/$15 per million input/output tokens, while DeepSeek V4-Flash sits at $0.14/$0.28 and Opus 5 costs half as much as Fable 5 per token. GPT-5.6 launched at $1/$6 for Luna and $5/$30 for Sol; three weeks later, OpenAI had cut Luna to $0.20/$1.20 and Terra to $2/$12. Jefferies, citing Silicon Data, put the average inference price at $2.04 per million tokens on May 31 and $1.16 by August 8. A 43% drop in ten weeks. A routing table written in May could be economically obsolete by August.

The “best model” depends on the job. Coding, tool use, writing, latency and cost produce different winners. If your architecture assumes one model will remain best for everything, that assumption has a short half-life.

None of this is going to slow down. The lesson is not “pick Kimi” or “pick Opus”. The lesson is that picking is now a continuous activity, and your platform either makes it cheap or makes it a project.

Multi-model is already the norm

If you think of “which LLM should we use?” as a one-time decision, the data says you are in a shrinking minority.

In early 2024, a16z’s interviews and survey of enterprise leaders found that all respondents were testing multiple models. A year later, in its follow-up with 100 enterprise CIOs, 37% were running five or more models, up from 29%. The interesting part is why. Avoiding lock-in is one reason, but a16z found that the main driver had become differentiation by use case: one model wins on code completion, another on architecture, another on writing, another on complex question-answering.

A Dataiku-commissioned Harris Poll survey of 600 CIOs from 2026 lands in the same place: 93% say different LLMs perform better for different use cases and that this requires continual evaluation and switching; 81% expect to rely on two or more providers this year; and 55% have already switched LLMs at least once, with cost reduction the most cited driver.

Read those numbers together. Many large organisations already run several models and switch between them. They are likely to do so more often than they would like, because providers retire models on a roughly yearly cadence and the price/performance frontier keeps moving. The practical question is whether each switch is a controlled platform change or an application rewrite.

One CIO in the a16z study put it plainly: “all the prompts have been tuned for OpenAI… changing models is now a task that can take a lot of engineering time.” That is what technical debt looks like in 2026.

What actually kills AI projects

Here is the uncomfortable part. Most AI initiatives do not fail because the model was not smart enough.

MIT’s Project NANDA published The GenAI Divide in 2025, based on 150 leadership interviews, a 350-employee survey and an analysis of 300 public deployments. Its headline finding was that 95% of the enterprise GenAI initiatives it examined showed no measurable impact on P&L. The report attributes the gap not to model capability but to tools that fail to integrate with, learn from or adapt to real workflows. External partnerships involving customised, learning-capable tools reached deployment about 67% of the time, compared with about 33% for internally built tools. The authors describe those outcomes as self-reported and caution that they may not account for confounding variables, so the figures are directional rather than universal.

Gartner tells the same story from a different angle. It had predicted that at least 30% of GenAI projects would be abandoned after proof of concept by the end of 2025. It now reports that at least 50% were abandoned. The reasons: poor data quality, inadequate risk controls, escalating costs and unclear business value. Those are not failures that a stronger model fixes; they are infrastructure, governance and operating-model problems.

And McKinsey’s State of AI 2025 shows the scaling gap in numbers: 88% of respondents say their organisations use AI regularly, nearly two-thirds have not begun scaling it, and about 6% qualify as “high performers”—organisations that attribute at least 5% of EBIT to AI and report significant value from it. What distinguishes that 6%? They are much more likely to redesign workflows and define human-in-the-loop validation processes. The evidence points to operating practices, not model choice alone.

In my own experience, the failures in production are depressingly mundane:

• A rate limit that never showed up in testing takes down a customer-facing feature on a Monday morning.
• A “quick experiment” with a reasoning model turns a few euros a day into a few hundred, and nobody notices for three weeks because nothing tracks spend per project.
• A provider ships a silent behaviour change in a dated model snapshot and a downstream parser starts failing on 3% of responses.
• A regulated customer asks which documents were sent to which model on which date, and nobody can answer.

None of these get solved by a better model. All of them get solved by a better platform.

The price of intelligence is collapsing. Your bill is not.

Stanford’s 2025 AI Index contains a number that should change how you think about AI budgets: the inference cost for a system performing at GPT-3.5 level dropped more than 280-fold between November 2022 and October 2024. Open-weight models closed their gap with closed ones from 8% to 1.7% on some benchmarks in a single year.

So the price per unit of benchmark performance is falling quickly, and this summer’s 43% estimate suggests the trend is continuing. And yet Menlo Ventures estimates that the enterprise AI market grew 3.2× to $37B in 2025. In the Dataiku/Harris Poll survey, 55% of CIOs had already switched models at least once, with cost reduction the most cited driver.

One part of the explanation sits in the architecture. If every request goes to the most expensive model regardless of difficulty, if repeated work is never reused, and if nobody can see spend per team or use case, lower token prices do not automatically produce a lower bill. Cost control in AI is not only about negotiating a better rate. It also depends on routing, caching, and observability, which live in the infrastructure layer, not in the model.

In Europe, governance is not optional infrastructure

If you operate in the EU, there is a further reason infrastructure comes first. The AI Act’s obligations for high-risk systems include automatic event logging throughout the system’s lifecycle (Article 12) and deployer duties around human oversight, monitoring and log retention (Article 26). Under the consolidated regulation, most provisions apply from 2 August 2026; the amended deadline is 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I systems. The 2 December 2026 transition applies specifically to Article 50(2) marking obligations for relevant systems placed on the market before 2 August 2026—not to every transparency obligation.

Whichever deadline applies to you, notice what the requirements have in common: logs, traceability, human oversight and data governance. None is solved by model choice alone. A governed platform can provide reusable controls and evidence across applications and providers. Compliance still depends on the use case, the organisation’s role, the system’s risk classification and the surrounding human processes.

What to build instead

If the model is the volatile part, the durable part is everything that sits around it. Six pieces. Each one has a simple test: if the next model release forces you to touch application code, that piece is missing.

1. An abstraction layer, so the model is a setting

Application code should ask for a capability and its requirements—“summarise this document within this latency budget”, “extract these fields into this schema”—without scattering provider names through business logic. Provider-specific APIs, model selection, failover and retries live behind that boundary. Switching providers becomes a controlled platform change.

We spent a decade learning this lesson with databases and ORMs; there is no reason to relearn it with LLMs.

2. Routing by task, not by habit

Simple queries can go to cheap, fast models; complex or high-risk work can go to more capable ones. Given that 93% of CIOs in the Dataiku/Harris Poll survey say different models win on different tasks, routing is not just an optimisation. And since the price map changed several times this summer, routing rules should be centrally managed policy rather than duplicated application logic.

3. Caching

Where requests or source context repeat, caching can deliver a major latency and cost win. It is provider-independent, but it needs access controls, retention rules and invalidation so that stale or private responses are not served to the wrong user.

4. Observability with a budget attached

Token consumption, cost per request, per project, per user; error rates; quality signals. All visible to the people who own the budget, not just to the engineer who wrote the integration. Most of the “cost surprises” I described earlier were not caused by expensive models; they were caused by nobody looking.

5. Data protection by construction

Which data can leave the organisation, to which provider, under which contract and with what retention. Enforce those rules at the platform level so that each application does not have to reimplement them. Shared logging, access controls and audit evidence can support AI Act and GDPR obligations across applications, while use-case-specific compliance remains the responsibility of the organisation deploying the system.

6. Evaluation that outlives the model

This is the one most teams skip, and the one the summer of 2026 made non-negotiable. When several frontier-class models ship in twelve weeks, “is the new one better for us?” is a question you will ask every month. Answering it by feel, or by reading someone else’s benchmark, is how regressions reach production.

What you need is boring and specific: a fixed set of real prompts from your own use cases, the expected outputs or a rubric, and a way to run that set against several models at once and compare, side by side, what each one produced, what it cost, how long it took and how it scored. The score can be exact-match, a rubric, or a stronger model acting as judge; the point is that it is your metric on your data.

Do this and evaluating Opus 5 or Qwen3.8-Max takes an afternoon and produces a number. Skip it and every release is a debate.

Build these six and something useful happens: when a provider ships a better or cheaper model, you can evaluate and adopt it without rewriting the application. Hardcode the model instead and every release from every provider risks becoming a migration project.

How we think about this at MINEO

This is the thesis behind MINEO. We built it as a governed platform where the whole team can use AI: business users through Threads and no-code Assistants; data teams through Notebooks, Live Apps, Pipelines and Dev Environments. Models sit behind one governed layer with no vendor lock-in. Model choice is managed centrally, costs are visible and controllable per project, and shared controls help teams protect data and meet GDPR and EU AI Act obligations. When a model is retired, teams can evaluate its replacement and roll it out centrally instead of reworking every application. That is the point.

The models will keep getting better, and they will keep getting retired. Plan for both.