Ask most teams what their LLM travel assistant will cost and you get a single number: “about $X a month.” That number is almost always wrong in the direction that hurts — it under-budgets exactly the conversations that matter most. The reason is simple, and once you see it you cannot unsee it: in travel, the context you feed the model routinely dwarfs the question the traveller actually asked. A traveller typing “can I change my flight?” sends a handful of tokens. But to answer, the assistant has to load the passenger’s PNR, the fare rules attached to that ticket, the current itinerary, the rebooking options, and often several turns of prior conversation. The user’s question is tiny. The context behind it is not. A flat per-conversation average smooths all of that away, and it smooths it away precisely on the high-value tasks — cancellations, rebookings, service recovery — where the assistant earns its keep. A token estimator exists to make that cost visible before launch, not after the first invoice. What is a token, really — prompt, context, history, or output? A token is a fragment of text the model reads or writes — roughly three-quarters of a word in English, though it varies by language and by tokenizer. That definition is easy. What trips teams up is where tokens come from in a live request, because you pay for all of them. Every turn of a conversational travel assistant sends four distinct token streams to the model: System prompt — the instructions, tone rules, and tool definitions. Fixed per turn, and often larger than people expect once you include function-calling schemas. Retrieved context — the booking data, fare rules, itineraries, and policy documents pulled in to ground the answer. In travel this is the dominant cost driver. Conversation history — the prior turns replayed so the model stays coherent. This grows with every exchange unless you truncate it. Generated output — the model’s reply. Usually the smallest stream, and typically the most expensive per token. Providers price input and output tokens separately, and output tokens usually cost more. Per OpenAI’s and Anthropic’s published pricing pages, output tokens are billed at a higher rate than input tokens for their comparable models — a detail that matters less than most people assume, because in travel the input side (context plus history) is where the volume lives. If you estimate cost by counting only the visible chat, you have measured the cheapest part of the request and ignored the rest. Why do travel service-recovery conversations cost more tokens than FAQ turns? This is the divergence that a per-conversation average hides. An FAQ turn — “what’s the baggage allowance on my fare?” — needs a short policy snippet as context and produces a short answer. A service-recovery turn — a missed connection that needs rebooking across two carriers — needs the full PNR, both fare rules, live availability, and the accumulated history of the conversation so far. The first turn might run a few hundred tokens. The second can run several thousand, and it will do so on every turn of that exchange because the context has to be re-sent each time the model is called. The operational consequence is uncomfortable: the conversations your business cares about most are the ones a flat average silently under-prices. A traveller asking a baggage question is cheap and low-stakes. A traveller trying to salvage a disrupted trip is expensive to serve and the moment where a good assistant creates real value. If your budget was built on an average, you have quietly promised to lose the most money on your most important interactions. That is not a rounding error — it is a structural mismatch between where cost lands and where value lands, and it is exactly the kind of gap a token estimator is built to surface. How does a token estimator work in practice? A token estimator is not a chatbot feature. It is a small cost model you build during scoping, before a line of production code ships. You enumerate the conversation types your assistant will handle, and for each one you estimate the four token streams per turn. The output is a per-turn cost, per conversation type — which is a completely different object from a monthly average. Here is a worked example. Assume a mid-market provider priced at roughly $2.50 per million input tokens and $10 per million output tokens (illustrative figures in the range of current commercial LLM pricing; check your provider’s published rates). These are stated to show the method, not to quote a vendor. Per-turn token cost by conversation type Conversation type System prompt Retrieved context History Output Est. tokens/turn Illustrative cost/turn Simple FAQ (baggage, check-in time) ~400 ~300 ~200 ~150 ~1,050 ~$0.004 Booking lookup (“where’s my flight?”) ~400 ~900 ~400 ~250 ~1,950 ~$0.007 Booking modification (seat, date) ~600 ~2,500 ~1,200 ~500 ~4,800 ~$0.016 Service recovery (cancellation, rebooking) ~600 ~4,500 ~2,500 ~800 ~8,400 ~$0.029 Token counts are illustrative planning figures for a hypothetical travel assistant, not a benchmarked measurement; substitute your own tokenizer counts against real prompts before committing a budget. The table makes the point that no single average can: a service-recovery turn costs roughly seven times an FAQ turn in this configuration, and it does so mostly on retrieved context and replayed history — the two streams a naive estimate ignores. Multiply each per-turn cost by expected turns per conversation and by monthly conversation volume for that type, and the vague monthly number resolves into a budget you can actually defend line by line. How do you turn a per-turn estimate into a monthly budget? The arithmetic is deliberately boring, which is the point. For each conversation type, take cost-per-turn × turns-per-conversation × conversations-per-month, then sum across types. What changes is not the maths but the resolution: instead of one blurred figure, you get a breakdown that tells you which features drive spend. If service recovery is 8% of your conversations but 35% of your token bill, that is a fact you want on the table before you commit — not a surprise you discover in month two. This is what makes each conversational milestone individually cost-testable. You can price a booking-modification feature against its own token cost and decide whether to ship it now, defer it, or constrain it — which is how you ship value incrementally rather than betting the whole programme on one launch. Teams evaluating which model to run this on will also weigh capability against cost; our notes on how the LMSYS Elo rating actually ranks LLMs are a useful counterweight to picking a model on price alone, and reading what the Chatbot Arena leaderboard does and does not tell you helps keep capability and cost as two separate decisions rather than one conflated guess. What levers reduce token cost without breaking booking accuracy? The dangerous way to cut token cost is to starve the model of context — trim the PNR, drop the fare rules, and watch the assistant confidently give a traveller wrong rebooking information. The accuracy you need in booking flows is not negotiable, so the levers that matter are the ones that reduce token volume without removing the grounding data the answer depends on. A few that hold up in practice: Retrieval scoping. Don’t inject the entire fare-rules document; retrieve only the clauses relevant to the current action. Tighter retrieval is the single biggest lever because retrieved context is the dominant stream in travel. History truncation and summarisation. Replay a rolling window of recent turns plus a compact summary of earlier ones, rather than the full transcript. This caps history growth on long service-recovery exchanges. Context-window budgets per feature. Set a hard token ceiling for each conversation type at design time, so a feature cannot silently balloon in production. Structured context over prose. Passing booking data as compact structured fields rather than verbose natural language cuts the token count of the same information. Each of these is a design decision you make before launch, informed by the estimator. Setting a history-truncation budget after you have seen the first month’s bill is remediation; setting it against a per-turn model is engineering. FAQ What should you know about token estimator llm in practice? A token estimator is a small cost model built during scoping: you enumerate your conversation types and estimate the four token streams — system prompt, retrieved context, conversation history, and generated output — for each one, producing a per-turn cost rather than a monthly average. In practice it turns a vague “about $X a month” into a defensible per-feature budget you can test before shipping. What actually counts as a token in an LLM request — prompt, context, history, and output? A token is a fragment of text — roughly three-quarters of an English word — and you pay for every stream in the request, not just the visible chat. That means the system prompt, the retrieved booking context, the replayed conversation history, and the generated reply all count, with input and output tokens usually priced separately by the provider. Why do travel service-recovery conversations cost more tokens than FAQ turns? Because a cancellation or rebooking requires loading the full PNR, fare rules for the affected tickets, live availability, and the accumulated conversation history — all re-sent on every model call — whereas an FAQ turn needs only a short policy snippet. In the illustrative model above, a service-recovery turn runs roughly seven times the tokens of an FAQ turn, and a flat average hides that exactly where value is highest. How do you translate a per-turn token estimate into a monthly cost budget for a conversational feature? For each conversation type, multiply cost-per-turn by turns-per-conversation by conversations-per-month, then sum across types. The value is in the resolution: the breakdown shows which features drive spend, so a low-volume but token-heavy feature like service recovery surfaces before it surprises you on an invoice. What levers reduce token cost without breaking booking-context accuracy? The safe levers reduce token volume without removing grounding data: scope retrieval to only the relevant fare-rule clauses, truncate and summarise conversation history, set per-feature context-window budgets at design time, and pass booking data as compact structured fields rather than prose. Starving the model of context to save tokens is the failure mode to avoid — it produces confident wrong answers in exactly the flows where accuracy is non-negotiable. How does token estimation fit into a GenAI feasibility assessment before you commit to a programme? Token estimation is the cost-modelling line item that turns a feasibility assessment into a defensible per-feature budget rather than a hopeful guess. It lets a generative-AI programme be scoped feature by feature, so each conversational milestone is individually cost-testable before you commit spend. Where this leaves you before launch The uncomfortable version of the takeaway is that most travel conversational-AI budgets are built backwards — an average is chosen first and the awkward conversations are assumed to fit inside it. They do not. Service recovery is where the token cost concentrates and where the traveller experience matters most, and a per-turn estimator is the only way to see both at once before money is committed. If you are scoping a conversational-AI programme, the token estimator belongs inside the feasibility assessment, next to the accuracy and integration questions — the failure class it prevents is a per-feature budget that under-prices the interactions your business most needs to get right.
