Autoregressive Generation
The mechanism underneath every Claude response: the model emits one token at a time, each conditioned on the whole sequence so far, its own output included. 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 get keyed. Generation is serial, so response time scales with output length. There is no lookahead and no revision, so a contract stated before the task beats a correction bolted on after. And each token conditions the next, so an early wrong turn compounds instead of self-correcting.
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 carries two that disagree with each other, roughly 3.5 characters per token in the glossary and roughly 4 characters or 0.75 words in the pricing FAQ, and that disagreement is itself the argument for measuring.
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 carried across a migration is wrong twice over: once for the cost model, once for the window headroom. Recount, every time you change models.
See also: 5.1 LLM Fundamentals
Token Counting Endpoint
POST /v1/messages/count_tokens, which accepts the same structured inputs as a real message, system prompt, tools, images and PDFs included, and 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 prices a request shape 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 is load-bearing rather than incidental. Options claiming that counting costs money or returns a guaranteed figure are wrong on both counts.
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 headroom, 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. Both corollaries are routinely got backwards in distractors.
See also: 5.1 LLM Fundamentals
model_context_window_exceeded
The stop_reason returned when a request was accepted but generation ran into 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 discriminator against the other overflow branch 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 budget arithmetic with 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 August 2026 it is deprecated alongside top_p and top_k, returning a 400 on a non-default value on Claude 4.7 and later, with the recommended replacement "Omit and use prompting to guide model behavior". The docs are not internally consistent here, since the reducing-latency page still suggests experimenting with it, so treat the deprecations table and the Thinking page as the authority.
See also: 5.1 LLM Fundamentals
Non-Determinism
The property that identical inputs can produce different outputs across API calls. Stated first-party 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 most durable claim in the domain, because it describes the service rather than a release. Temperature zero buys consistency, not reproducibility. Any option promising byte-identical output for identical input is wrong, and the keyed fix is always a demonstrated format, an explicit output contract and validation at the boundary.
See also: 5.1 LLM Fundamentals
Adaptive Thinking
The delegation form of reasoning control, set with thinking: {type: "adaptive"}, which lets Claude "decide when and how deeply to think based on the request". As of 14 October 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.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 carries the older extended thinking form instead. As of 14 October 2026 every current model has it, Claude Haiku 5.5 included, and Haiku 4.5 is a legacy model. A design needing self-regulated reasoning depth rules out any model without it, Haiku 4.5 among them, on capability before cost enters the argument. To see the reasoning, read the thinking blocks: on Claude Fable 5.1, Opus 5.5, Opus 5, Sonnet 5.5 and Fable 5, asking for it in the response text can be refused with stop_details.category: "reasoning_extraction", a category billed even when the refusal arrives before any output.
See also: 5.1 LLM Fundamentals
Effort
The parameter set through output_config, with levels low, medium, high, xhigh and max, trading 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", and setting it to the model's default behaves exactly as omitting it.
Exam context: The workhorse and the first lever to try, because it "applies to every output token", so "it works whether or not thinking is enabled", and it covers tool calls too, 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 lever than switching models.
See also: 5.1 LLM Fundamentals
Fast Mode
A research-preview inference configuration, opted into with speed: "fast" and the fast-mode-2026-02-01 beta header, 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 trade quality. Its gain is in output tokens per second, "not time to first token (TTFT)", so it tells on long streamed answers and barely registers on short ones. As of September 2026 it covers Claude Opus 5.5, Opus 5 and Opus 4.8 on the Claude API only, 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 vocabulary runs 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. Reach for examples on a failure of form or of boundary, never on a failure of budget or of 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 a raw request hits.
Exam context: The half items are actually written on 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 the ergonomics of calling 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 keyed 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 compose, so worst-case wall clock is roughly the timeout multiplied by the attempt count. A loop stacked on top of the defaults multiplies attempts, re-sends deterministic failures that will never succeed, and pushes a rate-limited endpoint further into the limit. Set it at one layer and let the other decide whether to degrade, queue or fail loudly. The retried set is not the same as the transient set: as of September 2026 a usage tier's spend-cap 429 (no retry-after, an error_code of enforced_spend_limit_reached) is retried too, and 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 say mid-generation. Streaming is also sometimes obligatory rather than optional, but 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: The reliable item shape is the right transport 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, paying a fresh TLS handshake and multiplying open sockets. The defect only shows under concurrency, presenting as latency that grows with traffic and connection errors that look like an upstream problem, which is exactly the symptom set a stem will describe.
See also: 5.2 Technical Fundamentals
Cost and Capability Ordering
The stated ranking of the current line-up. As of 14 October 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.1 (the frontier model)". A month earlier the same sentence began with Claude Haiku 4.5 and Claude Sonnet 5. Comparative latency runs the other way.
Exam context: The ordering is durable; the identifiers, prices and line-up are dated and belong on the quick reference. The consequence worth carrying: quality, latency and cost are not independent axes, so moving up the ordering buys capability and spends 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, 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 home ground: 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 stem picks one, and an answer that applies either strategy as dogma 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 home ground: 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 September 2026 the page starts on Claude Opus 5.5 and moves to the frontier Claude Fable 5.1 only if evals at xhigh or max effort still fall short. Note where the optimisation goes, into effort before tier. An effort sweep on the model you are already running competes directly with a tier change, and documentation states that tuning effort is often the better lever.
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 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 an evergreen pointer.
Exam context: Pinning means the snapshot you are on does not change underneath you, 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 may 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. Distractors trade on exactly those confusions. Anthropic provides "at least 60 days' notice before model retirement for publicly released models", which is a planning window rather than a reprieve. 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 loudly: manual thinking with budget_tokens, assistant prefill and non-default sampling parameters all return a 400 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 carrying everything else across unchanged is the shape of that quiet failure.
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 those counts at their own rates (cache writes at the 5-minute or 1-hour multiplier), 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, a 1-hour write 2x, and a read or refresh 0.1x on most models (0.05x on Claude Opus 5.5, 0.025x on Claude Fable 5.1 and Mythos 5.1). "A cache hit costs 10% of the standard input price, which means caching pays off after one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write)."
Exam context: Key on the shape rather than the figures. A write costs more than not caching, so a single-use prefix loses money outright, and describing caching as pure saving with no write cost is a distractor. 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 token floor below which a prompt "is processed without caching". As of 14 October 2026 it runs from 512 tokens on the newest models (Claude Fable 5.1, Mythos 5.1, Opus 5.5, Opus 5, Sonnet 5.5, Fable 5, Mythos 5 and Haiku 5.5) up to 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 a handler to swallow and nothing in the logs to notice. It is the reason "large" is one of the four conditions rather than a nicety.
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 eaten most of the shorter lifetime before the next request begins. A bursty arrival pattern is where the choice between the two durations stops being configuration and becomes arithmetic.
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 settled transcript 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. /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, groupable "by API key, workspace, model, service tier, context window, data residency, or speed", and /v1/organizations/cost_report returns cost breakdowns in USD.
Exam context: Third of the three instruments, and options offering one for another's job are wrong by construction. It needs an Admin API key rather than a standard one, is "unavailable for individual accounts", surfaces data within about five minutes, and supports polling once a minute. Measuring a change against a monthly invoice is the distractor, 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, but only for work nobody is waiting on. The discount is paid for in delivery time, 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 September 2026: "A task budget saves money, because the model sees it. max_tokens is a safety cap: lowering it cut cost per attempt without lowering cost per solved task." 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 reliable distractor in the 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 inverts the instinct: set it high enough that nothing is cut off, and "treat stop_reason: max_tokens as a failure". Take the saving from a lever the model can see, such as effort or a task budget. A task budget is a beta that shows the model a running token countdown for the whole agentic loop; it is advisory, so max_tokens stays the hard ceiling.
See also: 5.4 Cost and Token Management
Token Hygiene
The plain send-less lever: pruning stale tool output, retrieving fewer and better passages, dropping dead transcript and right-sizing images. Documented as a free win, one that cuts spend without touching 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