The short answer
A customer-support chatbot handling 1,000 conversations per day at about five turns each makes roughly 150,000 model calls in a 30-day month. The bill then depends on the input sent on each turn, output length, model, and the share of input that qualifies for caching.
- Efficient models: test first for routine support and FAQ retrieval.
- Balanced models: use when evaluation shows the efficient tier misses important reasoning cases.
- Frontier models: reserve for complex or high-stakes queries that justify the added cost.
Use the calculator for the current dollar estimate. This guide explains the four inputs that most often cause a forecast to miss.
Want a number for your exact volume? The AI Cost-per-Task Calculator has a chatbot template — set your conversations/day and turns, and it models the cost across every major model instantly.
Lever 1 — Model choice
The price gap between efficient and frontier models in 2026 is material. On output tokens — which dominate chatbot cost because the model talks back — use the current pricing table instead of a static rate copied into a guide.
The strategic insight most teams miss: a support or FAQ chatbot rarely needs a frontier model. Answering "what's your refund policy" from a knowledge base is not a reasoning-hard task. Efficient models handle it indistinguishably from frontier models in blind tests. Paying GPT-5.5 prices for FAQ answers is the most common — and most expensive — mistake in production chatbots.
When does a frontier model earn its price? When the chatbot must reason over ambiguous, multi-step, or high-stakes queries — medical triage, legal interpretation, complex troubleshooting where a wrong answer is costly. For those, the premium is justified. For everything else, start cheap and only upgrade if quality testing demands it.
Lever 2 — Prompt caching (the 40–55% lever)
Every chatbot has a system prompt — the instructions, tone, and often a chunk of knowledge base — sent on every single turn. It's identical each time. Without caching, you pay full input price to re-send it on every message.
Prompt caching fixes this. Anthropic, OpenAI, Google, and DeepSeek offer ways to discount eligible repeated input, but the rate, minimum cache length, and expiry behavior differ. Measure how much of the prompt actually qualifies before forecasting the saving.
This is free money that teams routinely leave on the table. If you're running a chatbot without prompt caching enabled, that is almost always the first optimization to make — bigger impact than switching models in many cases.
Lever 3 — Conversation length (the hidden multiplier)
Here's the trap that surprises people. A chatbot doesn't cost "X per conversation." It costs X per turn, and conversation history grows with each turn because the model needs the full thread as context.
By turn five, you're sending the system prompt plus four previous exchanges plus the new message. So a ten-turn conversation doesn't cost twice a five-turn one — it can cost three to four times as much, because later turns carry much more context.
The practical lever: keep conversations focused. A chatbot that resolves issues in three turns is not just better UX — it's materially cheaper to run than one that meanders through ten. Design for resolution, not engagement.
Lever 4 — Volume (and why batch doesn't apply here)
Cost scales linearly with conversation volume, which is obvious. The less obvious point: real-time chatbots can't use the batch API discounts(typically 50% off) that classification and summarization workloads can, because users are waiting for a response. So a chatbot's per-token cost is the full real-time rate. Plan around that.
Worked workload: 1,000 conversations/day
Let's cost a realistic support chatbot: 600-token system prompt, five turns per conversation, ~100-token user messages, and ~250-token responses. The provider determines what repeated input is cache-eligible.
- Calls/month: 150,000
- Input shape: system prompt plus growing conversation history
- Output shape: about 250 tokens per response
- Cache assumption: only the provider-eligible repeated share
Enter these assumptions in the calculator and compare the current model dataset. Then replace the defaults with token logs from a pilot before committing to a production budget.
These ranges come straight from the AI Cost-per-Task Calculator. Plug in your real numbers — it models caching and conversation growth automatically. For raw token-level pricing across the current dataset, see the LLM API Cost Calculator.
The three mistakes that triple a chatbot bill
- Defaulting to a frontier model.Teams reach for the most capable model "to be safe" and pay 10–20× more than needed. Start with an efficient model; upgrade only if quality testing forces you to.
- Not enabling prompt caching. Re-sending the same system prompt at full price on every turn. Free 40–55% saving left unclaimed.
- Letting conversations sprawl. Every extra turn carries the whole thread. Long chats cost super-linearly. Design for fast resolution.
Fix all three and a chatbot bill commonly drops by 60–80% with no loss in answer quality. That's the difference between a feature that's "too expensive to ship" and one that's comfortably profitable.
FAQ
What's the cheapest way to run a chatbot?
Start with efficiency-focused candidates and prompt caching where eligible. Test representative support questions, choose the least expensive model that clears your quality bar, and design conversations to resolve quickly.
Should I use one model for everything?
Not necessarily. A common pattern is "model routing": send simple queries to a cheap model and escalate only genuinely hard ones to a frontier model. This can cut costs substantially while preserving quality where it matters. It adds engineering complexity, so weigh it against your volume.
Do embedding/RAG costs change this?
If your chatbot retrieves from a knowledge base (RAG), add the retrieval-call cost on top. Embedding costs for indexing are usually trivial (rounding error vs generation). The bigger RAG cost is the retrieved context you stuff into each prompt — see the RAG template in our cost calculator.
How accurate are these estimates vs my real bill?
Within 10–20% for typical workloads. Variance comes from your actual token distribution, batch discounts (not applicable to real-time chat), and enterprise volume pricing. Log a week of real usage for precision, then model it.
Pricing verified 2026-06-28. This is general guidance, not a quote — always confirm current rates on the vendor pricing page before committing to a workload.