Why route at all
Putting an entire delivery pipeline behind one AI provider is a business risk, not a technical preference:
- An outage stops your work. When their API is down, your agents are down.
- You have no pricing leverage. No alternative means nothing to negotiate with.
- You miss improvements. Breakthroughs arrive at different labs at different times.
- Different jobs deserve different models. The role reading a paragraph of requirements does not need the model that writes your authentication code.
There is a second reason, and for some organisations it is the only one that matters: you decide where the thinking happens. Anything that speaks the common API can be plugged in, including models running on your own hardware — so the stack does not have to depend on an outside service at all.
That is also why the list is not only the Western labs. GigaChat (Sber) and Yandex AI Studio both answer through the same gateway, with the same failover and the same per-organisation metering as everything else — which matters if your users are in Russia and the obvious providers are not reachable or not billable from there.
Forge’s gateway sits between every agent turn and the provider that answers it. Your agents speak one language; the gateway translates for whoever is on the other end.
How it chooses
Each organisation keeps an ordered list of providers, governed by two things:
- Preference — you set it. Which provider you would rather use, all else equal.
- Health — Forge tracks it. A rolling view of how that provider has actually been behaving: how often it has errored lately, how recently, and how long it has been stable since.
When a turn arrives, Forge takes your preferred provider that is currently healthy. If the call fails it moves down the list and tries the next one, and the run carries on. A provider that starts failing gets used less; one that stays stable through a cooldown period earns its place back. A bad afternoon does not get a provider written off for good.
There is also a designated fallback per organisation, kept out of the normal rotation and used only when everything else has failed. Think parachute, not plane.
Pinning
Sometimes you want less choice, not more.
Pin a run. Every turn of one run gets answered by the same model, so the reviewer is reading work produced under the same assumptions as the developer’s.
Pin a pool of machines. A group of runners can be marked as only accepting work for a particular provider or region. This is how teams satisfy “personal data must stay on inference in this region”, and how you roll a new provider out to a small slice of traffic first.
Spending where it matters
Roles have different needs, and each one can carry its own default. A pattern most teams land on:
- Product manager → fast, inexpensive; it is reading and organising requirements.
- Architect → the strongest model you have.
- Developer → the strongest model you have; this is the heavy lifting.
- Tester and reviewer → a balanced model that is reliable with structured output.
You can set this per role, or as rules on the organisation’s provider list.
What you get
Everything below is running in production today.
- An ordered provider list per organisation, with a designated fallback
- Automatic failover and health-based demotion and recovery
- Per-run and per-role provider pinning
- Pools of machines restricted to one provider or region
- A console for the provider list, the per-run chooser, and filtering past runs by who answered them
Try it
If you are already on Forge, open your organisation’s settings and add a second provider behind your current one. Forge will keep sending everything to your primary until something breaks, fail over without an agent error, and shift back once the primary is healthy again. The point is that you should not notice — the failover is visible afterwards in the run history, not during the run.