A client called me last month holding two invoices from two different chatbot pilots, both running what he assumed was "the same AI," and one was nine times more expensive than the other. He wanted to know what he was actually paying for. Not the marketing version — the actual mechanical thing that determines the number on the bill. That thing is tokens, and almost nobody explains it in plain terms before someone signs a contract.
A token is a small chunk of text — smaller than a word, most of the time. "Running" might be one token. "Unbelievable" might split into two or three pieces. Punctuation, spaces, and parts of words all count. As a rough rule of thumb for English text, a token is somewhere around four characters, or a bit under a word — so 100 words of plain English lands around 130 to 150 tokens. It's not an exact science and it varies by language and by how repetitive or unusual the text is, but that ratio is close enough to plan around. Every AI tool you use — a chatbot, a writing assistant, a summarizer bolted into your CRM — is quietly converting your words into tokens, feeding them to a model, and getting billed by the token on both ends of that conversation.
Here's the part that catches people off guard: the tokens you send in (the input, sometimes called the prompt) and the tokens you get back (the output) are almost always priced differently, and output usually costs several times more per token than input. That's not an arbitrary markup — generating new text is a heavier, slower computational job than reading text that's already there, so providers price it accordingly. Practically, this means the shape of your usage matters as much as the volume. A tool that reads a lot and writes a little is cheap. A tool that reads a little and writes a lot is not.
This is why a one-line question costs almost nothing and a long document costs real money, even though it "feels" like the same kind of request. Ask a chatbot "what's our return policy?" and you might be looking at a few dozen tokens in, a few dozen out — a fraction of a cent, genuinely too small to notice on a bill. Now paste in a twenty-page vendor contract and ask for a summary. That contract alone might run eight or ten thousand tokens before the model has written a single word back, and if you've asked for a thorough summary rather than three bullet points, the output can add several thousand more — at the higher output rate. Same tool, same model, wildly different cost, purely because of what you fed it and what you asked it to hand back.
The mistake I see business owners make isn't misunderstanding this — it's never being told this, so they build a workflow around a single cheap test message and then get surprised when production traffic looks nothing like that test. The fix isn't complicated. Before you commit budget to anything, do a back-of-envelope estimate using real numbers from your actual workload, not a demo.
Take a customer support use case as an example. Say you're routing every incoming support email through an AI assistant that reads the customer's message plus some account context, and writes a drafted reply for a human to review. A realistic message-plus-context input might run 1,500 to 3,000 tokens once you count the customer's email, order history, and a system prompt telling the model how to behave. The drafted response might run 300 to 600 tokens. Multiply that per-message cost by however many tickets you handle a day, then by roughly twenty to twenty-two business days a month, and you have a real monthly number — not a guess, an actual estimate you can hold a vendor to. Do this before you sign up for a per-seat SaaS wrapper charging you a flat fee that may or may not track what the underlying usage actually costs.
Now take a batch document-summarization job, which behaves completely differently. If you're summarizing five hundred contracts a month at an average of six thousand tokens each, your input volume alone is three million tokens before a single summary is written — and that's the cheap side of the ledger. If each summary runs four hundred tokens on the pricier output side, that's another two hundred thousand tokens billed at the higher rate. The lesson here isn't "summarization is expensive" — it's that batch jobs live or die on the size of what you're feeding in, and that's usually the number people forget to estimate because they're thinking about the output, not the input.
A few habits make this much easier to control once you're actually running something. Trim what you send — a system prompt that repeats itself, includes irrelevant boilerplate, or pastes in an entire manual when three paragraphs would do is pure waste, billed the same as anything else. Ask for what you actually need on the output side — a workflow that generates an exhaustive five-paragraph answer to a yes-or-no question is burning tokens at the expensive rate for no reason. And if you're running the same or similar context repeatedly — a support bot referencing the same policy documents on every ticket, for instance — ask any vendor you're evaluating whether they support some form of prompt caching or reuse discount, because reprocessing identical context from scratch every single time is money left on the table.
None of this requires you to become an engineer. It requires about twenty minutes with a calculator and a realistic sample of your own data before you commit to a monthly spend, a headcount-replacing pitch, or a twelve-month contract. Every AI vendor pitch I've seen that skips this step — that goes straight from "look what it can do" to "here's the price" — is either hiding the math or hasn't done it themselves, and neither is a good sign.
I write about this kind of thing — the unglamorous mechanics behind AI tools that actually determine whether they're worth using — at 013labs.com.