Your Cloud AI SLA Tells You Less Than You Think

By James Dawson Principal I 5th August 2026 · 6 min read

There is a lot being written about the rapid changes in frontier model capabilities, agentic workflows & the enabling tools. Today, though, let's step back from the coalface for a moment and talk to the people who are signing the purchase orders, not just the ones writing the code.

When it comes to enterprise software, the conversation around service reliability almost always ends up in the same place: the SLA. What's the uptime guarantee? What credits do we get if it drops below 99.9%? This is sensible, well-worn territory. We've been negotiating SaaS contracts on these terms for the better part of two decades and, for the most part, it works.

The problem is that this framing, when applied to cloud-based AI foundation models, is somewhat incomplete; "How so?" I hear you say.

The uptime illusion

Let's start with what a traditional SLA is actually measuring. When a vendor promises 99.95% monthly uptime, they are telling you that their API should have less than 30 minutes downtime per month (i.e. where they are unable to accept and respond to your requests); this equates to less than 5 hours over the course of a year. The green status page dot will be... green. The HTTP 200s will flow.

For a payroll system, a CRM, or a document store, that guarantee maps cleanly onto business value. If the system is up, it does what it did yesterday. The software version may change occasionally, but those changes are versioned, communicated, tested in staging, and rolled back if they break something. The behaviour of the system is, broadly, predictable.

Foundation model services operate on an entirely different contract, one that most vendors are not yet being asked to articulate clearly.

Consider what it actually means for a model provider to keep the lights on. The API may be perfectly available. Your requests are going in, responses are coming out. The green tick is present and correct. However, the model answering your requests today may not be the same model that answered them last Tuesday. And it may be substantially less capable at the specific task your agent or workflow depends on.

This is not speculation. There are multiple well-documented reports of incidents where users observed their previously reliable pipelines degrade, seemingly overnight without any outage event to point to. The model did not go down. It just became, for want of a better phrase, inexplicably dumber.

Before we think about the ways this can happen, Mike's post about the different layers that make up your AI-assisted coding experience is well worth a read and is directly related.

Silent model updates

Providers iterate on their foundation models continuously. Point releases, safety fine-tunes, reinforcement learning from human feedback (RLHF) adjustments, these happen on cadences that do not always come with prominent changelogs. If you are calling models by alias (rather than a pinned version) you are, in effect, opting in to whatever the vendor currently considers to be that model. Sometimes that's an improvement, sometimes it isn't (for you at least).

Harness and tooling changes

The model itself may be unchanged, but the scaffolding around it is updated (e.g. the system prompt handling, the tool-calling interface, the context window management). These changes can subtly alter how the model interprets its instructions, with results that range from mildly inconsistent to completely off-the-rails.

Default behaviour shifts

Perhaps the most insidious. A vendor decides that the default temperature, the system prompt, or the default safety thresholds should change. No alarm fires. Your monitoring shows no errors. But your agent, which was previously producing the required output with admirable consistency, now produces something... unexpectedly less useful!

In each of these cases, the SLA clock is not running. Nothing is broken and the vendor owes you nothing.

There are similarities with the Platform-as-a-Service offerings we are more familiar with, in that there is a lot of 'below the waterline' behaviour that can change in ways that unexpectedly impact your workloads. However, there are key differences:

• As mentioned above, the failure case is generally obvious (e.g. deployment or runtime errors that your monitoring will detect)
• We can run automated tests to verify behaviour, but what's the equivalent for assessing intelligence or the output of a non-deterministic system?

Shifting commercial sands

Whilst not really SLA-related we've also seen vendors, as they struggle to keep up with demand, engineer new concepts to give themselves some wiggle room (looking at you Anthropic with your "adaptive thinking"!), whereby a model might not be thinking as hard about your prompt as you had previously come to expect. In these types of cases, you can typically switch back to the original behaviour but you'll likely be consuming more token/credits than you were before. Similarly, GitHub's recent change to their Copilot billing (moving from 'Premium Requests' to 'AI Credits') looks like it will also result in a significant cost increase - some very early analysis on our usage looks like a 6x price increase!

The cost double-whammy

With traditional software downtime, the cost is relatively simple to model: you cannot do the thing, so you lose the value of doing the thing. It is painful, but it is bounded and, in most contracts, at least partially recompensed through service credits.

AI agent failures, particularly the silent kind caused by behavioural drift, do not work like this. The failure mode is not 'no response', it is 'a response that is wrong in a way you may not immediately notice'. And that creates a compounding cost structure.

Cost hit #1: You spend time and tokens doing something that turns out to be wrong

An agentic workflow might make dozens of model calls before a human reviews the output. Each of those calls costs money; directly in API spend and indirectly in the compute, orchestration, and latency overhead wrapped around it. If the underlying model has drifted and is producing subtly degraded reasoning, you've burned all of those tokens to arrive at an output that is less ideal than you expected.

Cost hit #2: You then spend more time and tokens trying to recover

This is the trap that's very easy to fall into. A confused or off-track agent doesn't cleanly fail, it often continues to operate making further calls, retrieving further context, perhaps even taking actions in downstream systems; all while heading in the wrong direction. Similarly, we've seen less capable models/reasoning effort end up churning tokens and feedback loops trying to solve a problem that a more advanced model/mode would have been able to one shot. By the time a human spots something is amiss, the remediation effort is not just "re-run the task", it may involve debugging the agent's trajectory, reverting actions, re-prompting, and re-running. You are, quite splendidly, paying twice for a problem that never appeared on your incident dashboard.

This is arguably a more significant operational risk than classic downtime for any organisation running AI agents at scale and it is almost entirely absent from current AI procurement conversations.

What if you are building something for a customer, the risks from such mistakes may previously have been mitigated through professional liability insurance; will that cover you today if the mistake was AI-generated? Whilst your customer will care little about the distinction, perhaps your insurance provider will see it as grounds to refuse a claim?

What should you be asking for?

As things stand today, you could be forgiven for thinking that you're being offered very little assurance!. It's unclear whether even the biggest of customers have much practical scope for commercial negotiations with a foundation model provider (i.e. it all feels very 'take it or leave it' right now), but assuming that this will evolve over time, here are the questions worth putting on the table or at least giving some thought to:

Model versioning and stability

• Can we pin to a specific model version, and how long will that version be maintained?
• What is your change notification policy for model updates including harness, tooling, and default changes?
• What regression testing do you perform before rolling a new version to production traffic?
• Can we use a model hosting service to exert more control? (e.g. Azure Foundry)

Behavioural guarantees

• Do you offer any form of output consistency guarantee, for example: structured output formats, tool-calling behaviour, or context handling?
• How do you measure and communicate changes to model capability on benchmark tasks?

Remediation and accountability

• If we can demonstrate that a model or tooling change caused measurable degradation in a production workflow, what is your resolution process?
• Are service credits applicable to token-wastage events, or only to outage events?

The honest answer, at time of writing, is that most providers will not have satisfying answers to many of these. That's not a reason to stop asking, it's a reason to document the gap carefully and factor it into your risk posture.

A glimpse at where this might go

There is a longer game at play here, and it is worth keeping in mind as part of the broader industrialisation of AI story that will need to address enterprise concerns.

The competitive landscape for foundation models is shifting quickly. Models that, eighteen months ago, required data-centre scale to run are increasingly viable on capable workstation hardware or private cloud infrastructure. As this trend continues, and there is little reason to believe it won't, enterprises (power users even) will have a genuine alternative to cloud-hosted foundation models for a growing set of use cases.

The moment organisations can credibly say "we could run this ourselves", the negotiating dynamic changes considerably. Providers who have been comfortable offering API uptime guarantees and little else may find themselves under pressure to articulate much richer commitments: behavioural stability windows, versioned model contracts, change freeze periods for enterprise customers, and genuine accountability for silent degradation events.

We are not quite there yet. But the organisations that start asking these questions now; that build the internal instrumentation to detect behavioural drift, that document the token-waste costs of degradation events, and that negotiate version-pinning rights into their contracts, will be materially better positioned when that conversation becomes mainstream.

This is a fast-moving space and this post definitely doesn't have all the answers, but I'd strongly encourage any organisation treating cloud AI spend as a straightforward operational cost to look again at what they are actually purchasing, and what assurances they have when it quietly stops behaving as expected; or at least to ensure they explicitly understand the lack of any such assurances!

FAQs