What an AI Reply Actually Costs You Per Conversation

Two bills, not one

If an AI answers your retailers on WhatsApp, you are now potentially paying on two meters, and they are easy to confuse.

The messaging meter. Meta charges per message for templates, and from 1 October 2026 for service messages and for utility messages sent inside the 24-hour window. That change is covered in what happens to the free reply on 1 October.

The token meter. Separately, Meta documentation states that from 1 August 2026 it charges on a per-token basis for Meta Business Agent messages, at a published rate of $2.00 USD per 1M tokens. If instead you run your own model behind your own integration, you pay your model provider on a similar basis.

These behave differently, and the difference is the whole point of this post. Message cost scales with how many messages you send. Token cost scales with how much text the model has to read and write — which grows with conversation length regardless of how many messages the retailer sees.

Where the tokens actually go

The intuition that trips people up is assuming the retailer's message is the expensive part. It is almost always the smallest part.

To answer even a simple question, a model is sent: the instructions defining how it should behave, whatever catalogue or price context it needs, the conversation so far, and finally the new message. It has no memory between turns, so all of that is re-sent every single time.

Two consequences follow directly.

Cost grows within a conversation. Turn eight carries seven turns of history that turn one did not. A long conversation is not linearly more expensive than a short one; it is worse than linear, because each turn drags a growing history behind it.

Cost is unrelated to order value. A retailer who chats for twelve turns and orders nothing costs more than one who sends a list and confirms in two. Nothing in the token meter knows or cares whether an order resulted.

That second point is the one worth sitting with, because it is the opposite of how distribution economics normally work, where cost to serve broadly tracks volume.

A worked example

Numbers to re-run with your own, not a benchmark. Substitute your actual context sizes and current rates.

Say your setup sends roughly 1,000 tokens of instructions and catalogue context per turn, plus accumulated history, and the model replies with about 150 tokens.

A three-turn order might total in the region of 5,000 tokens. A rambling twelve-turn conversation, with history compounding, can run several times that for the same single order — or for no order at all.

At published per-token rates these are small amounts individually. The reason to care is that they multiply by every conversation every day, and the third row is pure cost with no revenue attached to it.

The design that keeps this bounded

Retrieve, do not attach. The single largest avoidable cost is sending the whole catalogue every turn. A distributor with several thousand SKUs who attaches all of them pays for the entire catalogue repeatedly inside one conversation. Select the handful of relevant items and send only those.

Use the model for interpretation, rules for everything else. Working out that a retailer means a specific SKU when they type it in mixed language and local shorthand is genuinely hard, and is what a model is for — the mechanics are in how conversational AI parses commerce messages. Applying the price list, checking the credit limit, totalling the cart and picking the tax rate are arithmetic. Routing those through a language model costs tokens and, worse, introduces the possibility of arithmetic that is confidently wrong.

Summarise history rather than replaying it. Past turns can be compressed into a short running state — cart contents, retailer identity, what has been confirmed — instead of being re-sent verbatim. This flattens the growth curve, which is where most of the cost in a long conversation lives.

Cap conversation length deliberately. A conversation that has run a dozen turns without producing an order is usually stuck. Handing it to a person at that point is cheaper than letting it continue, and it is a better experience.

Short-circuit the repeat orders. A retailer whose order barely varies does not need a model in the loop at all. Send the usual list for confirmation and skip straight to fulfilment. This is the same lever that cuts the message bill, and it is worth doing once for both reasons.

The sequencing that matters

The temptation with per-token pricing is to treat it as a procurement problem — find a cheaper model, negotiate a rate. That is the smallest lever available.

The larger one is the same argument made in AI in B2B sales automation and in reorder prediction versus a reorder point rule: decide honestly which part of the job actually needs a model. Interpretation of messy human input does. Arithmetic, lookups and rules do not, and they represent most of what happens in an ordering conversation.

Get that split right and token cost becomes a small, predictable line that scales with genuine ambiguity rather than with everything your system happens to do. Get it wrong and you are paying a language model to add up a cart, on every turn, forever.

Measure before you optimise

One caution before acting on any of this. The numbers above are illustrative shapes, not measurements of your system, and token accounting is unintuitive enough that guessing tends to be wrong.

Log tokens per conversation and per completed order for a week. You will usually find the cost is concentrated in a small number of long conversations and in one oversized piece of context being sent every turn. Both are cheap to fix once visible — and neither is findable without the log.

FAQ

The questions that come up when a team first sees a token bill.