Pay for the Model You Need, Not the One You Defaulted To
Most teams pick one model and one provider early and never look again. Three small habits change that: ask by model name, match the model to the work, and fail over within your policy. You choose how far to go with each.
In this post
- 01The default nobody reviewed
- 02Three questions worth asking again
- 03One model name, several providers
- 04Your policy stays in charge
- 05A cheaper tier for work that does not need the best
- 06What tiering is worth, in numbers
- 07When the provider is down
- 08Reliability is a cost decision too
- 09Budgets apply to every retry
- 10Roll out in a month
- 11Your first week
The default nobody reviewed
Every AI app starts with a choice made in a hurry.
Someone picks the best model they know and the provider they already have an account with. It works, so it ships.
Picture this
A support assistant launches on the largest model from one provider because it gave the best answers in testing. A year later it handles thousands of simple questions a day, such as order status and password resets. Each one still goes to the largest model, at the largest model's price.
Nothing is broken. The choice just stopped being a choice. Nobody asked whether a smaller model would answer the easy questions as well, or whether another provider sells the same model for less.
Three questions worth asking again
Model choice is not one decision.
It is three, and each has its own control.
| Question | What answers it |
|---|---|
| Which provider should serve this model? | Ask by model name and let Cloptima choose from the providers you can use |
| Which model should serve this request? | Your choice per kind of work, checked against spend by Model in the Explorer |
| What if the provider is down? | Automatic retries, then failover to another provider that serves the model |
You decide how far to go with each. They work on their own, and they work together.
One model name, several providers
The same model is often sold by more than one provider.
Claude runs on Anthropic, Vertex AI, and Bedrock. GPT models run on OpenAI and Azure. Naming the provider in your code ties the app to one of them.
Pinned to a provider
- The code says anthropic/claude-opus-5-5
- A cheaper route needs a code change
- An outage at that provider is your outage
Asking by model name
- The code says claude-opus-5-5
- Cloptima picks the lowest-cost provider you can use
- Your policy lists decide what is allowed
The choice is stable. The same kind of request keeps landing on the same provider, which keeps its prompt cache warm, until prices change. Your own keys come first, and Cloptima credits cover the rest.
Your policy stays in charge
Choosing a provider for you does not mean choosing around you.
The policy is the authority.
- Allowed providers keep traffic where your data rules say it belongs
- Denied models are never chosen
- A provider you have no credential for is never chosen
- The Request Simulator shows the choice before you send anything
A cheaper tier for work that does not need the best
Not every request needs your strongest model.
Sort the work into three tiers, cheap, balanced, and strong, and send each kind of request to a model that fits it.
| Tier | A good fit | Example work |
|---|---|---|
| Cheap | Short, simple, high-volume requests | Order status, classification, extraction |
| Balanced | Everyday reasoning | Summaries, drafts, routine analysis |
| Strong | Hard or high-stakes requests | Complex reasoning, long documents |
Check that each model can do what the work needs: tool calls, structured output, images, streaming, and enough room in its context window. Your policy lists and credentials apply to every model you choose.
What tiering is worth, in numbers
The saving depends on how much of your traffic is easy.
Here is an illustration for an assistant that handles 10,000 requests a day.
| Plan | Requests | Cost per request | Daily cost |
|---|---|---|---|
| Everything on the strong model | 10,000 | $0.0100 | $100.00 |
| Cheap tier for simple requests | 7,000 | $0.0004 | $2.80 |
| Balanced tier for everyday requests | 2,000 | $0.0030 | $6.00 |
| Strong tier for hard requests | 1,000 | $0.0100 | $10.00 |
| Tiered total | 10,000 | $18.80 |
In this illustration the daily cost falls by about 81 percent. Your own mix will differ, so move one kind of request at a time and compare spend by Model in the Explorer before and after.
When the provider is down
Providers have bad hours. The question is whether your users notice.
1Call fails
Connection error, timeout, rate limit, or server error
2Retry
Short failures often clear
3Fail over
To another provider that serves the model
4Answer returned
No change in your code
Retries and failover need nothing set up: a request for a model can fail over to any of your providers that serves it. Conversations stay where their prompt cache is warm. For the rare model that cannot be served, a policy can name backup models.
Reliability is a cost decision too
A failed call costs time, and a retry can cost money.
Cloptima handles both for you.
| What Cloptima does | Why it matters for cost |
|---|---|
| Retries short failures | A short blip never becomes a request your app has to send again |
| Fails over to the same model on another provider | The answer you tested is the answer you get |
| Keeps conversations where their prompt cache is warm | Long conversations stay cheap |
| Uses backup models only when the requested model cannot be served | A different model is the last resort, never the first |
There is nothing to tune. The one choice you make is whether to add backup models.
Budgets apply to every retry
Retries, failovers, and backup models follow the same budgets and credits as the first call.
You pay for what providers bill.
Roll out in a month
A staged plan keeps each change small.
- 1
Week 1: ask by model name
Replace provider-pinned names with plain model names on one app. Check the choice in the Request Simulator.
- 2
Week 2: connect a second provider
Add a credential, then watch spend by Provider in the Explorer.
- 3
Week 3: add backup models
Failover is already on. Pick backup models on the policy for the rare case a model cannot be served.
- 4
Week 4: move the easy work
Send one kind of simple request to a cheaper model and compare spend by Model in the Explorer.
Your first week
Start where the savings and the risk are both small.
- Pick one app and one model name that several providers serve
- Set Allowed providers on its policy to match your data rules
- Add a credential for a second provider
- Compare spend by Provider and Model in the Explorer after a few days
- Write down which requests are simple enough for a cheaper tier