Customer support is one of the most common production LLM use cases, and also one of the easiest to get wrong on cost, because a single conversation can span many turns and each turn resends growing context. Choosing a model here is less about which provider is generally strongest and more about matching model tier, context handling, and cost structure to a support workload's specific shape.
What Actually Matters for Support Workloads
Support bots need reliable grounding in a knowledge base or policy document, consistent tone, and graceful escalation when the model is uncertain, more than they need frontier-level reasoning. This means the flagship tier of any provider is often overkill for the majority of straightforward tickets, and a mid-tier or lightweight model handles routine questions like order status, return policy, or account settings just as well at a fraction of the cost.
Multi-turn context handling matters more here than in most other use cases, since a support conversation can run ten or more turns, each resending the growing history. This makes prompt caching on the conversation prefix and the injected knowledge base content one of the highest-value optimizations for this specific use case, regardless of which provider you choose.
A Tiering Approach Across Providers
Rather than picking a single model for all support traffic, route by query complexity. A lightweight tier, such as Claude Haiku, GPT's smaller mainline model, or Gemini Flash-Lite, can handle FAQ-style and account-lookup queries directly. Route only genuinely ambiguous, emotionally sensitive, or multi-issue conversations to a stronger flagship model.
This tiering approach is provider-agnostic; the specific model names change over time, but the pattern of routing simple traffic to the cheapest capable tier and reserving flagship reasoning for hard cases holds regardless of which provider's lineup you standardize on.
Evaluating Providers for Your Specific Knowledge Base
The right choice often comes down to how well a given model follows grounding instructions and refuses to answer outside the provided knowledge base, since a support bot that hallucinates policy details creates real business risk. Run a held-out evaluation set of real historical tickets against each candidate model and score for groundedness and appropriate escalation, not just fluency.
Latency also matters more here than in offline tasks: a support widget with a multi-second delay per response measurably hurts user satisfaction. Benchmark time-to-first-token and full response latency for your actual prompt length, not just the provider's published average, since a long injected knowledge base document can change latency behavior significantly.
Cost Structure Specific to Support
Model your cost per resolved conversation, not per API call, since a single ticket might involve several back-and-forth turns before resolution. This metric lets you compare a cheaper model that takes more turns to resolve an issue against a stronger model that resolves in fewer turns, which is not always the trade-off it first appears to be.
Cap conversation length with a fallback to human handoff after a set number of turns without resolution. This protects both cost and user experience, since an unbounded conversation loop is both expensive and a sign the bot is failing the user.
Key takeaways
- Route routine FAQ and account-lookup queries to the cheapest capable model tier.
- Cache the knowledge base content and growing conversation prefix, since support chats run many turns.
- Evaluate groundedness and appropriate escalation on real historical tickets, not generic benchmarks.
- Measure cost per resolved conversation, not per API call, to compare models fairly.
- Set a maximum turn count with automatic human handoff to bound both cost and user frustration.
Bottom line
There is no universally cheapest provider for customer support; the right choice depends on your knowledge base structure, conversation length, and how well a model follows grounding instructions on your specific content. Tiering by query complexity and measuring cost per resolution, rather than per call, gives a far more accurate picture than comparing sticker prices alone.