Tokens, context, and the sampling parameters you are losing
Two units run this whole exam domain: the token, which is what you are billed in, and the context window, which is what you run out of. Then there is a third thing, sampling, which is quietly being taken away from you, and it is the single most likely line to break your next model upgrade.
Tokens are the billing unit and the limit unit
A token is a sub-word chunk. Not a word, not a character. Ordinary English prose lands somewhere near three quarters of a word per token, code and non-English text land elsewhere, and structured JSON with lots of punctuation lands somewhere else again.
Which means: estimate from measured token counts, not from word counts. Every price in this course is quoted per million tokens, so a bad token estimate is a bad budget, and the API returns exact usage on every response so there is no excuse for guessing after the first day.
Output is billed at roughly five times the input rate across this lineup. Sonnet 5 is 2 in and 10 out. Opus 5 is 5 and 25. Haiku 4.5 is 1 and 5. So a design that produces long output is expensive in a way that a design that consumes long input is not, and “make it more concise” is a genuine cost lever.
Context window versus output limit
The context window is total budget for the whole request plus its response. Everything counts: system prompt, tool definitions, entire message history, attached documents, and the tokens being generated.
The output limit is a separate, smaller ceiling on one response.
Current models: 1M context, 128k output. Haiku 4.5: 200k context, 64k output.
max_tokens is bounded by the output limit. You cannot ask a 1M-context model for 300k tokens of output, because output stops at 128k. Conflating the two is one of the most common errors in this domain and it produces confidently wrong architecture.
Sampling parameters are being withdrawn
This is a significant change of mental model. A decade of practice has treated temperature as the first knob you reach for, and on current Opus models that knob has not been left alone to gather dust. It has been removed and the hole welded shut.
The reasoning is coherent even if it is inconvenient. Modern models with adaptive thinking manage their own exploration internally, and an external sampling override fights that rather than helping it. Rather than let you degrade the model quietly, the API refuses.
The practical fallout is bigger than it looks, because the offending line is often not in your code. Any request body copied from an older service, any shared helper with temperature: 0 baked in for “determinism”, any wrapper library that populates the field unless told otherwise: each of those produces a request that fails the moment it points at Opus 4.7 or later, and none of them will show up in a grep of your own repository.
So check the serialised body, not the call site. Log one real request, look at what actually went over the wire, and you will find in thirty seconds what reading three libraries would take an afternoon to establish.
Try it yourself
Setting temperature on Opus 4.7
You copy a working request from an older service and point it at claude-opus-4-7, keeping "temperature": 0.2. What happens?
Show answer
Correct answer: C — It returns 400, because temperature is rejected there
temperature, top_p and top_k all return 400 on non-default values for Opus 4.7 and later. Silent ignoring is the tempting answer because that is how deprecated parameters usually die, and it is the more dangerous behaviour: you would ship believing you had determinism you did not have. A 400 forces you to deal with it at integration time.
Two limits, two meanings
These get conflated constantly. Separate them cleanly.
What is the difference between the context window and the output limit, and which one bounds max_tokens?
Reveal answer
The context window is the total budget for everything in the request plus the response: system prompt, tool definitions, full message history, documents, and the generated output all count against it. The output limit is the ceiling on a single response on its own. max_tokens is bounded by the OUTPUT limit, so on a current model you can hold 1M tokens of context but never generate more than 128k in one response. On claude-haiku-4-5-20251001 those numbers are 200k and 64k.
What a token actually is
Which statement about tokens is correct for cost estimation purposes?
Show answer
Correct answer: D — A token is a sub-word unit, so token count varies by content and must be measured rather than assumed
Tokens are sub-word units, so the same word count produces different token counts depending on language, formatting, code, and whitespace. That is why estimating from word count is a rough heuristic and not a number to put in a budget. Output is very much billed per token too, and at a much higher rate than input, typically five times higher across this lineup.
Spot the line that breaks the migration
This request body has worked in production for a year against an older Opus. Today it is being repointed at claude-opus-5.
{
"model": "claude-opus-5",
"max_tokens": 2048,
"temperature": 0,
"system": "You are a strict classifier. Answer with one label.",
"messages": [
{ "role": "user", "content": "Classify this ticket." }
]
}Show answer
Correct answer: A — temperature: 0, which returns 400 on Opus 4.7 and later
Opus 5 is later than Opus 4.7, so the sampling rule applies: temperature, top_p and top_k at non-default values are rejected with 400. The tempting answer is that nothing breaks, because the body looks completely ordinary and temperature 0 is the single most common line in production LLM code. That is exactly why this is the most likely thing to fail in a model migration. It is worth noticing where the value came from too, since a shared helper or wrapper library that defaults temperature will produce this line in requests whose own source code never mentions it.
Where the parameter you did not write comes from
The point of this card is the search strategy, not the rule. Grepping your own call sites is necessary and it is not sufficient.
Your service never mentions temperature anywhere in its own source, and a model migration still fails with 400 on a sampling parameter. Where do you look?
Reveal answer
In everything between your call site and the wire. Shared internal helpers that build request bodies and set a house default, wrapper or framework libraries that populate sampling parameters unless told otherwise, config or environment layers that inject defaults, and copied request templates that carry the field from an older service. The general point is that the parameter reaches the API rather than being written by you, so the grep has to cover the request as it is actually sent, not just the code that appears to construct it. Logging the final serialised body once is faster than reading three libraries.
Find every sampling parameter you set
Grep or scan your own service for temperature, top_p and top_k.
You have a list of every call site that sets one, and for each you can say whether the target model is Opus 4.7 or later, and therefore whether that call site is a 400 waiting for a model bump.