How deadlines become discounts: SLA tiers explained
What decides the price of a batch job? Mostly, the deadline you give it. The more time the work is allowed to take, the cheaper it can run.
A deadline is permission to wait
A deadline gives the scheduler permission to wait for a better price, up to that time. The price of computing moves: between regions, between providers and through the day. Every extra hour you allow is another chance to catch a cheap moment.
That is why the same job can cost very different amounts depending only on when you need it. The work is identical. What changes is how much room there is to find a cheap time to do it.
How tiers turn patience into price
Service tiers (often called SLA tiers, after "service level agreement") package this as a few named deadlines, from the longest and cheapest to the shortest and most expensive. Most batch services offer just one deadline (the comparison below shows the best-known one); a ladder lets you choose. Here is Otium’s:
| Tier | Deadline | How it runs | Good for |
|---|---|---|---|
| Remnant | < 7 days | Waits for the cheapest moments and uses spare computers in any region. | Backlogs, re-processing, anything with no fixed date on it. |
| Standard | < 24 hours | Skips the expensive hours and runs when demand drops. | Nightly jobs: the everyday choice. |
| Priority (planned) | < 6 hours | Waits for smaller price dips and prefers machines already running. | Same-business-day batches. |
| Rush (planned) | < 1 hour | Starts almost at once, on a reserved machine if it has to. | “I need it this hour.” |
Choosing the right window
Pick the longest deadline the work can really live with, not the shortest you might like. Teams often ask for urgency out of habit and pay for it. Ask when the output actually needs to exist. If a catalog refresh feeds a weekly report, a seven-day window costs far less than a one-hour one and changes nothing about the result.
You can also split the work: run the bulk of a backlog on the cheapest deadline, and pay for a faster one only for the part that is truly time-sensitive.
Then send everything on that deadline at once. A deadline buys the most when the scheduler can see all the work it covers. Starting a machine costs the same for ten requests or ten thousand, and Otium waits until there is enough work to fill one before starting it, so a whole backlog starts sooner and runs cheaper than the same work trickled in a few requests at a time. Pick a deadline, then send it all.
A steady price on a moving market
You should not have to watch the market yourself. A good service charges a fixed, published price per tier that you can plan against, and takes on the moment-to-moment swings in what capacity costs. You get a steady price and the discount; the service carries the risk of finding capacity below it.
How this compares, and where it comes from
Paying less for patience is not a new idea: the interactive providers sell a version of it. What stands out is how blunt that version is. OpenAI's Batch API prices a flat 50% discount, and its completion window can only be set to 24 hours: one point on the curve, take it or leave it.
Tiers are what that looks like when the window becomes a dial instead of a constant. Why a longer deadline reaches a lower price is the subject of specific systems research: with a deadline, a scheduler can run on interruptible capacity and keep standard, on-demand capacity in reserve, switching only when the job falls behind the pace its deadline needs. That policy is the contribution of Can't Be Late (NSDI 2024), and it is what a tier buys you.
Frequently asked questions
Why is a longer deadline cheaper?
It gives the scheduler more time to wait for cheap, interruptible capacity and to look across regions for a lower price. More room to wait means a lower price.
Which SLA tier should I choose?
The longest deadline the work can truly live with. If nobody is waiting on the result, choose the longest tier, and pay for a faster one only for the part of the work that is genuinely urgent.
Related guides
Spot and remnant GPUs are the same hardware sold cheap, with the catch that it can be reclaimed. How it works, and why batch can use it when interactive cannot.
Work backwards from when the output is needed, not from how fast it could be. A practical way to set deadlines for batch AI jobs and pipelines.
Batch AI inference runs large volumes of requests against a deadline instead of in real time. How it differs from interactive inference, and why it costs less.
Prompt caching reuses the computed state of a repeated prefix so you stop paying full price for it. How it works, why batch benefits most, and how it is billed.
If your AI work is a pipeline, submitting one request at a time discards the structure that would let it be scheduled well. What the research says that costs.