Downgrading is the last lever, not the first
Moving from Opus 4.8 to Sonnet 4.6 cuts per-token prices by 40 percent, and it re-rolls every answer your product gives. That is the trade most teams reach for first, and it is usually premature, because two bigger discounts are already sitting on the price sheet for the model you run today: prompt caching reads repeated context at roughly a tenth of the input price, and the Batch API takes a flat half off anything that can wait. Neither changes a single answer. They stack. And if you apply them first, the downgrade you were bracing for often stops being necessary.
To keep the numbers honest we will keep working on the same patient: the support chatbot whose $1,460 invoice we took apart in part one. Four levers, applied in order, no model switch for the traffic that matters:
| Item | Amount |
|---|---|
| Part 1 invoice | $1,460 |
| + prompt caching | $1,332 |
| + routing | $799 |
| + output trim | $673 |
The part 1 chatbot, four levers later
Opus 4.8, 10,000 conversations / month · levers applied left to right
Modelled on part 1's assumptions (10,000 four-turn conversations; a 1,500-token system block; 500-token questions, 700-token answers; Opus 4.8 at $5 / $25 per 1M). Caching uses 5-minute windows and honours Opus 4.8's 4,096-token minimum cacheable prefix, so it only starts paying from turn 3. Routing sends the easier half of conversations to Haiku 4.5 ($1 / $5) and changes those answers. Trimming cuts answers ~30% with the input left unchanged, which keeps the estimate conservative.
Lever 1: prompt caching, the discount hiding in your repeated context
Part one showed that re-sent context is the biggest line on a conversational bill: the same system prompt and the same growing history, billed again on every turn. Caching attacks exactly that line. You mark the stable prefix of your request, pay a one-time premium to write it (1.25x the input price on the 5-minute tier, 2x on the 1-hour tier), and every later request that starts with the same bytes reads it back at roughly a tenth of the price.
| Cache tier | Write premium | Read price | Pays for itself |
|---|---|---|---|
| 5-minute | 1.25x input price, once | ~0.1x input price | On the 2nd use of the prefix |
| 1-hour | 2x input price, once | ~0.1x input price | On the 3rd use |
Two honest caveats before you pencil in 90 percent. First, the discount applies to the cached portion, not the bill: our chatbot drops from $1,460 to $1,332, a 9 percent cut, because its conversations are short. On Opus 4.8 nothing below 4,096 tokens can be cached at all, so a four-turn chat only crosses that threshold on turn three; the deepest, most expensive turns get the discount, the early ones do not. Second, the write premium means caching a prefix nobody reuses is a way to pay extra. Caching shines where context is big or conversations run deep, which is exactly where part one said the pain lives.
Lever 2: the Batch API, a flat half off everything that can wait
The Batch API is the simplest discount in the catalogue: submit work asynchronously, get results back within minutes to hours, pay 50 percent of the standard price on every token in the job, cached tokens included. There is no quality trade at all; it is the same model producing the same answers, just not while anyone watches a spinner.
The catch is the definition of "can wait". A customer mid-conversation cannot, so our chatbot's live traffic gets nothing from this lever, and that is why it does not appear in the waterfall above. But almost every AI product carries a shadow workload that can wait: the nightly summaries of those support conversations, bulk classification, report generation, content pipelines. Price those separately and batch them by default; paying the live rate for work no one is waiting on is the quietest leak in most bills.
Lever 3: route by difficulty, not by default
Not every conversation needs your best model. Password resets and delivery-status questions do not require Opus 4.8; they require a correct lookup and a polite sentence, which Haiku 4.5 delivers at $1 / $5 per million tokens, five times cheaper per token. In our model, sending the easier half of conversations to Haiku takes the bill from $1,332 to $799, the single biggest step in the waterfall.
Treat this lever differently from the previous two, because it is the first one that changes outputs. Caching and batching return identical answers; routing gives the routed slice a different model. The discipline that keeps it safe: classify conservatively, route only the traffic a cheaper model provably passes on your own test set, and keep an escalation path back to the big model the moment the conversation stops being easy.
Lever 4: trim the output side, because it bills at five times input
Every Claude model prices output tokens at exactly five times input, so the length of your answers is a pricing decision, whether or not you made it deliberately. Support answers padded with restated questions and closing pleasantries cost real money at volume. Instructing the assistant to answer in the shortest form that fully resolves the ticket cuts our modelled answers by about 30 percent and the bill from $799 to $673, and on the Opus family the effort setting is the same dial one level up: turn it down for routine traffic and the model spends fewer reasoning tokens getting to the same place.
The limit here is not technical but human: trim past the point of usefulness and answers start reading as curt, which shows up later as repeat contacts. Cut the padding, keep the substance.
Where the 50 to 90 percent actually comes from
Stack the levers on our chatbot and the invoice lands at $673, 54 percent below where part one left it, with the hard half of the traffic still on the exact same model producing the exact same answers. Whether your own number lands nearer 50 or 90 is decided by two properties of your workload: how much of your input is repeated context, and how much of your work can wait.
| Workload | Saved |
|---|---|
| Live support chatbot | -54% |
| Nightly document pipeline | -64% |
| Async agent, heavy shared context | -88% |
How deep the cut goes depends on the shape
Share of the monthly bill saved, modelled per workload
Three modelled workloads, same models throughout. Chatbot: part 1's assumptions plus the three levers above ($1,460 to $673). Pipeline: 60,000 documents a month on Sonnet 4.6 ($3 / $15), a 2,500-token shared instruction block (cached) plus a 3,000-token document in and 500 tokens out, run overnight through the Batch API ($1,440 to $518). Agent: 100,000 async calls a month on Opus 4.8 with a shared 10,000-token context pack kept warm, 200 in / 300 out per call, batched ($5,850 to $675). Cache hits inside Batch runs are best effort, so treat the right ends as ceilings.
A live chatbot sits at the modest end, because short conversations cache late and none of the live traffic can be batched. A nightly document pipeline does better: its instruction block caches perfectly and every token in the job takes the batch discount. And the async agent with a large shared context pack is the shape the discounts were made for; nine-tenths of its input reads from cache and the whole run batches, so 88 percent of the bill simply leaves.
The eligibility check
Before you touch the model string, walk your workload down this table once.
| Lever | Your workload needs | Realistic saving | Watch out |
|---|---|---|---|
| Prompt caching | A stable prefix above the model minimum, reused within the cache window | ~90% off the repeated portion | Write premium backfires below 2-3 reuses; short chats start caching late |
| Batch API | Tolerance for minutes-to-hours of latency | Flat -50% on the whole job | Never for a waiting user; cache hits inside batches are best effort |
| Routing by difficulty | A slice of traffic a cheaper model provably handles | Up to 5x on the routed slice | Changes outputs; test quality first and keep an escalation path |
| Output trim + effort | Output-heavy bills (output prices at 5x input) | Proportional to the cut | Too aggressive reads as curt, incomplete answers |
Run the audit in this order: caching first if any context repeats, batch everything a user is not waiting on, trim the output you were never reading anyway, then route the provably easy slice. Only when all four are in place does the downgrade question deserve an answer, and by then it is a much smaller question. And if the number you land on still feels too high for what the feature earns, the question is no longer how to run it cheaper; it is whether it should exist at all, which is exactly what part three is for.
