
Large language models (LLMs) read and write text in small pieces called tokens, and most providers charge for the tokens you send in and the tokens the model sends back. The context window is the maximum amount of text the model can consider at once. Costs rise with longer prompts, longer answers and larger models, so controlling what you send is the main way to control spend.
Key takeaways
- A token is a piece of a word. Usage-based pricing counts tokens in (your prompt and any documents) and tokens out (the reply).
- The context window limits how much text the model can handle at once. Longer inputs cost more and can dilute the model's focus.
- Cost, speed and quality trade off against each other. Bigger models are usually slower and costlier per token; smaller ones are often enough for simple tasks.
- The biggest savings come from sending less: shorter prompts, retrieval of only the relevant text, caching of repeated context and the right model for each job.
- Measure usage from day one, set budgets and alerts, and test quality against a fixed set of examples before swapping to a cheaper option.
- Plan for vendor changes, since models are updated, repriced and retired over time.
What is a token in plain terms?
A token is a chunk of text, usually a word or part of a word. A short, common word may be one token. A long or unusual word may be split into several. Punctuation, numbers and spaces also take up tokens, and text in some languages tends to need more tokens for the same meaning.
You do not need to count them by hand, because providers return usage figures with every response. The mental model is simple: more text means more tokens, more cost and more time.
What are input tokens and output tokens?
Every request has two sides.
- Input tokens are everything you send: your instructions, the user's question, any examples, any documents or conversation history you attach.
- Output tokens are what the model writes back.
Providers often price these two differently, and output is typically the more expensive side per token, though the exact structure varies by provider and changes over time. Check the current pricing page rather than relying on a rule of thumb. The practical lesson is that you pay for what you ask the model to read and for how much you let it write. A request that attaches a long report and asks for a one-line answer is mostly an input cost. A request that asks for a long essay is mostly an output cost.
What is a context window and why does it matter?
The context window is the amount of text the model can take into account in a single request, covering your prompt, any attached material and the reply together. If you go beyond it, something has to be cut or the request fails.
Two business consequences follow.
- Cost. Anything inside the window is billed as input. Sending a very long document with every question quietly multiplies your spend.
- Focus. Even when text fits, very long contexts can make a model less reliable at picking out the one detail that matters. More text is not automatically better. A short, well-chosen context often produces a sharper answer.
Conversation history counts too: each new chat message may resend earlier turns, so long conversations cost more with every reply unless you trim them.
How do pricing models and trade-offs work?
Most providers use usage-based pricing: you pay for tokens consumed, sometimes with different rates for different model sizes, and sometimes with discounts for repeated context or batch processing. Some offer committed plans for larger customers. Because rates and rules change, this article names no figures; always read the provider's current terms.
Beyond price, three qualities trade off.
- Model size. Larger models tend to reason better on hard tasks but cost more and respond more slowly. Smaller models are cheaper and quicker and often perfectly good for classification, extraction and short rewrites.
- Latency. Longer prompts and longer outputs take longer. For a live chat or voice feature, speed is part of the experience, not just a cost matter.
- Quality. The cheapest option that meets your quality bar is the right one, and you can only know that by testing.
How can you control LLM costs?
Work through these levers roughly in this order.
Write tighter prompts
Remove repeated instructions, long preambles and examples that do not earn their place. Our prompt engineering guide for business teams shows how to keep prompts clear without making them long.
Retrieve only what is relevant
Do not paste whole manuals into every request. Search your documents first, then send only the few passages that answer the question. This approach is explained in RAG explained: AI answers from your own documents, and it usually improves accuracy as well as cost.
Cache repeated context
If many requests begin with the same long instructions or reference text, ask whether your provider supports caching for repeated input, and cache your own results for questions that recur.
Match the model to the task
Route simple jobs to a smaller model and reserve the larger one for hard cases. A cheap first pass that escalates only when unsure can cut spend substantially.
Batch work that can wait
Overnight tagging does not need an instant reply, and providers sometimes offer cheaper batch options.
Set limits
Cap output length, cap requests per user, and cap conversation length. Limits protect you from runaway usage, whether from a bug, an abusive user or a loop in an automated agent.
How do you measure usage and set budgets?
You cannot manage what you cannot see. From the first pilot:
- Log tokens in and out for every request, tagged by feature, user group and model.
- Track cost per task, such as per answered question or per processed document, not only the monthly total.
- Set a budget for each feature and alerts that fire well before the budget is reached.
- Watch for rate limits, which are caps on how many requests or tokens you can use per minute. Plan retries and queues so a traffic spike degrades gracefully instead of failing.
How do you balance quality and cost?
Never swap models or shorten prompts on instinct. Build a test set of real, representative questions with known good answers, run each candidate setup against it and compare results. If a smaller model passes your bar on the test set, you have a justified saving. If it fails on certain question types, route only those to the larger one. Repeat the test whenever you change the prompt, the model or the retrieval step. For choosing providers, see how to evaluate AI vendors and AI products.
How does data privacy interact with cost?
Everything inside the prompt is sent to the provider. Sending less saves money and reduces exposure at the same time. Strip personal and confidential details that the task does not need, check what the provider retains and whether it uses your data for training, and agree internal rules on what staff may paste into AI tools. Requirements vary by country and sector, so take qualified advice where regulated data is involved.
How do you plan for vendor change?
Models are updated, repriced and eventually retired. Protect yourself by:
- Keeping model names and settings in configuration, not scattered through code.
- Keeping your test set so you can re-evaluate a replacement quickly.
- Reading vendor notices and scheduling time for migration.
How do you forecast the cost of a pilot?
Use a method, not a guess.
- List the tasks the pilot will handle and the expected number of requests per user per day.
- Run a small sample, perhaps a few dozen real requests, and record average input and output tokens per request.
- Multiply by the expected volume, using the provider's current rates.
- Add headroom for retries, longer conversations and growth.
- Compare the result with the value of the time or errors saved.
Imagine a team building an internal assistant for HR policy questions. A trial shows that most input comes from pasted policy documents, so they switch to retrieving only the relevant paragraphs. Input per question falls, answers become more precise, and the rollout forecast becomes easier to defend. The figures come from their own logs.
What mistakes should you avoid?
- Sending whole documents with every request.
- Running without usage monitoring, then discovering the bill at month end.
FAQ
What is a token in an LLM?
A token is a small piece of text, often a whole short word or a fragment of a longer one. Models read and write in tokens, and providers measure usage and charge in them. As a rough idea, more text means more tokens, though the exact count depends on the language and the model.
Why do long prompts cost more?
Providers bill for input tokens, so every extra paragraph, document or earlier chat message you include adds to the cost. Long prompts also take longer to process and can make it harder for the model to focus on what matters. Sending only relevant text keeps both cost and quality in check.
What is a context window?
It is the maximum amount of text a model can consider at once, covering your prompt, any attached material and its reply. If you exceed it, the request fails or text must be trimmed. A larger window allows longer inputs, but it does not mean you should fill it.
How can I reduce LLM costs without hurting quality?
Shorten prompts, retrieve only relevant passages, cache repeated context, use smaller models for simple tasks and set sensible limits. Then test each change against a fixed set of real examples so you know quality has held. Measure usage continuously so savings show up in your own data.
Related reading
- RAG Explained: AI Answers Grounded in Your Own Documents
- Prompt Engineering for Business Teams: A Practical Guide
- How to Evaluate AI Vendors and AI Products
Next steps
Pick one AI feature you plan to build or already run. Start logging tokens in and out per request, write a small test set of real examples, and find out which part of your prompt is largest. That single exercise usually shows where the money goes. If you would like help designing a cost-aware AI feature, see our AI and ML services or contact us to talk it through.


