AI support agent cost per month: the per-ticket maths

"How much will an AI support agent cost us each month?" has two answers, and they can differ by a factor of fifty. One is what the language model costs for each conversation, which you can work out to the cent from a provider's price list. The other is what a support-automation product charges, which includes the model and a lot more. This guide works out the first one in full, with every assumption stated, and then shows where the second one sits. All model prices are in US dollars per million tokens, checked on each provider's own pages on 2 November 2026. The conversation size is an illustration, not a measurement: replace it with your own numbers.

What you pay for

A support agent that answers customers from your help centre has four cost lines:

• Model tokens: every message the agent reads and writes. This is the line this guide calculates.
• Search and retrieval: finding the right help articles for each question. Retrieved text is added to the prompt, so it also shows up as tokens.
• The platform or the build: either a vendor's subscription and per-conversation fees, or the engineering time to build and run it yourself.
• People: the agents who handle what the AI cannot, and whoever reviews its answers. For most teams this stays the largest line even after automation.

The example conversation

A customer talks to the agent for five turns. Each time the agent is called, the model receives:

• 2,500 tokens of fixed instructions: role, tone, policies and rules. The same on every call, so it can be cached.
• 2,000 tokens of retrieved help-article text: different for each question, so not cached.
• 500 tokens of conversation so far and the new question: also different each time.

The model replies with 250 tokens. Over five turns, one conversation reads 12,500 fixed tokens and 12,500 changing tokens, and writes 1,250 tokens. Reasoning models also bill their thinking tokens as output, so a model that thinks before answering will write more than the visible 250 tokens; we show that effect below.

Model cost per ticket

The table prices that conversation on current models, first with no caching, then with the fixed instructions read from the cache at the provider's cached-input rate. Cache-write charges are left out, because on steady traffic the cache is written rarely compared with how often it is read; our prompt caching guide has the write prices and lifetimes.

Claude Fable 5.1 has the same input and output prices as GPT-6 Astra but a cheaper cache read ($0.25 against $1.00), so on this conversation it costs about $0.19 rather than $0.20 with caching. Fable 5.1's cache read is cheaper, but the fixed prompt is only half the input here, so the difference is small. Everything else in the table is identical between the two providers at each tier. A conversation on a small model costs a fraction of a cent; the same conversation on a flagship costs 100 times as much. Whether the small model answers well enough is the question that matters, and it is worth testing on real tickets before assuming either way.

Cost per month at 10,000 tickets

Two things stand out. Caching the instructions saves 36% to 38% on every model here, no more, because 12,500 of the 25,000 input tokens repeat and the rest do not. A support agent with a longer fixed prompt, such as a large policy document in every call, saves more; one that mostly passes retrieved articles saves less. And the last column shows that output length matters more than it looks: if the model writes three times as many tokens (for example because it thinks before answering), the bill rises by about 60% to 65% even though input is still the larger share of tokens, because output tokens cost five times as much as input tokens on every model here. Measure your real output tokens, including thinking tokens.

From cost per ticket to cost per resolved ticket

Not every conversation ends with the customer's problem solved. The ones handed to a person still cost tokens. The number to track is the cost per resolved conversation:

cost per resolved ticket = cost per conversation ÷ resolution rate

At a 60% resolution rate, a Sonnet 5.5 conversation costing $0.039 with caching becomes about $0.065 per resolved ticket. At 40% it is about $0.097. The model price barely moves; the resolution rate does. A cheaper model that resolves fewer tickets can cost more per resolved ticket than a dearer model that resolves more, once the human time for the failed conversations is counted. This is why the cheapest model is not automatically the right one, and why testing on your own tickets comes first.

Platform prices

Support-automation products bundle the model with retrieval, a chat interface, analytics, handoff to staff and support. They price in different ways, so they are hard to compare with a token bill. Three published examples, all from the vendors' own pricing pages checked on 2 November 2026:

The comparison uses the same 60% resolution rate as above, which is an assumption, not a vendor figure. Intercom's page also lists seat prices on its plans and a standalone Fin option with no seats, and Zendesk charges per agent seat on top of resolutions; those are not included here, and Intercom's page does not say what counts as an outcome. Against these figures, the model tokens for the same 10,000 conversations on Claude Sonnet 5.5 or GPT-6.1 Sol with caching are $388, or about $0.065 per resolved ticket.

That gap is not a verdict on the products. A platform price covers work our table leaves out: retrieval, the interface, handoff, reporting, support and the engineering you would otherwise do yourself. But it shows why the rate card deserves a close read: a per-outcome or per-conversation fee scales with your ticket volume, while the model cost underneath it is a small share of the price. If you are comparing vendors, ask what is billed (conversation, message, resolution or action), what counts as a resolution, whether a failed conversation is billed, and which model runs underneath. If you are considering building your own agent, the table above is your model cost; the build, the evaluation and the monitoring are the rest.

Where the bill grows

1. Long conversations. Each turn re-sends the history. Cost per conversation rises faster than the number of turns, so summarise or trim older turns.
2. Too much retrieved text. Ten help articles in every prompt, when two would do, can be the largest input line. Retrieve fewer and better.
3. The wrong model for easy tickets. Password resets and order-status questions rarely need a flagship. Route simple tickets to a small model and keep the larger one for hard cases. Our small versus large model guide covers how to test it.
4. Long prompts. OpenAI GPT-6 models charge double input and 1.5 times output on prompts over 272K tokens, and Claude Haiku 5.5 charges more above 100,000. Conversation prompts are far below this, but agents that load whole documents may not be.
5. Tool calls and retries. Each extra call to look up an order or retry a failed step is another full prompt.

How to check your own number

Take 50 to 100 real tickets and run them through the agent. Log input, cached and output tokens for every call, count the conversations that were resolved without a person, and price the totals from the current price list. That gives you cost per conversation, cost per resolved ticket and the ranges, in your own numbers. To price any volume on every current model, use the API pricing calculator. If your agent is already live, the free Bill Analyzer reads your usage export and estimates the effect of caching, cheaper models and batch processing. For a ranked plan based on your real requests, with the savings shown as ranges, that is what the LLM Cost Report delivers.