When enterprises deploy an AI customer service or knowledge-base chatbot, LLM API cost at 100k conversations a month can differ by 100x or more between the cheapest and most expensive model tier. This article compares official OpenAI, Anthropic, and Google pricing as fetched on September 15, 2026, and works through actual monthly costs at 10k, 100k, and 1M conversations so you can size your budget correctly before committing to a model.
Why "A Chatbot" Can Cost 100x More or Less
LLM APIs bill by the token — roughly a chunk of text smaller than a word (English averages around 4 characters per token). The cost gap comes from two variables: which tier of model you choose (a single vendor's economy and flagship models can differ in price by tens of times), and how many tokens each conversation actually consumes (driven by system prompt length, conversation history, and any retrieved knowledge-base content). Most companies evaluating a chatbot only ask "which model is smarter" without multiplying that against expected volume — which is exactly how the bill ends up far higher than anticipated after launch.
In practice, the token count a single agent consumes is often anything but fixed across conversation types: a one-line "what are your hours?" question and a complaint reply that has to cross-reference three contract clauses can differ by 10x or more in input tokens. If you estimate using a single average figure, you'll likely underestimate the real cost of peak-complexity conversations — it's worth modeling against a realistic distribution of conversation types before launch, not just one average conversation length.
Official Pricing Comparison, September 2026 (USD per Million Tokens)
The following prices were fetched directly from the OpenAI official pricing page, the Anthropic (Claude) official pricing page, and the Google Gemini API official pricing page on September 15, 2026.
| Vendor | Tier | Representative Model | Input (USD / 1M tokens) | Output (USD / 1M tokens) |
|---|---|---|---|---|
| OpenAI | Economy | GPT-5-nano | $0.05 | $0.40 |
| OpenAI | Mid-tier | GPT-5.6 Luna | $0.20 | $1.20 |
| OpenAI | Flagship | GPT-6 Astra (short context) | $10.00 | $50.00 |
| Anthropic | Economy | Claude Haiku 4.5 | $1.00 | $5.00 |
| Anthropic | Mid-tier | Claude Sonnet 5 | $2.00 | $10.00 |
| Anthropic | Flagship | Claude Opus 5 | $5.00 | $25.00 |
| Economy | Gemini 2.5 Flash-Lite | $0.10 | $0.40 | |
| Mid-tier | Gemini 3.8 Flash | $0.75 | $3.75 | |
| Flagship | Gemini 3.1 Pro Preview (≤200k tokens) | $2.00 | $12.00 |
All three vendors' economy-tier models sit close together on price. The real spread shows up at the flagship tier, especially on output pricing. Because enterprise chatbot replies tend to be short, input tokens usually dominate total usage — so in practice, input pricing often matters more than the flagship-tier headline numbers suggest.
Monthly Cost Worksheet: 10k / 100k / 1M Conversations
Assumption: each conversation averages 1,500 input tokens (system prompt, conversation history, and any RAG-retrieved snippets) and 400 output tokens. This is Noise & Signal's own estimate based on project experience, reflecting pure LLM API usage only — it excludes vector database, server, and staffing costs.
| Vendor / Tier | Cost per Conversation | Monthly @ 10k | Monthly @ 100k | Monthly @ 1M |
|---|---|---|---|---|
| OpenAI Economy (GPT-5-nano) | $0.00024 | $2.4 | $24 | $235 |
| OpenAI Flagship (GPT-6 Astra) | $0.035 | $350 | $3,500 | $35,000 |
| Anthropic Economy (Haiku 4.5) | $0.0035 | $35 | $350 | $3,500 |
| Anthropic Flagship (Opus 5) | $0.0175 | $175 | $1,750 | $17,500 |
| Google Economy (Flash-Lite 2.5) | $0.00031 | $3.1 | $31 | $310 |
| Google Flagship (Pro 3.1 Preview) | $0.0078 | $78 | $780 | $7,800 |
Two things stand out. First, within a single vendor, economy vs. flagship can differ by roughly 100x (OpenAI goes from $2.4 to $350 at 10k conversations). Second, at 100k conversations a month, picking the wrong tier can mean a difference of tens of thousands of dollars a year — which is exactly why model selection shouldn't be based on "which one is smartest" alone.
Is Self-Hosting an Open-Source Model Worth It?
Open-source models (Llama family, Mistral family, and similar) carry no per-token fee, but you have to rent or build GPU infrastructure and carry the engineering cost of operations and model updates yourself. At a mid-size company's 100k-conversation-a-month scale, the fixed cost of self-hosted GPU infrastructure — commonly a few hundred to a few thousand dollars a month depending on hardware — usually exceeds simply calling an economy-tier API. Self-hosting tends to pay off only once you're past several million conversations a month and already have GPU operations capability in-house. Based on our 2026 project experience, most SME clients scale other parts of the business well before they hit the volume where self-hosting becomes the cheaper option, so calling a hosted API remains the more practical starting point.
There's a maintenance dimension that's easy to underweight, too. When you call a hosted API, the vendor continuously swaps in improved model versions behind the scenes with no work on your end. Self-hosting an open-source model means your own team owns tracking upstream releases, deciding when to upgrade, and handling any behavior changes an upgrade introduces — engineering time that's frequently left out of the initial self-hosting cost comparison.
Worked Example: Sizing a Mid-Size Retailer's Support Bot
As a composite example based on patterns across similar projects, not any single named client, consider a retailer handling roughly 40,000 customer-service conversations a month across order status, returns, and product questions. An initial proposal defaulted to a flagship model for every conversation, penciling out near $700/month at Anthropic's flagship tier — reasonable-looking in isolation, but most of that volume was simple order-status lookups a much cheaper tier could handle just as well.
Re-architecting around tiered routing — an economy model handling roughly 75% of straightforward queries, escalating the rest to a mid-tier model, with only ambiguous complaint cases reaching the flagship tier — cut the estimated monthly bill by more than half without a measurable drop in resolution quality. The lesson generalizes: the model tier you'd pick for the hardest 10% of conversations is rarely the right default for the other 90%.
Ways to Cut Cost Beyond Choosing a Cheaper Model
- Cache frequent answers. Pre-cache responses to high-repetition questions (store hours, return policy) instead of calling the LLM every time.
- Shorten the system prompt. The system prompt is a fixed cost on every single conversation — trimming it directly reduces input tokens per conversation.
- Route simple questions away from the LLM. Use rule-based logic or keyword matching to filter simple queries, reserving LLM calls for questions that genuinely require language understanding.
- Control RAG retrieval size. The number and length of retrieved knowledge-base snippets directly drives input token count — tune retrieval parameters to keep this in check.
Common Mistakes to Avoid
- Looking only at per-conversation cost, not scale. A few cents per conversation looks trivial until you multiply it by hundreds of thousands of monthly conversations.
- Ignoring the hidden cost of output tokens. Most vendors price output at 5-10x input; if your agent tends to produce long-winded replies, cost rises disproportionately.
- Not setting a usage cap. LLM APIs have no built-in spending limit by default; if agent logic loops or gets abused, the bill can spike within hours.
- Treating the worksheet as a guarantee. Actual token usage fluctuates with conversation complexity — launch at a small scale first to observe real usage before scaling up the budget.
Choosing a Vendor Isn't Just About Price
Once you've sized the budget, price stops being the only variable that matters. A few practical factors we weigh on every project:
- Context window and document length. If your knowledge base includes long technical manuals or contracts, a model's maximum context window determines whether you can pass a full document as context or need to chunk it more aggressively — which itself affects RAG retrieval cost.
- Tool-calling and structured output reliability. An agent that needs to call internal APIs or return strict JSON for downstream systems needs a model with dependable function-calling behavior; cheaper models are more likely to produce malformed output that requires retry logic, which quietly adds to your effective token cost.
- Rate limits and latency. High-traffic customer service use cases need to check a vendor's requests-per-minute and tokens-per-minute limits at your target tier, not just the headline price — hitting a rate limit mid-conversation is a worse outcome than paying slightly more per token.
- Data handling and contractual terms. Enterprise customers in regulated industries should review each vendor's data retention and training-opt-out policies before committing, since these differ by vendor and by API tier.
None of these factors show up in a per-token price comparison, but they can eliminate an otherwise-cheap option from consideration entirely, or justify paying a premium for a specific use case.
A Multi-Model Strategy Often Beats Picking One Vendor
Few enterprise deployments we've built actually run on a single model for every request. A more common pattern is tiered routing: use an economy-tier model as a first-pass classifier or for simple factual lookups, and only escalate to a mid-tier or flagship model when the conversation is flagged as complex, ambiguous, or high-stakes (for example, anything involving a refund, a complaint, or a request the agent isn't confident about). Because economy-tier models are often 10-50x cheaper than flagship models on the same vendor, routing even 70-80% of traffic through the cheaper tier can cut total LLM spend substantially while keeping response quality high on the conversations that actually need it. The engineering cost of building this routing logic is modest compared to the ongoing savings once conversation volume climbs into the six-figure-per-month range.
How Model Choice Interacts with Architecture
Model pricing is only half the picture — how you architect the agent changes how much of that pricing you actually pay. A chatbot that re-sends the entire conversation history on every turn burns far more input tokens than one that summarizes older turns and only keeps recent context in full. Similarly, a RAG pipeline that retrieves ten document chunks per query costs several times more than one tuned to retrieve three well-ranked chunks. Neither of these choices shows up in a vendor's pricing page, but both can move your actual bill by 2-3x independent of which model you pick — which is why the worksheet above should be treated as a starting point for architecture decisions, not just model selection.
How to Read These Numbers
The per-conversation costs in this article are built on one assumption — 1,500 input tokens plus 400 output tokens per conversation — which is Noise & Signal's own estimate from project experience, used to illustrate how cost scales with model tier and volume. It isn't a guarantee for your specific project. Real token usage varies with system prompt length, conversation turns, and how much your RAG pipeline retrieves: a short yes/no customer-service exchange can run well below this assumption, while multi-turn reasoning or long-document comparison can run well above it.
Treat the worksheet above as a tool for sizing the right order of magnitude during model selection. Before signing a contract, test a small batch of real conversations, measure actual average token usage, and re-run the math against official pricing — that gives you a budget number grounded in your own use case rather than this article's assumption.
Next Steps
If you're budgeting the annual cost of an enterprise AI chatbot or knowledge-base agent, start by estimating expected conversation volume and typical conversation length, then use the worksheet above to land on a realistic model tier. Noise & Signal handles model selection, RAG architecture design, and post-launch usage monitoring as part of our full build process — see our AI Agent Development Services page for how we help enterprises keep LLM operating costs under control. For a side-by-side comparison of timelines and pricing across our services, see our Process & Pricing page.