Tokens and the context window
Tokens are the unit models read, bill, and limit you by. Learn how text becomes tokens, what a context window really holds, and how to count before you send.
Models don't read characters, and they don't read words. They read : chunks of text made by a . Common words are usually one token. Rare words, long words and unusual text get split into several.
- "cat"cat1 token
- "generative"generative2 tokens
- "getUserById"getUserById4 tokens
- "antidisestablishment"antidisestablishment4 tokens
A rule of thumb for English: 100 tokens is about 75 words, or about 4 characters per token. Code, and non-English text need more tokens for the same length, so they cost more than they look. Emoji often take several tokens, and spaces count too.
Under the hood — How does text actually become tokens?
Models cannot read characters — they operate on numbers. A tokenizer sits in front of the model and converts text into integer IDs from a fixed of perhaps a few hundred thousand entries.
That vocabulary is learned, not hand-written. The usual method is : start with individual characters, then repeatedly merge the most frequent adjacent pair into a new single token. After many rounds, common words like the end up as one token, while a rare identifier like getUserById stays split into several pieces.
So the tokenizer is really a compression scheme fitted to the training data. It explains a lot of otherwise odd behavior: why English costs fewer tokens than most other languages, why models are historically bad at spelling tasks and counting letters (they never see letters, only chunks), and why your bill is measured in tokens rather than words.
Why you should care
- Cost. You are billed per input token and per output token, usually at different rates.
- Limits. The is the most tokens a model can handle in one call, counting your input and its output together.
- Speed. The model writes one token at a time, so a long answer takes noticeably longer than a short one. Output length matters much more than input length.
What the context window actually holds
It is easy to think of the context window as "how much you can ask". It is really one budget shared by everything in the call: your system instruction, the conversation so far, any documents, tools, and the answer itself.
- System instruction · your standing rules
- Chat history · every earlier message you resend
- Documents · text you pasted in or retrieved
- Tools · tool definitions and results
- The answer · what the model writes back
- Free space · what's left over
Counting before you send
countTokens tells you how many tokens a request would use, without asking the model to answer. It is fast and doesn't use up your generation . Use it before sending anything large, so "will this fit?" is a check instead of a guess.
const response = await gemini.countTokens({ contents: "Hello there" });
// { "totalTokens": 3 }Note the difference from generateContent: no candidates, no parts. Just a count. Your exercise is to dig it out.
Key takeaways
- Models read tokens, not words. 100 tokens is roughly 75 English words.
- Your instructions, the chat history, documents and the answer all share one context window.
- Nothing is remembered between calls. A chat resends, and pays for, the whole history every time.
Sign in to run the exercise
Reading is free. Writing code here needs an account so we have somewhere to keep your Gemini key and the +25 XP you are about to earn.