Platform
A model ladder for serious AI software delivery
Multi-provider model routing with fallback: the right model for each task, work that continues when a provider degrades, and no single-vendor dependency.
The Ciao model ladder is multi-provider model routing with fallback: each task is routed to a suitable model, and when a provider degrades, work continues on the next rung. Unlike platforms hard-wired to one AI vendor, the ladder reduces dependency on any single model vendor — and on enterprise plans it can be constrained to your approved providers, your own keys or your private models.
Published 2026-07-03 · Last updated 2026-07-03
One model vendor is a single point of failure
The model landscape moves monthly: capabilities shift, prices change, providers have bad days. A platform hard-wired to one vendor inherits all of it — every outage becomes your outage, every pricing decision becomes your cost structure, every roadmap change becomes your constraint. Procurement teams have started asking the question directly: what happens to our delivery when your model vendor has an incident?
Ciao's answer is the model ladder: a multi-provider model ladder with fallback that reduces dependency on any single model vendor. Tasks are routed to the model suited to them, and when a provider degrades, the ladder falls back and the work keeps moving.
The same logic applies inside the products you ship. If your app's AI features depend on one provider, your customers inherit that provider's bad days too. Routing discipline at the platform level protects both the building of the software and the software itself.
How the model ladder works
The ladder is infrastructure, not a setting you manage day to day — routing and fallback happen below the level of the prompt.
1. Tasks are classified
A large build step, a quick UI edit, test generation and diagnosis are different kinds of work — the platform treats them that way.
2. Each task gets the right model
Routing matches the task to a suitable model rather than pushing everything through one general-purpose choice.
3. Fallback engages automatically
When a provider degrades or fails, the ladder routes to the next rung. Your build does not stop because someone else's status page turned red.
4. Providers run under strict terms
Inference runs under zero-retention model contracts, and customer code is not used to train models — across the ladder.
5. Enterprises set the boundaries
On enterprise plans, constrain routing to approved providers, bring your own provider keys, or point at OpenAI-compatible endpoints including private models.
Why it matters
Reliability, fit and negotiating position all improve when no single vendor sits underneath everything. Delivery continues through provider incidents, each kind of work gets a model suited to it, and your organization is not exposed to one company's pricing and roadmap decisions.
It also future-proofs the platform choice itself. Models will keep changing; a ladder absorbs that change behind a stable delivery loop, so betting on Ciao is not a bet on any particular model generation. For procurement, that converts an awkward dependency question into a short answer with evidence behind it — often the difference between an approved platform and a stalled one.
None of this asks anything of the people building. Prompts stay the same, the Builder stays the same, and the routing does its work invisibly until the day it visibly saves a deadline.
Who cares about the model ladder
The ladder tends to matter most to the people accountable for what happens when things fail:
- Engineering and platform leaders — Remove a single point of failure from the delivery pipeline before it fails at the worst moment.
- Security and procurement teams — Zero-retention contracts across providers, and a concrete answer to the vendor-dependency question in every RFP.
- Enterprises with approved-model lists — Constrain the ladder to sanctioned providers, own keys or private endpoints without giving up the platform.
- Teams shipping AI features — The same multi-provider discipline that builds the app stands behind the AI capabilities inside it.
Security and governance notes
Multi-provider does not mean loosely governed:
- ✓ Inference runs under zero-retention model contracts across the ladder.
- ✓ Customer code is not used to train models — any provider, any rung.
- ✓ Enterprise plans support own provider keys, OpenAI-compatible endpoints and private model routing.
- ✓ Admin actions and configuration changes land in the append-only audit trail.
- ✓ SOC 2 Type II reports are available under NDA for security review.
Single provider vs the Ciao model ladder
The structural difference shows up in every failure mode:
| Single-provider setup | Ciao model ladder | |
|---|---|---|
| Provider outage | Work stops until they recover | Fallback routes to the next provider |
| Task fit | One model for every kind of work | The right model per task |
| Vendor dependency | Total — pricing, roadmap, terms | Reduced across multiple providers |
| Model landscape shifts | A migration project each time | Absorbed behind a stable delivery loop |
| Enterprise control | Take the vendor or leave the platform | Own keys, private models and routing on enterprise plans |
Frequently asked questions
Which model providers does Ciao use?
Ciao maintains a multi-provider ladder and adjusts it as the model landscape changes, which is exactly the point — no single vendor underneath everything. Enterprise plans can constrain routing to approved providers, your own keys, or OpenAI-compatible endpoints.
Do I choose a model for each prompt?
No. Routing is per task — build steps, quick edits, tests and diagnosis go to suitable models automatically. Enterprises that need control set boundaries at the plan level rather than micromanaging prompts.
What happens during a provider outage?
Fallback engages and the ladder routes work to the next provider, so builds continue. That resilience is one of the main reasons serious teams ask about multi-provider routing in the first place.
Is our code exposed to all these providers?
Inference runs under zero-retention model contracts, and customer code is not used to train models — those terms apply across the ladder. Enterprises can further restrict which providers see anything by using their own keys or private model routing.
Can we run the ladder over our own models?
On enterprise plans, yes — bring your own provider keys or point routing at OpenAI-compatible endpoints, including privately hosted models. Serious production programs start at USD 10,000 per year; talk to sales about own-model configurations.