What happens when the AI provider fails mid-job?

Every AI feature you use is a request to somebody else's computer. That computer has outages, rate limits, deprecations and days when it is simply slow.

The question nobody asks their vendor is: when that happens, who pays?

The three honest answers a vendor can give

• You do. The request was attempted, the credit is gone, try again. This is more common than you would expect, because charging on attempt is the simplest thing to build.
• We do, and we absorb it quietly. Which works until the outage is long, and then the feature is withdrawn or the price moves.
• Nobody does, because the charge is reconciled against what actually happened.

This platform does the last of those, and the mechanism is the point.

Reserve, execute, reconcile

A request reserves its ACUs before a provider is called. The call runs. Then the reservation is reconciled against what actually happened:

• the provider answered — you are charged for the work,
• the provider failed — the reservation is released and you are charged nothing,
• the provider answered less than was asked for — a truncated draft is not a result, so the work continues rather than being delivered half-finished and billed in full.

The important word is reserved. A system that charges first and refunds later is a system where your balance is wrong for as long as the refund takes, and where a failure during the refund leaves you out of pocket.

One registry, no provider names in the product

Six models from three providers sit in a single registry, each with its capabilities, its quality score and its price. Feature code never asks for a named provider — it asks for a capability and a quality level, and the routing engine chooses.

Two consequences you can check:

• Prices are data, not code. A provider changing its rates does not require a deployment here.
• Any provider can be disabled instantly. If one has an incident, or a term we will not accept, it leaves rotation without the features that use it noticing.

There are five routing modes — automatic, lowest cost, fastest, highest quality, and pinned to one provider when you have a reason. Automatic is the default and weighs cost against the quality the task genuinely needs, which is why a social caption and a legal-sensitive page do not get the same model.

The circuit breaker, and why it saves you money

When a provider starts failing, the naive behaviour is to retry. Retrying into a failing provider is how a job burns its whole invocation and returns nothing.

So a failing provider trips a breaker: it is taken out of rotation, work routes to an alternative, and the breaker half-opens later to test one request before trusting it again. Your job moves instead of queueing behind something that is not working.

What it cannot do

It cannot make an outage invisible, and it will not pretend to. If every route for a capability is degraded, the work waits — and because no AI action here has a time limit, waiting is not failing. It continues when the route recovers.

What you should never accept is a vendor who cannot tell you what a failed request costs you. That is a question with a factual answer, and ours is: nothing.