If you just want the recommendation: choose the LLM API that produces the lowest cost per successfully resolved customer-support conversation while meeting your latency and correctness SLOs, then put a compatibility layer and an idempotent write boundary around it. A cheap token that triggers escalation, repeats a tool action, or forces a larger prompt isn't cheap.
I learned that distinction from an in-app chatbot incident, and it changed how I run model evaluations. I don't start with a public price sheet now. I start with a replay set, the support operations the bot may perform, and an error budget. GPT, Claude, Gemini, and OpenAI-compatible runtimes can all enter the test; their names do not get to decide the result.
The uncomfortable answer is that there is no permanent cheapest LLM API for every customer support chatbot. Traffic shape, context length, retry behavior, tool calls, cache policy, escalation rate, and on-call ownership move the total. Your mileage may vary.
Why did a cheap retry make our support bot more expensive?
One Friday, our client timed out after asking a model to summarize a case and append an internal note. The naive retry ran the whole operation again. We found 37 conversations with two note writes before the alert fired; the model response itself was acceptable both times, but our application had confused retrying generation with retrying a side effect. That was the only number I needed to stop treating token price as the primary selection metric. The invariant was sharper: a model request may be repeated, while a business operation must have one stable identity and an observable terminal state.
