Token Limits and API Pricing: What You're Actually Paying For
Before you build your first AI feature, it helps to understand what a token actually is and why your bill doesn't track word count.
If you're about to build a feature on top of an AI API for the first time, the pricing page can be confusing in a specific way: it charges per token, and a token isn't a word, a character, or anything you'd naturally count yourself. Understanding what you're actually being billed for makes it much easier to estimate cost before you ship something that surprises you at the end of the month.
A token is a chunk of text the model was trained to process as a unit — sometimes a whole common word, sometimes a fragment of a longer or less common word, sometimes just punctuation. As a rough rule of thumb, a token works out to somewhere around three-quarters of an English word on average, though this varies by language and by how repetitive or unusual the text is. The important part isn't memorizing an exact ratio; it's knowing that both what you send to the model and what it sends back are measured this way, and both get counted toward your bill.
Most providers price input tokens and output tokens separately, and output is typically priced higher than input, because generating text is more computationally expensive than reading it. This is why a feature that asks a model to summarize a long document tends to be cheap — lots of input, relatively little output — while a feature that asks a model to write a long report from a short prompt costs more per call, even though the prompt itself was small.
Pricing also varies significantly by model tier. Larger, more capable models generally cost more per token than smaller or older ones, and it's common for a provider to offer several tiers so you can match cost to how demanding a given task actually is — a simple classification or formatting task rarely needs the most expensive model available. Some providers also offer discounted pricing for cached or repeated context, which matters if your feature sends a similar large prompt (like a long system instruction or reference document) on every request.
The practical takeaway before you build anything: estimate your typical input and output size per request, multiply by your expected request volume, and price it against the specific model tier you plan to use rather than a headline number. It's also worth testing whether a cheaper model handles your task acceptably before defaulting to the most capable one — for a lot of real features, the expensive model is more capability than the task actually needs.