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?
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?
What a token actually is
Which statement about tokens is correct for cost estimation purposes?
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." }
]
}
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?
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.