5.1 Tokens, Context Windows, and Autoregressive Generation

Every question about limits, pricing, or capacity on this exam ultimately comes back to one unit of measurement: the token. Claude does not read, bill, or bound your requests in characters or words — it operates on tokens, which are roughly word-fragments, where one token works out to about 3-4 characters of English on average. That approximation matters because it is easy to eyeball a prompt's length in characters or words and badly misjudge how many tokens it actually costs.

Tokenization is vocabulary-dependent: a common English word might be a single token, while a rare word, a long number, or non-English text can split into several tokens. Two prompts with the same character count can have meaningfully different token counts. The practical upshot is that you never reason about a context-window limit, a `max_tokens` cap, or a per-request cost in terms of characters or words — you reason in tokens, and every one of those quantities (input and output alike) is billed and bounded in that unit.

It's tempting to picture an LLM as something that reads your prompt and returns a finished answer in one step, the way a lookup table would. That mental model is wrong, and the exam will test whether you've replaced it. Claude is an autoregressive predictor: at each step, it looks at everything generated so far — the full prompt plus any tokens it has already produced — and predicts a probability distribution over what the single next token should be. It samples one token from that distribution, appends it to the sequence, and repeats the entire process again with the now-slightly-longer sequence.

This repeats until a stop condition is reached: a configured stop sequence, the `max_tokens` ceiling, or the model's own signal that the response is complete. Because every token depends on all the tokens before it — including ones the model itself just generated a moment ago — generation is inherently sequential. There is no shortcut that computes token 500 before token 499 exists. This is also why longer outputs take proportionally longer to generate and cost proportionally more: each additional output token is another full pass through the "predict, sample, append" loop.

The context window is the maximum number of tokens — input plus output combined — that a model can consider in a single request. It is a hard ceiling, not a soft guideline: exceed it and the request either fails outright, or its content has to be truncated or summarized before it can fit. Knowing the number by itself isn't the exam-relevant skill, though; the exam-relevant skill is understanding what draws from that budget.

The critical, easily-missed detail is that the context window is one pooled budget shared across every component of a request — not a set of separate per-category allowances. A verbose tool result, a long system prompt, an extensive conversation history, a large set of tool definitions, and the model's own response are all drawing tokens from the exact same pool. There is no dedicated "tool-results budget" that's separate from the "conversation budget"; a token spent in one place is a token unavailable everywhere else.

Because the window is shared, a request that looks perfectly reasonable when you only glance at the user's message can still blow past the limit once you account for everything else riding along with it. A system prompt that reads as modest, a conversation history that's grown over many turns, a moderately large set of tool definitions, and a couple of verbose tool results can each look individually fine and still sum to more tokens than the model can accept.

This is why estimating whether a request fits means summing across all contributing categories — system prompt, history, tool definitions, tool results, and the anticipated response — rather than eyeballing the most visible piece (usually the user's latest message) and assuming the rest is negligible. When a request would exceed the window, the two realistic responses are to fail fast with a clear error, or to actively manage the content: truncating older turns, summarizing prior context, or pruning oversized tool output before it's added to the running conversation.

• 1.Estimate tokens for the system prompt, not just the user's message.
• 2.Add the accumulated conversation history — it grows every turn in a multi-turn session.
• 3.Add tool definitions (schemas, descriptions) if the request uses tools.
• 4.Add any tool results already appended to the running context.
• 5.Reserve headroom for the response itself — output tokens count against the same ceiling.
• 6.If the sum would exceed the window, truncate, summarize, or prune before sending — don't wait for the failure.

Task Statement 5.1 is foundational, and its questions tend to be short and literal — but the exam likes to hide the trap in a single word. Watch for scenarios that quietly swap "token" for "word" or "character," and for scenarios that imply a bigger context window automatically means lower cost or that any one category (like tool results) has its own separate ceiling.

• •Reasoning in words or characters instead of tokens. ✗ Any answer that estimates length or cost by word/character count. ✓ The answer that reasons in tokens and accounts for tokenization being vocabulary-dependent.
• •Treating the context window as bigger-is-cheaper. ✗ An answer implying a larger window reduces per-token cost or removes the need to budget. ✓ The answer that recognizes a bigger window permits more tokens, not cheaper ones.
• •Assuming per-category limits within the context window. ✗ An answer treating tool results, history, or the system prompt as having independent budgets. ✓ The answer that treats the window as one shared pool across every component.
• •Picturing generation as one-shot computation. ✗ An answer describing the model as retrieving or computing the full response at once. ✓ The answer describing autoregressive, token-by-token generation ending at a stop condition.