# Quiz — Advanced Level, Session 1 # “Claude API: Deep Dive” **Program:** Applied AI — Yann Isola **Format:** 10 MCQs (MCQ = Multiple Choice Questionnaire), certification level *Claude Certified Architect* **Duration:** 20 minutes — only one correct answer per question unless otherwise stated **Threshold:** 7/10 > ⚠ The numerical values (rates, limits, TTL) reflect the documentation at the time of writing and are volatile. --- ### Q1 — Mandatory fields Which fields are **strictly required** in a `POST /v1/messages` query? - A. `model`, `messages`, `system` - B. `model`, `max_tokens`, `messages` - C. `model`, `max_tokens`, `messages`, `temperature` - D. `model`, `messages` — `max_tokens` has a default value **Answer: B.** `system`, `temperature` and other sampling parameters are optional. `max_tokens` has **no** default value: its omission causes a 400 error. Trap in D: unlike other APIs on the market, it is mandatory at Anthropic. --- ### Q2 — stop_reason and HTTP code A JSON extraction returns a document truncated halfway. The HTTP code was 200. What is the most likely explanation and where should it be detected? - A. Error 500 hidden by the SDK; detect via SDK logs - B. `stop_reason: "max_tokens"`; detect by inspecting the `stop_reason` field of the response - C.`stop_reason: "stop_sequence"`; detect via header `anthropic-stop` - D. The model judged the task completed (`end_turn`); it's a prompt problem **Answer: B.** Reaching the limit `max_tokens` is not an HTTP error: the request succeeds (200) but the generation is stopped. The only reliable detection is application-based: test `stop_reason == "max_tokens"` on each response. The C header does not exist. --- ### Q3 — Prefilling You end the table `messages` with `{"role": "assistant", "content": "{"}`. Which statements are accurate? **(two answers)** - A. The model will continue generating from `{`, favoring direct JSON output - B. The character `{` will be included at the beginning of the text returned by the API - C. The character `{` will NOT be included in the response; the client must re-prefix it - D. This query is invalid: `messages` must end with a role `user` **Answers: A and C.** Prefilling is an official technique: the last message can be a partial `assistant` turn that the model extends. Prefixed text belongs on the input, not the output — forgetting it produces invalid JSON (without an opening brace). D is false: only the **first** message should be `user`. --- ### Q4 — System prompt Why is the system prompt called a “privileged channel” rather than a “first message”? - A. It is free: system prompt tokens are not charged - B. It is passed out of the `messages` table and processed by the model with particular priority for personas, rules and exit policies - C. It is end-to-end encrypted, unlike messages - D. It persists automatically between requests without being returned **Answer: B.** The `system` parameter is structurally separated from `messages` and the model is trained to give it particular weight (durable instructions, increased resistance to bypass attempts in `user` rounds).A is false (charged as any input token), C is fancy, D is false — the API is **stateless**: everything must be returned on each call. --- ### Q5 — Context window and costs A conversation assistant accumulates on average 40,000 history tokens returned each round, over 25 rounds. Which architect's statement is correct? - A. Only new tokens of each round are charged; the total cost is marginal - B. Each turn re-invoices the entire entry: the cumulative cost of the conversation increases approximately quadratically with its length, hence the interest in summarizing, truncating or caching - C. The context window automatically empties the middle tokens (“lost in the middle”) - D. The cost is constant per round because the API compresses the history **Answer: B.** Because the API is stateless, the entire history is returned — and billed — each round. The sum of prefixes grows quadratically. “Lost in the middle” (C) is an effect of **degraded recall** of information in the middle of the context, not a deletion of tokens. --- ### Q6 — Prompt caching: economy With prompt caching: which pair (write cost, read cost) is correct, as a percentage of the normal input rate? ⚠ - A. Write 100%, read 50% - B. Writing 125%, reading 10% - C. Writing 90%, reading 25% - D. Write 110%, read 0% (free read) **Answer: B.** ⚠ Writing to the cache costs an additional cost of ~25% (therefore 125% of the price); playing a hit costs ~10% of the price (i.e. ~90% savings). Consequence: the cache is profitable from the **second** request in the TTL window (1.25 + 0.10 < 2.00) — and a cache that is never reread (unstable prefix) costs *more* than no cache at all. --- ### Q7 — Prompt caching: invalidation Which change DOES NOT invalidate the cache of a prefix placed on the system prompt via `cache_control`? - A. Modify a character in the system prompt before the breakpoint - B. Modify the definition of a tool (`tools`) - C. Modify the content of the last message `user` (after the breakpoint) - D. Change model between two calls **Answer: C.** The cache covers the **exact prefix** up to the breakpoint, in the order `tools → system → messages`. Everything **after** the breakpoint can vary freely — this is precisely the target design: stable content at the top, variable question at the tail. A and B modify the prefix; D: the cache is specific to each model. --- ### Q8 — Token counting Which statement about token counting is correct? - A. The number of tokens in a text is identical for all models Claude and GPT (GPT = Generative Pre-trained Transformer), the tokenizer being standardized - B. The `count_tokens` endpoint generates a token response to estimate the total - C. Each family of models has its own tokenizer; the dedicated `count_tokens` endpoint allows you to count a complete request (system + messages + tools) without launching a generation - D. We can only count the tokens after the call, via the field `usage` **Answer: C.** Tokenizers differ between families and publishers — reusing a tiktoken count (OpenAI) for Claude is a classic mistake. The metering endpoint is separate from generation and allows you to validate the context window and estimate the cost **before** paying for a call. D describes *a posteriori* counting, which exists but is not the only one. ---### Q9 — Streaming SSE In an SSE flow (SSE = Server-Sent Events), in which event does the client find the final `stop_reason` and the final count of output tokens? - A.`message_start` -B.`content_block_stop` - C.`message_delta` - D.`message_stop` **Answer: C.** The canonical sequence is `message_start → content_block_start → content_block_delta* → content_block_stop → message_delta → message_stop`. The final metadata (`stop_reason`, `usage.output_tokens`) arrives in **`message_delta`**. `message_stop` (D) is the classic trap: it closes the flow but does not carry these fields; a client that does not parse `message_delta` will never detect a streaming truncation. --- ### Q10 — API Batches For non-urgent classification of 80,000 documents, what combination (discount, SLA, limit, correlation) correctly describes the Batches API? ⚠ - A. −25%; results in 1 hour guaranteed; 10,000 requests max; results returned in order of submission - B. −50%; 24-hour SLA (often much faster in practice); up to 100,000 requests per batch; compulsory correlation by `custom_id` because the order is not guaranteed - C. −50%; real time; 100,000 requests; correlation by array index - D. −90%; 24-hour ALS; unlimited queries; the batch shares conversational memory between requests **Answer: B.** ⚠ 50% discount on input and output, commitment to processing within 24 hours (the majority of batches finish in less than an hour), cap of 100,000 requests (~256 MB). The queries are independent (no shared state — D false) and the results arrive in any order: `custom_id` is the only reliable correlation key. Certification bonus: batch and prompt caching are cumulative (hits not guaranteed). --- ## Correction grid | Q | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | |---|---|---|---|---|---|---|---|---|---|----| | R | B | B | A+C | B | B | B | C | C | C | B | **Analysis of common errors (for the trainer):** - Q2/Q9 combined → review the distinction *HTTP error* vs *business state* and the SSE sequence. - Q6 failed → redo the profitability calculation of block 5 of the guide. - Q10 failed on the order of results → insist: any batch pipeline without `custom_id` is a design defect eliminating certification.