How to Estimate the Cost of an AI Chatbot Before You Build It

Most chatbot cost estimates are wrong because they only price the first message. A support bot doesn't send one API call per conversation — it sends one call per turn, and every turn after the first has to include everything that came before it. That compounding is the single biggest reason teams get a $200/month pilot and a $4,000/month production bill on roughly the same traffic.

Estimate the Conversation, Not the Message

A "conversation" is a sequence of turns. Each turn is one API call. Unless you're using prompt caching, most chat implementations resend the full message history on every turn, because the model has no memory between calls — your server is the memory. That means turn 4 of a conversation costs more than turn 1, even if the user typed the exact same sentence, because turn 4's input includes turns 1 through 3.

This is the detail that separates a real estimate from a guess. If you only budget for "average tokens per message," you're pricing turn 1 and calling it representative.

Build a Per-Turn Token Budget

Break every turn into four components:

• System prompt + tool definitions. Instructions, brand voice, safety rules, and JSON schemas for any tools the model can call. A lean support bot runs 200-400 tokens here; one with five or six tool definitions (order lookup, refund, inventory check) can run 800-1,500 tokens, and that cost repeats on every single turn.
• Retrieved context (if you use RAG). Chunks pulled from a knowledge base to ground the answer. Typically 300-1,200 tokens per turn depending on chunk size and how many chunks you retrieve — see our vector database pricing guide if retrieval is part of your design.
• Conversation history. Every prior user message and assistant reply in the thread, resent verbatim unless you summarize or truncate it.
• The new user message and the model's reply. Usually the smallest piece of the budget, and the one most estimates focus on exclusively.

Worked Example: A 4-Turn Support Conversation

Assumptions, stated explicitly so you can swap in your own numbers:

• System prompt + tool schema: 400 tokens, sent on every turn
• Average user message: 40 tokens
• Average assistant reply: 120 tokens
• Conversation length: 4 turns before resolution
• No RAG, no prompt caching — the worst case for cost

Because history accumulates, the four turns cost 440, 600, 760, and 920 input tokens respectively — not four identical 440-token calls. Summed across the conversation:

• Total input tokens per conversation: 2,720
• Total output tokens per conversation: 480

At 5,000 conversations a month, that's 13,600,000 input tokens and 2,400,000 output tokens. Here's what three commonly used chatbot models charge for that exact volume:

• Claude Haiku 4.5: $25.60/month
• GPT-4o mini: $3.48/month
• Gemini 2.5 Flash: $10.08/month

Now compare that to the naive "first message only" estimate — pricing a single 440-token input and 120-token output, times 5,000: $5.20/month on Claude Haiku 4.5. The naive estimate undercounts input tokens by 84% for this conversation shape — and the gap gets worse the longer your average conversation runs.

Model Prices for Common Chatbot Workloads

These are the models teams most often reach for on support and FAQ bots — a mix of low-cost workhorses and a couple of mid-tier options for conversations that need more reasoning:

How the Bill Scales as You Grow

Using the same 4-turn conversation shape from the worked example, here's what the bill looks like at three volume tiers on two representative models — one budget-tier, one mid-tier:

Notice the cost scales linearly with volume once the per-conversation shape is fixed — the nonlinearity lives entirely in turns-per-conversation, not in conversation count. That's why the single most valuable thing you can do before launch is get a real number for average turns per conversation, even from a rough manual test, rather than iterate on your volume forecast.

What Prompt Caching Changes

Most major providers now offer some form of prompt caching: the static parts of your input — the system prompt, tool definitions, and any content that repeats turn to turn — can be cached so you pay a reduced rate to reread them instead of the full input price. The discount and minimum cacheable length vary by provider and change over time, so treat this as a lever to model, not a number to bake into your forecast. As a rough, approximate rule of thumb, caching mainly helps the fixed parts of your budget (system prompt, tool schemas, RAG context that's reused across a session) — it does little for the part that grows every turn, which is the conversation history itself.

Non-Token Costs to Budget For

Inference is usually the smallest line item once you're past a pilot. Typical, approximate ranges for the rest of the stack:

• Application hosting: $10-50/month on a small PaaS instance for low volume; scales with concurrency, not conversation count directly.
• Vector database (RAG only): free tiers exist up to roughly 100K-1M vectors on most providers; expect $25-70/month once you outgrow the free tier. Full comparison in our vector DB pricing breakdown.
• Observability/logging: $0-100/month depending on whether you self-host or use a hosted LLM observability tool.
• Human escalation: the conversations the bot can't resolve still cost a human agent's time — budget this against your current support cost per ticket, not against the bot's API bill.

Common Estimation Mistakes

1. 1. Pricing only the first turn. As shown above, this can understate a real conversation's cost by 30-50% or more.
2. 2. Assuming pilot volume equals production volume. Pilots run with 10-20 friendly internal testers. Production traffic is spikier, includes adversarial or off-topic messages that run longer, and arrives at 10-100x the pilot's volume within weeks of launch.
3. 3. Forgetting output tokens cost more than input. Across nearly every provider, output tokens are priced at 3-5x the input rate. A chatbot that rambles instead of answering concisely pays for it disproportionately — see our prompt optimization playbook for concrete ways to cap this.
4. 4. Ignoring tool-call overhead. Every tool the model can invoke adds its schema to every turn's input, and every tool result gets appended to history and resent on subsequent turns. A bot with three active tools can easily double its per-turn input budget compared to a bot with none.
5. 5. Not modeling failure and retry rates. Rate limits, timeouts, and malformed tool calls mean a fraction of turns get retried. A 3-5% retry rate is a reasonable planning buffer for a new integration.

A Five-Step Estimation Worksheet

1. 1. Estimate monthly conversations (start from support ticket volume or expected user base, then discount by 50-70% for a conservative first estimate).
2. 2. Estimate average turns per conversation from a similar existing product, or assume 3-5 for a first guess.
3. 3. Build the per-turn input budget: system prompt + tools + RAG context + running history + new message.
4. 4. Sum input and output tokens across all turns in a conversation, then multiply by monthly conversation volume.
5. 5. Run that volume through two or three candidate models and compare — then add 15-25% for retries, tool overhead, and off-happy-path conversations.

Our Chatbot Cost Calculator runs this worksheet for you — enter conversation volume, turns, and token estimates, and it prices the result across every model in our catalog side by side.

FAQ

Do I need to price every message in a conversation separately?

Not by hand — but your estimate needs to account for the fact that later turns carry more input tokens than earlier ones. Summing a conversation's turns (as in the worked example above) rather than multiplying a single "average message" by turn count gets you a materially more accurate number.

How much should I budget for a pilot vs. production?

Price the pilot at your best estimate, then plan production budget at 3-5x that figure until you have a month of real usage data. Traffic patterns, conversation length, and escalation rate all tend to look better in a controlled pilot than in the wild.

Is a cheaper model always the right first move?

Only if it holds up on quality. See our guide on picking the cheapest model that's still good enough — a bot that has to re-ask clarifying questions or escalates more often because the model is too weak can end up costing more overall, even at a lower per-token price.

What's the single highest-leverage number to get right?

Average turns per conversation. It affects both token volume (linearly, on output) and token growth (roughly quadratically, on input, since history compounds). Getting this number from real data — even a small manual test with 20-30 users — beats any other assumption you could tune.

For the pricing mechanics behind every number in this guide — how input, output, context, and caching actually get billed — read LLM pricing explained.