Autoregressive Generation
The mechanism behind every Claude response is this: the model emits one token at a time. Each token is conditioned on the whole sequence so far, including the model's own output. Anthropic's glossary describes the pretraining objective as predicting "the next word, given the previous context of text in the document".
Exam context: Three consequences are tested. Generation is serial, so response time scales with output length. There is no lookahead and no revision, so a contract stated before the task works better than a correction added afterwards. And each token conditions the next, so an early mistake leads to more mistakes instead of correcting itself.
See also: 5.1 LLM Fundamentals
Token
A unit of the model vocabulary rather than of human text. Tokens "can correspond to words, subwords, characters, or even bytes (in the case of Unicode)", so code, JSON, tables and non-English text tokenise quite differently from English prose.
Exam context: Don't rely on a tokens-per-word ratio. The documentation set gives two ratios that disagree with each other. The glossary gives roughly 3.5 characters per token, and the pricing FAQ gives roughly 4 characters or 0.75 words. That disagreement is itself the reason to measure.
See also: 5.1 LLM Fundamentals
Tokenizer
The component that turns text into the tokens a given model actually consumes. It is a property of the model, not of the text, which is why the same words can cost different amounts on different models.
Exam context: As of August 2026, Claude 4.7 and later models use a newer tokenizer producing approximately 30 per cent more tokens for the same input. So a count taken before a migration and reused after it is wrong in two ways: for the cost model and for the space left in the context window. Recount, every time you change models.
See also: 5.1 LLM Fundamentals
Token Counting Endpoint
POST /v1/messages/count_tokens. It accepts the same structured inputs as a real message, including the system prompt, tools, images and PDFs. It returns a single input_tokens field. It is free, has rate limits independent of message creation, and does not apply caching logic.
Exam context: It counts the tokens in a request before you send it, and its answer is explicitly "an estimate". It returns the count under the tokenizer of the model you pass, so the model argument changes the result and is not a minor detail. Options claiming that counting costs money or returns a guaranteed figure are wrong on both points.
See also: 5.1 LLM Fundamentals
Context Window
Everything the model can reference when generating, the response included. The system prompt, every message with its tool results, images and documents, the tool definitions and the generated output with its thinking all compete for the same space.
Exam context: Caching creates no extra space in the context window, because "prompt caching changes what you pay for those tokens, not whether they count". Bigger is not automatically better either, since recall degrades as token counts grow. Wrong options often state the opposite of both of these points.
See also: 5.1 LLM Fundamentals
model_context_window_exceeded
The stop_reason returned when a request was accepted but generation reached the window limit. It arises on Claude 4.5 and newer when input tokens plus max_tokens exceed the window; earlier models return a validation error before generation instead.
Exam context: The way to tell this case from the other overflow case is whether the input alone is too big. Input alone over the window is a 400 invalid_request_error before any generation, on every model. Both are token-count problems, and both have token-budget fixes, and neither is a prompt fault. Silent first-in-first-out truncation of old messages is chat-interface behaviour, not API behaviour.
See also: 5.1 LLM Fundamentals
Temperature
The sampling parameter that widens or narrows the distribution the next token is drawn from. Lower values produce "more conservative and deterministic outputs that stick to the most probable phrasing and answers", where deterministic is meant comparatively.
Exam context: As of October 2026, API version 2026-10-21 removes it, together with top_p and top_k. Under that version, a request that sends any of them returns a 400 on every model. Under earlier versions, a non-default value returns a 400 on Claude 4.7 and later. The recommended replacement is "Omit and use prompting to guide model behavior".
See also: 5.1 LLM Fundamentals
Non-Determinism
The property that identical inputs can produce different outputs across API calls. Stated by Anthropic itself and without qualification: "Even with temperature set to 0, the results will not be fully deterministic", on Anthropic's own inference service and through third-party cloud providers alike.
Exam context: The claim in this domain least likely to change, because it describes the service rather than a release. Temperature zero gives consistency, not reproducibility. Any option promising byte-identical output for identical input is wrong, and the right fix is always a demonstrated format, an explicit output contract and validation when your code receives the output.
See also: 5.1 LLM Fundamentals
Adaptive Thinking
The form of reasoning control that leaves the decision to Claude, set with thinking: {type: "adaptive"}, which lets Claude "determine when and how deeply to think based on the request". As of 14 November 2026 it is already on with no configuration needed on Claude Opus 5.5, Opus 5, Sonnet 5.5, Sonnet 5, Haiku 5.5, Fable 5.2, Fable 5.1, Fable 5 and the Mythos models. On those models display defaults to "omitted", so thinking blocks come back with an empty thinking field until you set display: "summarized".
Exam context: Support was not uniform when the guide was written, which is exactly why it names it in the 5.3 scope. Claude Haiku 4.5, the fastest model then, rejects it and uses the older extended thinking form instead. As of 14 November 2026 every model in the current line-up has it, Claude Haiku 5.5 included. Haiku 4.5 is an older model, and it is still available. A design that needs the model to set its own reasoning depth cannot use any model without it, and Haiku 4.5 is one of them. Such a model is excluded on capability, before cost is considered. To see the reasoning, read the thinking blocks. A request for the reasoning in the response text can be refused with stop_details.category: "reasoning_extraction". As of 14 November 2026 this applies to Claude Fable 5.2, Fable 5.1, Opus 5.5, Opus 5, Sonnet 5.5 and Fable 5. This category is billed even when the refusal arrives before any output.
See also: 5.1 LLM Fundamentals
Effort
The parameter set through output_config. Its levels are low, medium, high, xhigh and max. It trades intelligence for latency and cost inside a single model. The default depends on the model. As of 14 October 2026, "Most Claude models default to high effort", while "Claude Opus 5.5 and Claude Haiku 5.5 default to medium". Setting it to the model's default behaves exactly as omitting it.
Exam context: It is the setting used most and the first one to try, because it "applies to every output token", so "it works whether or not thinking is enabled". It also covers tool calls, so "Lower effort also means fewer and terser tool calls" rather than merely shorter prose. It is "a behavioral signal, not a strict token budget", and documentation states that tuning it is often a better choice than switching models.
See also: 5.1 LLM Fundamentals
Fast Mode
An inference configuration, opted into with speed: "fast" (plus the fast-mode-2026-02-01 beta header on Claude Opus 5 and Opus 4.8 only), which "runs the same model with a faster inference configuration. There is no change to intelligence or capabilities."
Exam context: The only one of the four model options that does not lower quality. Its gain is in output tokens per second, "not time to first token (TTFT)", so it makes a visible difference on long streamed answers and almost none on short ones. As of 13 November 2026 it covers Claude Fable 5.2, Mythos 5.2 and Opus 5.5, with a research preview on Opus 5, deprecated on Opus 4.8 (removed on 30 November 2026), at premium pricing, and switching between fast and standard speed invalidates the prompt cache.
See also: 5.1 LLM Fundamentals
Multi-Shot Prompting
Supplying several worked input-output pairs alongside the instruction. The guide's terms are zero-shot, single-shot and multi-shot; the current documentation calls the same family "few-shot or multishot prompting".
Exam context: Examples are "one of the most reliable ways to steer Claude's output format, tone, and structure", and the quality tests are named: relevant, diverse, structured in <example> tags, three to five for best results. Diversity is the underrated one, because a set sharing an incidental property teaches that property. Use examples when the output fails on form or on boundaries, never when it fails on budget or on fact.
See also: 5.1 LLM Fundamentals
Client SDK
Anthropic's typed client libraries, shipped for Python, TypeScript, C#, Go, Java, PHP and Ruby alongside the ant CLI. Each "provides idiomatic interfaces, type safety, and built-in support for streaming, retries, and error handling", over the same public HTTP endpoint that a raw request uses.
Exam context: The part that exam questions actually test is what it does not change. No SDK-only models, no cheaper tokens, no higher or waived rate limits, no uptime guarantee, no immunity from an error class. The exam-safe formulation: the SDK changes how convenient it is to call the API and nothing about the API itself.
See also: 5.2 Technical Fundamentals
Request ID
The identifier on every response, arriving as the request-id header and exposed by the SDKs as _request_id, "so that you can quickly log failing requests and report them back to Anthropic". It also appears inside error bodies.
Exam context: The only key shared between your logs and Anthropic support, which is why the right practice is logging it on successes as well as failures. Finding it during an incident is too late.
See also: 5.2 Technical Fundamentals
Typed Exception Hierarchy
The SDK classes mapped from HTTP status: BadRequestError (400), AuthenticationError (401), PermissionDeniedError (403), NotFoundError (404), ConflictError (409), UnprocessableEntityError (422), RateLimitError (429), InternalServerError (500 and above), and APIConnectionError for transport failures.
Exam context: Catch most-specific-first and branch on the class, never on the message text, which is not a contract and changes without notice. Branching on substrings of an error message is a recurring wrong answer.
See also: 5.2 Technical Fundamentals
max_retries
The SDK setting governing automatic retry. The default is 2, "with a short exponential backoff", covering connection errors, 408, 409, 429 and 500 and above. The default timeout is 10 minutes, and requests that time out are themselves retried twice.
Exam context: Retries and timeout combine, so the worst-case total time is roughly the timeout multiplied by the attempt count. A retry loop of your own added to the defaults multiplies attempts, re-sends deterministic failures that will never succeed, and sends more requests to an endpoint that is already over its rate limit. Set it at one layer and let the other decide whether to degrade, queue or fail with a visible error. The errors that are retried are not the same as the errors that are transient. As of September 2026 a usage tier's spend-cap 429 is retried too. It has no retry-after and an error_code of enforced_spend_limit_reached, and it keeps failing until access resumes.
See also: 5.2 Technical Fundamentals
Server-Sent Events
The transport the Messages API streams over, enabled with "stream": true. It runs on ordinary HTTP, needs no protocol upgrade, and is deliberately one-directional: MDN notes "you can't send events from a client to a server".
Exam context: One-way is exactly right for a response, because the client has nothing to send during generation. Streaming is also sometimes obligatory rather than optional. The trigger is expected duration rather than any published max_tokens figure. The Python SDK "will throw a ValueError if a non-streaming request is expected to take longer than approximately 10 minutes", because some networks drop idle connections. Passing stream=True or overriding timeout disables that check.
See also: 5.2 Technical Fundamentals
WebSocket
A persistent two-way channel, which MDN describes as making it "possible to open a two-way interactive communication session between the user's browser and a server". It belongs between your own client and your own server.
Exam context: A question that often appears shows the right transport used at the wrong layer. No documented Anthropic API surface accepts a websocket connection from a client, so proposing one to Anthropic is wrong at the protocol level rather than merely suboptimal. The reverse also gets tested: a websocket in your front end gives you no streaming from the API, and streaming from the API needs no websocket in your front end.
See also: 5.2 Technical Fundamentals
Mid-Stream Error Frame
An error delivered inside an already-successful stream, such as an overloaded_error during periods of high usage, arriving as an event: error frame after the 200 that opened the connection.
Exam context: A 200 opens a stream rather than completing it. Error handling wrapped around the call but not around the iteration never sees this, and the symptom is a silently truncated answer with no exception raised.
See also: 5.2 Technical Fundamentals
Connection Pool
The reusable set of HTTP connections owned by a client instance. Anthropic's guidance is to use the SDK's default HTTP client classes precisely so "the SDK's default configuration (such as timeouts and connection limits) is preserved".
Exam context: Construct one client at startup and reuse it. A client built inside every request handler discards the pool on every call. Each call then pays for a fresh TLS handshake, and the number of open sockets multiplies. The defect only shows under concurrency. It presents as latency that grows with traffic and as connection errors that look like an upstream problem. Those are exactly the symptoms a question will describe.
See also: 5.2 Technical Fundamentals
Cost and Capability Ordering
The stated ranking of the current line-up. As of 13 November 2026: "From lowest to highest cost and capability, the current models are Claude Haiku 5.5, Claude Sonnet 5.5, Claude Opus 5.5, and Claude Fable 5.2 (the frontier model)". In October 2026 the same sentence ended with Claude Fable 5.1, and in September 2026 it began with Claude Haiku 4.5 and Claude Sonnet 5. Comparative latency is in the reverse order.
Exam context: The ordering stays stable. The identifiers, prices and line-up change over time and belong on the quick reference. The consequence to remember: quality, latency and cost are not independent axes, so moving up the ordering gives more capability and costs both money and time.
See also: 5.3 Model Selection and Trade-offs
Cost per Completed Task
The documented unit of model comparison, in place of price per token: "A more capable model finishes a task with less work: fewer turns, less searching, less re-reading of its own context, and less backtracking."
Exam context: Paired with the sampling rule, "Price the tail of your workload, not the median". On the typical task every model looks similar and the cheapest looks best. The bill is decided by the tasks the cheaper model fails. That is because a failed task bills its tokens, then the retry, then the downstream cost. "The ranking flips by workload, and no price list tells you which way."
See also: 5.3 Model Selection and Trade-offs
Efficiency-First Strategy
Starting with the fastest tier, testing thoroughly, and upgrading "only if necessary for specific capability gaps". Documented best uses: initial prototyping, tight latency requirements, cost-sensitive implementations and high-volume straightforward tasks.
Exam context: Not a default, and neither is its opposite. The stated constraint in the question picks one, and an answer that applies either strategy as a fixed rule is wrong regardless of direction.
See also: 5.3 Model Selection and Trade-offs
Capability-First Strategy
Starting with "the strongest starting point for your task", optimising the prompt for it, then considering "increasing efficiency by lowering effort or downgrading models over time". Documented best uses: complex reasoning, "tasks requiring nuanced understanding", and applications where accuracy outweighs cost.
Exam context: The starting point is not automatically the most capable model. As of 13 November 2026 the page starts on Claude Opus 5.5 and moves to the frontier Claude Fable 5.2 only if evals at xhigh or max effort are still not good enough. Note where the optimisation goes, into effort before tier. An effort sweep (a test of each effort level) on the model you are already running competes directly with a tier change, and documentation states that tuning effort is often the better choice. Anthropic's cost guidance makes one exception: a model or two behind the current line-up is upgraded first.
See also: 5.3 Model Selection and Trade-offs
Evaluation Set
The small suite of cases with explicit pass checks that converts an opinion about a model into a decision. Documentation calls it "the most important step in the process", to be run "with your actual prompts and data".
Exam context: The gate (the test that decides) for both selection and migration. A benchmark table or a price cut is not a gate, because published numbers are measured on somebody else's tasks. Pass checks are boolean rather than ratings, because that is what makes cost per completed task computable.
See also: 5.3 Model Selection and Trade-offs
Pinned Snapshot
What every Claude model ID is. Dated IDs are fixed to a release, and from the 4.6 generation the dateless format is also a pinned snapshot rather than a pointer that moves to newer releases.
Exam context: Pinning means the snapshot you are on does not change unless you change it, which is what makes a planned migration possible. It says nothing at all about how a different snapshot behaves, which is the entire reason a migration needs an eval. Recording what each identifier resolves to per environment is 2.6; deciding what to pin is here.
See also: 5.3 Model Selection and Trade-offs
Model Lifecycle States
The four documented states. Active: "fully supported and recommended for use". Legacy: "will no longer receive updates and might be deprecated in the future". Deprecated: "still functional but no longer recommended", with a recommended replacement and an assigned retirement date. Retired: "no longer available for use. Requests to retired models will fail."
Exam context: Legacy is not Deprecated and Deprecated is not Retired. Wrong options rely on exactly those confusions. Anthropic provides "at least 60 days' notice before model retirement for publicly released models", which gives time to plan and does not stop the retirement. A retirement date is a deadline on your roadmap.
See also: 5.3 Model Selection and Trade-offs
Breaking Behaviour Change
The guide's own phrase for what arrives with a new model release. Behaviour shifts in named ways, including default response length, how literally instructions are read, tool-calling tendency and readiness to delegate. Interface changes break code outright, and cost changes arrive even when nothing breaks.
Exam context: Interface changes fail with visible errors: manual thinking with budget_tokens, assistant prefill and non-default sampling parameters all return a 400 error on the newest models. The expensive ones fail quietly, because a prompt written to compensate for an older model is followed literally by a newer one. Swapping the model string and keeping everything else unchanged is how that silent failure happens.
See also: 5.3 Model Selection and Trade-offs
usage Object
The billing record on every response, carrying input_tokens, cache_creation_input_tokens, cache_read_input_tokens and output_tokens, plus details including output_tokens_details.thinking_tokens. A cost model prices each of those counts at its own rate, and cache writes use the 5-minute or 1-hour multiplier. The results are summed across the task's requests.
Exam context: input_tokens does not mean all of the input. It counts the tokens after the last cache breakpoint, so on a cached request the real input volume is the sum of all three input fields. Read it alone on a heavily cached workload and the prompt looks as though it shrank. On a stream, the counts on message_delta are cumulative and are read rather than summed.
See also: 5.4 Cost and Token Management
Cache Write and Cache Read
The two asymmetric halves of caching economics. As of September 2026, a 5-minute write costs 1.25x base input price and a 1-hour write costs 2x. A read or refresh costs 0.1x on most models. As of 14 November 2026 it costs 0.05x on Claude Opus 5.5 and Sonnet 5.5. On Claude Fable 5.2, Mythos 5.2, Fable 5.1 and Mythos 5.1 it costs 0.025x. Caching "saves money after a small number of cache reads". With the 5-minute duration (1.25x write), it saves money after one cache read. With the 1-hour duration (2x write), it saves money after two cache reads.
Exam context: Learn the pattern rather than the figures. A write costs more than not caching, so a prefix used only once loses money outright. An option that describes caching as pure saving with no write cost is wrong. Choosing the longer lifetime is an economic decision rather than a configuration one, because a miss re-sends the whole prefix at full price and writes it again.
See also: 5.4 Cost and Token Management
Minimum Cacheable Length
The per-model minimum token count below which prompts "are processed without caching". As of 14 November 2026 it is 512 tokens on Claude Fable 5.2, Mythos 5.2, Fable 5.1, Mythos 5.1, Opus 5.5, Opus 5, Sonnet 5.5, Fable 5, Mythos 5 and Haiku 5.5. The highest is 4,096, on Claude Opus 4.6, Opus 4.5 and Haiku 4.5.
Exam context: The failure is silent. A prefix under the minimum returns no error at all, so there is nothing for an error handler to catch and nothing in the logs to notice. It is the reason "large" is one of the four conditions for caching rather than an optional detail.
See also: 5.4 Cost and Token Management
Cache Lifetime
How long an entry stays valid, five minutes by default or one hour at the higher write price. The clock is "measured from the start of the request that writes or reads the cache entry, not from response end", and the entry "is refreshed at no additional cost each time cached content is used".
Exam context: Generation time counts against the window, so a response that streams for several minutes has used most of the shorter lifetime before the next request begins. A bursty arrival pattern is the case in which the choice between the two durations is no longer a configuration choice and needs calculation.
See also: 5.4 Cost and Token Management
Cache Check-Pointing
The guide's own phrase for deciding where the breakpoint sits when the prefix grows every turn. The transcript of earlier turns is the stable part and the new turn is the volatile part, so the breakpoint belongs at that boundary and has to advance as the boundary moves.
Exam context: Two limits shape explicit designs: at most four breakpoints per request, and a twenty-block lookback window from each one. A conversation growing further past the last write than that lookback will miss, and the fix is a second breakpoint placed closer and from the start. A checkpoint placed before volatile content is wasted, because that content invalidates everything after it on every request.
See also: 5.4 Cost and Token Management
Usage and Cost API
The organisation-level aggregate. It is now a legacy API that remains supported, and new integrations should use the Usage and Cost Analytics API. /v1/organizations/usage_report/messages tracks uncached input, cached input, cache creation and output tokens in buckets of a minute, an hour or a day. Its data is groupable "by API key, workspace, model, service tier, context window, data residency, or speed". /v1/organizations/cost_report returns cost breakdowns in USD.
Exam context: Third of the three instruments for measuring usage and cost, and options offering one for another's job are wrong by definition. It needs an Admin API key rather than a standard one, is not available "to organizations on the claude.ai Team plan or to individual Claude Console accounts", surfaces data within about five minutes, and supports polling once a minute. Measuring a change against a monthly invoice is the wrong answer, because an invoice cannot separate two changes or a traffic fluctuation from either.
See also: 5.4 Cost and Token Management
Batch Processing
Asynchronous request processing at "a 50% discount on both input and output tokens", with results available when the batch completes or after 24 hours, whichever comes first.
Exam context: A free win (a saving that does not lower quality), but only for work nobody is waiting on. The cost of the discount is slower delivery, so routing an interactive service through it trades a real requirement for a saving. That trade is a recurring wrong answer.
See also: 5.4 Cost and Token Management
max_tokens
The per-response output cap. As of October 2026, the cost guidance says it "caps a single response, invisibly to the model, so lowering it does not make the model economize. The turns that needed the room are discarded and still billed."
Exam context: The most common wrong answer in this sub-skill, and it is wrong on the mechanism rather than on the arithmetic. In Anthropic's internal measurement a tight cap cut off a large share of attempts, and very few of those still passed. Attempts got cheaper and fewer tasks got solved, so cost per solved task barely moved. The correct handling is the opposite of the first idea most people have: set it high enough that nothing is cut off, and "treat stop_reason: max_tokens as a failure". Take the saving from a setting the model can see, such as effort or a task budget. A task budget is a beta feature. It shows the model a running token countdown for the whole agentic loop. It is advisory, so max_tokens stays the hard limit.
See also: 5.4 Cost and Token Management
Token Hygiene
The simple way to cut cost by sending fewer tokens: pruning stale tool output, retrieving fewer and better passages, removing unneeded transcript and shrinking oversized images. Documented as a free win, a change that cuts spend without lowering quality.
Exam context: Second only to caching by measurement. In Anthropic's triage-agent run it took an 83 per cent saving to 88 per cent. It sits alongside a prompt audit against the model you actually run, which removes instructions written for an older model that a newer one now follows literally.
See also: 5.4 Cost and Token Management