Price Sheet at a Glance and the Three Tiers
How T0 Flagship / T1 Workhorse / T2 High-volume divide the work; knowing which is expensive isn't enough—watch the price-jump boundaries
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Price Sheet at a Glance and the Three Tiers”?
How T0 Flagship / T1 Workhorse / T2 High-volume divide the work; knowing which is expensive isn't enough—watch the price-jump boundaries
Read cost as a shape, not a single number. Break a request into input, output, retries, tools, and waiting time. The shape of usage usually tells you which design choice is expensive and where a smaller change can help.
Measure one real request before you optimize an imagined average.
A cheaper call that quietly creates more retries, latency, or review work.
Below is an illustrative USD-equivalent worksheet, not a live quote from any one provider. The three columns are non-cached input, cached input, and output per million Tokens. Real providers use different tiers and currencies; the point is to see how a cache discount and a context boundary change routing decisions.
| Model type | Tier / context | Input (non-cached) | Input (cached) | Output |
|---|---|---|---|---|
| Frontier reasoning API | Input ≤32k · Output ≤200 | $1.00 | $0.20 | $4.00 |
| Input ≤32k · Output >200 | $1.50 | $0.30 | $6.00 | |
| Input 32k–200k | $2.00 | $0.40 | $8.00 | |
| Balanced general model | Input 0–32k | $0.50 | $0.10 | $2.00 |
| Input 32k–128k | $1.00 | $0.20 | $4.00 | |
| Input 128k–256k | $1.50 | $0.30 | $6.00 | |
| Fast high-volume model | Input 0–128k | $0.08 | $0.02 | $0.80 |
| Input 128k–256k | $0.30 | $0.06 | $3.00 | |
| Hosted open-weight endpoint | Input 0–32k | $0.40 | $0.00 | $1.20 |
| Input 32k–64k | $0.80 | $0.00 | $2.40 |
Red numbers are prices “after a tier jump.” Inside the same model, prices can differ by 2–3×—those boundaries are the stars of Lessons 4, 5, and 6.
Frontier reasoning and long-output tier
Expensive output, capability ceiling. Leave for complex reasoning, code gen, multi-model arbitration—tasks where “getting it wrong costs more.”
Balanced general workhorse
Balanced value. The daily workhorse for chat, RAG Q&A, and summarization—most requests should land here.
Fast high-volume tier
Low unit cost (the illustrative cached input is $0.02/M). Fine for data cleaning, intent classification, high-frequency monitoring—and the best sidekick for bigger models.
Five real business scenarios—pick the tier you think fits best. Principle: never pay for expensive when cheap works, but don't skimp when being wrong is costly.
Tier first, then select: T0 for hard problems, T1 for daily work, T2 for volume. Most cost accidents are “using T0 to do T2's job.”
Cached price is 1/5 of standard—or lower. Whether you get that discount depends on your architecture (see Lesson 11).
Inside one model, prices can differ 2–3×. Tier-jump boundaries (output 200, input 32k) deserve more attention than model selection itself.
Source: The table is a teaching worksheet, not a provider quote. Model IDs, cache discounts, reasoning charges, regions, and retirement dates change constantly. Before selecting, verify the live pricing and data terms on the official OpenAI, Anthropic, Google, and DeepSeek pricing pages.
The complete interaction cost of “Price sheet panorama”
“Below is an illustrative USD-equivalent worksheet , not a live quote from any one provider.” is a reminder that AI cost is not one price multiplied by one call. Input, output, retries, tools, waiting time, and human cleanup together decide what a task really costs.
Find what the bill repeats
The key variables behind “Red numbers are prices “after a tier jump.” Inside the same model, prices can differ by 2–3×—those boundaries are the stars of Lessons 4, 5, and 6” are usually repeated context, oversized output, retries after failure, and calls that do not produce useful progress. Removing wasted Tokens can reduce cost, latency, and concurrency pressure at the same time.
A cheaper call can make the whole workflow more expensive
Start with “Inside one model, prices can differ 2–3×.” and keep a small table for input, output, retries, tools, and human review. Compare quality before and after optimizing instead of looking at one price in isolation.
From “Price sheet panorama” to “The Three Tiers”
“Price sheet panorama” grounds the problem in “Below is an illustrative USD-equivalent worksheet , not a live quote from any one provider. The three columns are non-cached input, cached input, and output per million Tokens. Real providers use different tier…”. “The Three Tiers” then moves it toward “Expensive output, capability ceiling. Leave for complex reasoning, code gen, multi-model arbitration—tasks where “getting it wrong costs more.””. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
When analyzing cost, map the complete interaction first, then find repeated input, wasted output, and retries. A cheap individual call does not make the whole task cheap.
- “Price sheet panorama”: Below is an illustrative USD-equivalent worksheet , not a live quote from any one provider. The three columns are non-cached input, cached input, and output per million Tokens. Real providers use different tier…
- “The Three Tiers”: Expensive output, capability ceiling. Leave for complex reasoning, code gen, multi-model arbitration—tasks where “getting it wrong costs more.”
- “The closing point”: Cached price is 1/5 of standard—or lower. Whether you get that discount depends on your architecture (see Lesson 11)
The final “The closing point” brings the discussion to “Cached price is 1/5 of standard—or lower. Whether you get that discount depends on your architecture (see Lesson 11)”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.