A $9,000/month support bot dropping to $500/month sounds like marketing rounding. It isn't, for one specific reason: support chatbots are the workload where the two biggest cost levers — model routing and caching — both apply at their strongest simultaneously. Here's the mechanism, worked through step by step, so the number is something you can verify against your own traffic instead of taking on faith.

TL;DR

1. Routing simple support queries off a frontier model to a cheap-tier one is roughly a 5x cost reduction on its own.
2. Support traffic is unusually repetitive, so caching catches far more of it than typical mixed traffic — published data shows up to 95% hit rates on FAQ/support workloads specifically.
3. Routing and caching compound multiplicatively, not additively, which is how a 5x reduction and an 80%+ cache hit rate together produce a 90%+ total cut.

What this is: a worked, illustrative model built from real, cited pricing multipliers and published caching benchmarks — not a single verified customer case with a name attached. The mechanism and the math are real; treat the exact dollar figures as directionally accurate for this workload shape, not a guarantee for every support bot.

The Starting Point

A support chatbot running entirely on a frontier-tier model (Claude Opus-class, at $5/$25 per million tokens input/output) for every conversation, including the simple, high-volume ones that make up most support traffic — return policy questions, shipping status, account access, the same handful of topics repeating constantly. That undifferentiated setup is the $9,000/month baseline.

Step 1: Route the Simple Majority to a Cheap Tier

Route ~80% of traffic to Haiku 4.5 ($1/$5 — a 5x rate cut) $9,000 → ~$3,240

Support conversations skew heavily toward simple, pattern-based exchanges. Testing against historical transcripts typically shows 70-85% of conversations are confidently routable to a cheaper model with no measurable quality loss, keeping only genuine escalations and ambiguous cases on the stronger tier. At a 5x rate difference between Opus and Haiku tiers, routing 80% of volume produces roughly a 64% reduction on its own.

Step 2: Cache the Repetition

Cache hits on the routed (Haiku-tier) traffic at up to 95% hit rate ~$3,240 → ~$700-900

This is where support bots specifically pull ahead of typical mixed-traffic workloads. Helicone's published production data shows cache hit rates reaching up to 95% on FAQ and support-deflection workloads — far above the 20-30% blended rate typical across general traffic — because the underlying questions genuinely repeat at high volume. A cache hit costs a small fraction of a fresh call, so an 80%+ hit rate on the routed traffic compounds the routing savings rather than just adding to them.

Step 3: Prompt Optimization on What's Left

Trim system prompt bloat, tighten output length on cache misses ~$700-900 → ~$500

The remaining traffic — genuine cache misses plus the smaller Opus-tier escalation share — still benefits from the standard prompt audit: removing stale few-shot examples, tightening response length constraints. On a workload that's already been cut this far, even a modest additional reduction on the remainder closes most of the rest of the gap.

Want to see if your support bot fits this pattern?

Preto flags the routing and caching opportunity specifically — free to check.

See Your Chatbot Costs — Free

See what routing and caching could do for your support bot. Free to start.

Why This Compounds Instead of Adding

The instinct is to add the percentages — "a 64% cut from routing plus an 80% cut from caching equals a 144% cut," which is nonsensical. What actually happens is multiplicative: caching applies to the already-reduced Haiku-tier cost, not the original Opus-tier cost. $3,240 reduced by an 80%+ hit rate on cheap-tier calls lands in the hundreds, not the thousands — the compounding is what turns two individually-moderate cuts into one dramatic one.

This is also why the mechanism doesn't generalize cleanly to every LLM feature. A workload with less routable traffic (more genuinely complex tasks) or less repetitive traffic (unique, non-cacheable requests) won't see the same multiplicative effect — support bots specifically sit at the intersection of "mostly simple" and "mostly repetitive," which is a rarer combination than it might seem.

Verifying This Against Your Own Bot

The way to know if your support workload fits this pattern, rather than assuming it does: check what share of conversations are confidently routable to a cheap-tier model against your own historical transcripts, and check your actual cache hit rate once exact-match and semantic caching are running. If both numbers land in the ranges above — 70%+ routable, 70%+ cacheable on the routed traffic — a reduction in this range is realistic. If either number is meaningfully lower, the achievable cut will be smaller, and that's worth knowing before promising a specific number internally.

Frequently Asked Questions

Can a support chatbot really cut LLM costs by 90%+?
Support chatbots are unusually well-suited to it, because model routing and caching both apply at their strongest in this workload. Most support conversations are simple and don't need a frontier model, and support traffic is highly repetitive — exactly what caching catches. A 90%+ reduction is realistic for this workload shape specifically, not a number that generalizes to every LLM feature.
Does switching from Opus to Haiku hurt support quality?
Not if done as routing rather than a blanket downgrade. Test the cheaper model against historical transcripts first, route only genuinely simple cases to it, and keep escalations and ambiguous cases on the stronger model.
Why does caching work especially well for support bots?
Support conversations repeat far more than most LLM workloads — a handful of topics account for a large share of volume. Helicone's published data shows cache hit rates up to 95% on FAQ and support-deflection workloads specifically, well above the 20-30% typical blended rate.
Is this a real customer result or an illustrative example?
This is a worked, illustrative model built from real, cited pricing multipliers and published caching benchmarks, not a single verified case study — the goal is to show the mechanism and the compounding math clearly.

Check if your support bot fits the pattern.

Preto shows your actual routable share and cache hit rate — the two numbers that determine whether a cut this size is realistic for your workload.

See Your Chatbot Costs — Free

Free forever up to 10K requests. No credit card required.

Gaurav Dagade
Gaurav Dagade

Founder of Preto.ai. 11 years engineering leadership. Previously Engineering Manager at Bynry. Building the cost intelligence layer for AI infrastructure.

LinkedIn · Twitter