Tokens: the invisible unit running your AI bill

Open the OpenAI Tokenizer in a second tab: [platform.openai.com/tokenizer](https://platform.openai.com/tokenizer). It's free, needs no sign-in, and gives you the same view your AI provider is billing off. Paste any of the three snippets below and watch the text split into coloured chunks. Every chunk is one token, and the number at the bottom is exactly what you'd be charged for.

You bolted an AI feature onto your team's workflow. Perhaps a summariser sitting on top of customer emails, or a helper that drafts first-pass replies, or an internal chatbot that fields the questions HR keeps getting. It shipped, people liked it, everyone moved on. Then the invoice from your AI provider landed at the end of the month, and it was roughly three times what you'd budgeted, and nobody on the team could quite explain why.

Welcome to tokens. Tokens are the unit your AI provider bills you in, and if nobody on the team really understands them, that surprise invoice tends to become a monthly ritual. Cost is only half the story, though. Tokens also set the ceiling on how much context your AI can hold in one conversation, how quickly it responds under load, and even which questions it can reliably answer at all. There's a well-known example where a state-of-the-art model can't consistently tell you how many Rs are in the word 'strawberry'. That's tokens too.

Over the next fifty minutes we'll open tokens up, watch them in a real tokeniser, and finish with a set of habits worth taking back to work. Some will save you real money. All of them will help you spec, buy, and manage AI more confidently.

A modern AI language model doesn't read your prompt as a string of letters, and it doesn't quite read it as words either. Sitting between the two is a token.

A token is a chunk of text that the model has decided is worth treating as one unit. For common English words that works out at roughly one token per word, plus a token or two for punctuation and spacing. Less common words get split into pieces (the word 'tokeniser' itself is three tokens: `token`, `is`, `er`). Names, code, jargon, non-English text, emoji, and made-up words all balloon the count, because every unfamiliar fragment needs its own separate token.

Every input you send and every output the model generates is measured in tokens. Every commercial provider prices you in tokens. Every model has a hard token ceiling per conversation. This is the unit that quietly runs everything, and once you can see it, a lot of AI's day-to-day behaviour stops being mysterious.

You might file tokens under 'developer concern' and move on. It's a mistake. Tokens shape three separate parts of the day-to-day AI experience, and each one lands squarely in a business context: your budget, your product's memory, and your users' patience.

Before you tap the cards below, take a guess: in your own team's use of AI, where might tokens quietly be costing you today?

A well-shaped prompt costs less, keeps more of its memory, and lands on the user faster. Three business wins for the price of one habit.

Back to strawberry. The reason a modern model sometimes confidently reports two Rs isn't lack of intelligence, and it certainly isn't malice. It's tokens.

When you type strawberry, the tokeniser doesn't hand the model ten letters. It hands it something like `straw` + `berry`, two chunks. The model then dutifully counts the Rs it can see in those chunks and gives you an answer. It isn't being lazy. It's answering the question it was actually shown, which isn't the question you meant to ask.

The same shape underlies its trouble with anagrams, with reversing words character by character, with counting emoji, with formatting dates on odd token boundaries, and with any task where the meaningful unit is a letter or a symbol. In a business context this matters most when you're picking a tool: character-level jobs (spell-checking legal-code identifiers, validating serial numbers, sorting an alphabetical list precisely) aren't the natural strength of a language model, and knowing why saves you from procuring the wrong thing.

If your business operates in more than one language, tokens matter to you specifically. English is, roughly, the cheapest major language in the world to run through a modern AI, because the training data was dominated by English and the tokeniser learned to compress it efficiently. Everything else costs more per idea, sometimes considerably more.

The reason is simple. For a language the tokeniser didn't see as often, common words get broken into more, smaller pieces. A friendly Polish greeting costs roughly twice the tokens of the same greeting in English. A Chinese, Japanese, or Arabic sentence can cost two to three times as much again. Translate your customer-support workflow into five languages and you haven't only multiplied the translation work; you've quietly multiplied your API bill in a ratio that varies by language.

Matching the language to its rough token weight is a useful first pass before you commit to any multilingual rollout.

Every token in your prompt costs money, eats context, and slows the response. Every token in the model's output does the same. The game, then, is to get the same result in fewer tokens.

The two prompts below ask for exactly the same thing. Both work. One is roughly four times cheaper than the other. Copy each into the tokeniser to see the difference for yourself, and remember that this multiplier applies to every single call your product makes.

Once a team gets comfortable with AI, one idea comes up almost every time: 'Let's just paste our whole handbook / product catalogue / support archive / codebase into the system prompt so the AI always knows the answer.'

It sounds reasonable, and it isn't unreasonable, but the context window turns it into a design decision rather than a default. Even a very generous 128,000-token window sounds huge until you notice that a typical employee handbook, plus a customer's full order history, plus the conversation so far can easily blow through it. And even before you hit the ceiling, models tend to pay less attention to content buried deep in a long prompt. The phenomenon is called 'lost in the middle', and it's why an important policy on page forty of a long handbook can quietly get ignored.

The pragmatic pattern most teams end up using is called retrieval-augmented generation, or RAG: keep the handbook in a searchable store, fetch only the two or three most relevant passages for the current question, and pass just those into the prompt. Fewer tokens, cheaper, faster, and the model actually reads the bit that matters.

Time to bring everything together. You've been asked to spec a small AI feature at work: a first-pass summariser for customer-support tickets, so agents can triage faster. You have a modest budget of about £300 per month, roughly 2,000 tickets a month across three languages (English, Polish, Arabic), and stakeholders who want responses fast enough to feel instant in the agent's dashboard.

Rough maths: £300 across 2,000 tickets is 15p per ticket for all input and output combined, before overhead. On today's mid-range API rates that's very achievable in English, tighter in Polish, and easily over budget in Arabic unless you plan for it. Your first design decision matters.