The model lineup and its limits
Model selection is 16.8 percent of the exam and the fastest marks in it are pure recall. Learn the table. It is genuinely one table, and the current models mostly agree with each other, so the memorisation load is smaller than it looks.
The current lineup
Four current models, and they share their limits, which makes this easier than it looks.
claude-fable-5 and claude-mythos-5, at 10 dollars in and 50 dollars out per million tokens. Mythos is invite-only, which is a real access constraint and not a footnote: you cannot design around a model you cannot call.
claude-opus-5, at 5 dollars in and 25 dollars out.
claude-sonnet-5, at 2 dollars in and 10 dollars out through 2026-08-31, then 3 dollars and 15 dollars. That date is a promotional cliff sitting inside your cost model.
All four run 1M context and 128k output.
The outlier and the legacy shelf
claude-haiku-4-5-20251001 is the cheap one at 1 dollar in and 5 dollars out. It differs on two axes and both are testable: 200k context, 64k output, and no adaptive thinking.
Still active, still callable, and worth recognising by name: claude-opus-4-8, claude-opus-4-7, claude-opus-4-6, claude-sonnet-4-6, claude-sonnet-4-5-20250929, claude-opus-4-5-20251101. Opus 4.x prices at 5 dollars in and 25 dollars out, matching Opus 5. Sonnet 4.6 and 4.5 are 3 dollars in and 15 dollars out.
Active is not the same as advisable. Several of these legacy ids are precisely where the hard 400s live, which is module five.
Context and output are two different limits
A 1M context window is how much you can put in. A 128k output limit is how much can come out of one response. They are unrelated numbers and conflating them is a classic error.
max_tokens is bounded by the output limit, not the context window. Asking a 1M-context model for 500k tokens of output does not work, because output tops out at 128k.
One boundary on that number, worth knowing so the rule stays exactly true rather than roughly true: 128k is the ceiling on the synchronous Messages API. The Batches API raises it to 300k on Opus 5, Opus 4.8, 4.7, 4.6, Sonnet 5 and Sonnet 4.6 behind a beta header. That does not soften the point above, since the request being judged is almost always a plain Messages call, but “128k, full stop” is the kind of half-true that a well-built question will happily charge you for.
No long-context premium
Dated ids versus current ids
claude-sonnet-5 has no date. claude-haiku-4-5-20251001 does. The dated form pins you to an exact snapshot, which is what you want for reproducibility and evaluation, and it is also the form that carries a retirement date.
There is a third form worth naming because it bites hardest: a bare family alias in a config file, the kind of thing that reads as opus rather than as a model id. An alias is a redirect owned by whatever resolves it, so it can silently re-point on any update while your config file still reads exactly as it did yesterday, and the failure is invisible because nothing errors. If you have ever discovered that a service was running a generation behind what its config appeared to say, this is the mechanism.
So: pin dated ids in anything whose behaviour you have measured. Then put the retirement date in a calendar, because nothing else will remind you. claude-opus-4-1-20250805 retires on 2026-08-05, and that is what a retirement looks like arriving.
Try it yourself
The current lineup, cold
Pure table recall, and the cheapest marks in this domain. The one thing to hold onto is that the current models agree with each other, so the work is remembering the exception rather than remembering four rows.
Name the four current model ids, their shared context and output limits, and the one current-generation model that differs.
Reveal answer
claude-fable-5, claude-mythos-5 (invite-only), claude-opus-5 and claude-sonnet-5, all at 1M context and 128k output. claude-haiku-4-5-20251001 is the outlier: 200k context, 64k output, and no adaptive thinking. Legacy ids still active are claude-opus-4-8, claude-opus-4-7, claude-opus-4-6, claude-sonnet-4-6, claude-sonnet-4-5-20250929 and claude-opus-4-5-20251101.
The Haiku exception
Your design needs a cheap model that can still reason through multi-step problems with adaptive thinking. Can you use claude-haiku-4-5-20251001?
Show answer
Correct answer: C — No, Haiku 4.5 does not have adaptive thinking
claude-haiku-4-5-20251001 has no adaptive thinking. It is very much active and is the cheapest model in the lineup at 1 dollar in and 5 dollars out per million tokens, so the retirement option is wrong on a different axis. There is no beta header that adds the capability, which makes the first option the tempting one: beta headers unlock plenty of things, just not this.
Predict the response to this request
A summariser is pointed at claude-sonnet-5, which has a 1M context window.
{
"model": "claude-sonnet-5",
"max_tokens": 300000,
"messages": [
{ "role": "user", "content": "Rewrite this 200-page manual in full." }
]
}Show answer
Correct answer: C — It is rejected, because max_tokens is bounded by the 128k output limit and not by the context window
Context window and output limit are two different numbers with two different jobs. The window is how much can be in play at once, request and response together; the output limit is the ceiling on a single generated response, and on current models that is 128k. max_tokens is bounded by the output limit, so asking for 300k is asking for something the model cannot produce in one response. The tempting answer is the one where generation stops at 128k and returns the max_tokens stop_reason, because that is exactly what happens when a legal value is reached during generation. Here the value itself is out of range, so the request never starts.
The 1M context bill
You send a 700k-token prompt to claude-sonnet-5. How is it priced?
Show answer
Correct answer: A — At the standard input rate, with no long-context premium
There is no long-context premium. 700k input tokens cost 700k times the ordinary input rate, which is a genuinely useful thing to know when you are sizing a document-heavy design. The premium answers are tempting because tiered long-context pricing is a common pattern elsewhere, and assuming it here would make you reject an architecture that is actually affordable.
Confirming a limit under time pressure
You need the exact output token limit for a model id before you can size a job, and you would rather not trust memory. You have the documentation open. Where do you go?
Show answer
Correct answer: B — The models overview and its comparison table of context and output limits per model
Per-model limits live with the per-model metadata, in the comparison table that lists every current and legacy id alongside its context window and output ceiling, which is the one place all of them appear side by side so you can also see which model is the exception. The max_tokens reference entry is the tempting answer, because max_tokens is literally the parameter you are about to set, but a parameter reference describes the field rather than enumerating each model's ceiling. The pricing page carries prices and does not reliably carry limits, and a launch note tells you about one model on one day rather than the current state of the lineup.
Check what your config actually pins
Look at how a model id is specified in any config you control.
You can say whether the id is a dated pin such as claude-haiku-4-5-20251001 or an undated current id such as claude-sonnet-5, and you can state the consequence of each, that a dated pin is stable but expires on a published retirement date, while an undated id keeps moving under you.