The first bill from a language model API is often a surprise, and the surprise usually has the same cause: the person who built the application thought in requests, while the provider charges in tokens. A request is not a unit of cost. A request that sends a 50-word prompt and receives a 50-word answer costs a tiny fraction of a request that sends a 5,000-word document and receives a 2,000-word report, even though both are "one API call." Until you think in tokens, the bill will feel random, and attempts to control it will target the wrong things, such as reducing the number of calls while leaving the enormous prompts untouched.
The LLM API Cost Calculator converts tokens into money. It takes your expected input and output token counts, the model's per-token prices, and the expected volume, and produces an estimate. The estimate is only as good as the token counts you feed it, so most of this guide is about getting those counts right and understanding the choices that change them. Note that prices change frequently and differ between providers and models; always check the provider's current pricing page before budgeting, and treat any figure here as illustrative rather than current.
Tokens, input, and output
A token is a chunk of text, roughly three-quarters of an English word on average, though the exact ratio varies with the text. Code, non-English languages, and unusual formatting can use more tokens per word. Input tokens are everything you send: the system instructions, the conversation history, the user's message, and any documents you include. Output tokens are everything the model generates in reply. Providers charge different rates for input and output, and output is usually more expensive, often several times the input price, because generating text costs more computation than reading it.
That asymmetry has a practical consequence: long outputs are the most expensive thing your application can do. An application that asks the model to write a long report for every query will cost far more than one that asks for a short summary, even if the inputs are identical. When you design prompts, specify the output length you actually need. "Summarise in three bullet points" is not just better writing advice. It is a cost control, because it caps the most expensive part of the call.
Input tokens have their own trap: conversation history. An application that sends the entire conversation with every new message grows more expensive with every turn, because the history gets longer each time. After twenty turns, you may be paying to resend the first nineteen messages with every new one. Common fixes include summarising older turns, keeping only the most recent turns, or storing a rolling summary. Each approach trades some context for cost, and the right trade depends on whether the application genuinely needs the full history or only the recent gist.
A worked example
Suppose you are building a support assistant that answers customer questions using a help-centre article. Each call sends system instructions of about 300 tokens, the relevant article of about 1,500 tokens, and the customer's question of about 100 tokens, for a total input of 1,900 tokens. The model replies with about 250 tokens. Suppose, for illustration only, the model charges $1 per million input tokens and $4 per million output tokens. The input cost per call is 1,900 divided by 1,000,000 times $1, which is $0.0019. The output cost is 250 divided by 1,000,000 times $4, which is $0.0010. The total per call is $0.0029, under a third of a cent. At 10,000 calls a month, the bill is about $29. That is manageable, and the calculation shows why: the per-call cost is tiny, and the monthly bill is driven by volume.
Now change one design decision: instead of sending one article, the application sends the five most relevant articles, totalling 7,500 tokens of context, and the model writes a longer reply of 800 tokens. Input rises to 7,900 tokens and output to 800, giving a per-call cost of about $0.0111, nearly four times the original. At the same 10,000 calls, the monthly bill is about $111. Nothing about the user experience changed fourfold, but the bill did, because the context grew and the output grew. This is the calculation worth doing before launch, not after the first bill, because it tells you which design choices are expensive and by how much.
A second worked scenario shows the value of model choice. Suppose a simpler model costs a tenth of the price of a powerful one and handles 90 percent of your queries well, while the powerful model is needed for the remaining 10 percent. Routing simple queries to the cheaper model and complex ones to the powerful model can cut the bill by most of the difference, while barely affecting quality. Many applications do not need the most powerful model for every call, and routing by task complexity is one of the most effective cost controls available.
Levers that actually control cost
The levers, in rough order of impact, are: choose the cheapest model that handles the task well; reduce the context sent with each call by retrieving only the relevant passages rather than whole documents; cap output length by asking for concise formats; manage conversation history with summarisation or truncation; cache repeated content, such as system instructions or frequently retrieved documents, where the provider supports it; and batch non-urgent work to cheaper processing options where available. Each lever is a design decision, not a billing setting, which is why cost control belongs in the design phase.
Caching deserves a note, because it is often misunderstood. If your application sends the same long document with many different questions, some providers offer prompt caching, which charges less for the repeated portion after the first call. The savings can be large, but they depend on the provider's caching rules, including how long cached content is retained and whether the cache is shared across your requests. Read the provider's documentation before counting on caching in a budget.
Common mistakes
The first mistake is budgeting from the price per request quoted in a blog post or a demo, which almost never matches your application's token profile. Always calculate from your own token counts, measured from real usage or realistic test data. The second mistake is forgetting output tokens, or assuming input and output cost the same. They do not, and output-heavy designs are systematically underestimated. The third mistake is ignoring growth: a prototype serving ten users costs almost nothing, and the same design serving ten thousand users costs a thousand times as much. Forecast at your expected scale, not your current scale. The fourth mistake is leaving development and testing traffic out of the budget. Developers testing prompts, running evaluations, and debugging can generate substantial usage that never appears in production forecasts. Track it separately, and set usage limits or alerts so that a runaway loop or a bug cannot generate an unbounded bill overnight.
Closing
Think in tokens, measure your real input and output counts, calculate at expected scale, and design with the cheapest adequate model, tight context, and capped outputs. To count the tokens in a prompt before you send it, use the AI Token Counter, and to plan how much context fits in a model's window, try the Context Window Planner. For managing token budgets across a session, read AI Token Counter Guide.