Tokens, Context Windows, and Next-Token Generation for the CCDV-F Exam

Why tokens are the unit that matters

Everything you build on Claude runs on one physical fact: the model does not read your prompt as words or characters. It reads it as tokens. A token is a chunk of text, often a fragment of a word or a short common word, and the model's entire view of your request is a sequence of these chunks. This is the first knowledge point in the LLM Fundamentals task statement for the Claude Certified Developer - Foundations (CCDV-F) exam, and it is the foundation that sampling, model options, and every cost calculation later depend on.

Because tokens are the unit, they are also the unit you are billed on, the unit that fills the context window, and the unit the model emits when it answers. Getting this one abstraction right early saves you from a whole family of surprises: prompts that get truncated, conversations that seem to "forget," and cost estimates that are wildly off because someone counted words instead of tokens.

Tokens are not words

The single most common trap on this knowledge point is treating a token as a word. The CCDV-F exam tests this directly, because the mistake quietly corrupts cost and capacity estimates. A token is usually smaller than a word: common words may be a single token, while longer or rarer words split into several. Whitespace, punctuation, and formatting all consume tokens as well.

The practical consequence is that you cannot look at a document, count the words, and know how many tokens it will cost. A rough rule of thumb for English is that a token is somewhat shorter than a word, but rules of thumb are for intuition, not for budgeting. When an exact number matters, you count tokens with a tokenizer or a token-counting endpoint rather than guessing from word count. Any answer that assumes "one word equals one token" is the distractor the exam wants you to reject.

The context window is bounded, and it holds everything

Every request runs inside a context window: a fixed maximum number of tokens the model can consider at once. This window is not just your latest message. It holds the whole request the model reasons over, the system prompt, every earlier user and assistant turn you resend, any tool definitions and tool results, and the output the model is generating right now. Input tokens and output tokens draw from the same budget.

The exam likes to probe the assumption that this window is effectively unlimited. It is not. A very long document, a transcript that has grown over many turns, or a large set of tool results can all approach the ceiling. When they do, you cannot simply keep appending. Something has to give: earlier or less relevant content must be dropped, summarised, or otherwise compacted so the essential material still fits. Treating the window as a bottomless bucket is the second trap this knowledge point sets.

This is also why the stateless request cycle you carry a conversation through has a natural cost curve. Because you resend the accumulated history each turn, the input side of the window grows steadily, which is exactly the pressure that later cost-control work such as caching for cost optimization is designed to relieve.

How next-token generation actually works

The model does not compose a whole answer and hand it back. It generates text one token at a time. At each step it looks at everything before it, the full sequence of tokens in the context window so far, and predicts the single most plausible next token. That token is appended, and the enlarged sequence becomes the input for predicting the token after it. The process repeats until the model predicts a natural stopping point or hits a length limit.

Two ideas fall straight out of this. First, output is sequential, which is why responses can be streamed as they are produced rather than arriving all at once. Second, generation is prediction over the preceding context, so the quality and relevance of what you put in the window directly shapes what comes out. The model is always answering the question "given all of this, what token comes next?"

That framing, prediction of the next token from prior context, is the mechanical seed for the very next knowledge point on sampling and non-determinism. The model does not simply take the single highest-probability token every time; how it chooses among probable next tokens is what makes the same prompt able to produce different outputs, which is a separate concept that builds directly on this one.

Why this underpins the rest of Domain 5

This knowledge point sits at Bloom level remember and difficulty 1: you are expected to recall what a token is, what the context window contains, and how output is produced. It is deliberately foundational. The model-options work on shot-based prompting and extended thinking only makes sense once you know that examples you add are tokens filling the same window, and that "thinking" produces more tokens. The technical-fundamentals work on SDKs that wrap REST APIs rides on requests whose size is measured in tokens.

So do not skim past it. Once tokens, the bounded window, and next-token generation are automatic, every later capacity, cost, and latency question in Domain 5 has a solid mechanical basis to reason from.

Common misreadings to avoid

How it shows up on the exam

CCDV-F questions on this knowledge point rarely ask for a definition in the abstract. They describe a developer whose prompt was truncated, whose cost estimate was wrong, or who assumed a long transcript would keep fitting, and ask you to name what went wrong. The answer traces back to the same three facts every time: text is tokens and tokens are not words, input and output share one bounded window, and the model generates output one token at a time from the preceding context. Lock those down and the sampling, model-option, and cost knowledge points that build on them have somewhere firm to stand.