Scenario practice questions

When using the Messages API, a developer wants to ensure that Claude does not use any tools and only provides a standard text response, even if tools are defined in the request. Which configuration should they use?

Trap 1: Omit the 'tools' parameter from the request entirely.

While omitting the 'tools' parameter works, it doesn't solve the developer's specific requirement of having tools defined but not used. In some architectures, the tools list might be static, and the developer needs a way to toggle their usage without re-writing the entire request structure or logic.

Trap 2: Set the 'tool_choice' parameter to {"type": "auto"}.

The 'auto' setting allows Claude to decide for itself whether to use a tool or a text response based on the user's prompt. This does not guarantee that Claude will avoid tools; in fact, if the prompt asks for something tool-related, Claude will likely choose to use one of the tools.

Trap 3: Include a system prompt that says 'Do not use any tools in this…

While Claude is good at following instructions, using a system prompt is a 'soft' constraint. There is still a statistical chance the model might trigger a tool if it finds it highly relevant. Using the 'tool_choice' parameter is a 'hard' API-level constraint that is much more reliable for system architecture.

A
Omit the 'tools' parameter from the request entirely.
Why it fails: While omitting the 'tools' parameter works, it doesn't solve the developer's specific requirement of having tools defined but not used. In some architectures, the tools list might be static, and the developer needs a way to toggle their usage without re-writing the entire request structure or logic.
B
Set the 'tool_choice' parameter to {"type": "none"}.
Setting tool_choice to 'none' explicitly instructs Claude to ignore the tools provided in the 'tools' array. This ensures the model only generates a standard text response, which is essential when you want to use the same code base for both tool-enabled and text-only interactions with the model.
C
Set the 'tool_choice' parameter to {"type": "auto"}.
Why it fails: The 'auto' setting allows Claude to decide for itself whether to use a tool or a text response based on the user's prompt. This does not guarantee that Claude will avoid tools; in fact, if the prompt asks for something tool-related, Claude will likely choose to use one of the tools.
D
Include a system prompt that says 'Do not use any tools in this conversation'.
Why it fails: While Claude is good at following instructions, using a system prompt is a 'soft' constraint. There is still a statistical chance the model might trigger a tool if it finds it highly relevant. Using the 'tool_choice' parameter is a 'hard' API-level constraint that is much more reliable for system architecture.

Question 2easymultiple choice

Which of the following scenarios describes the most effective use of Prompt Caching for cost management?

Trap 1: A chatbot where every user query is unique and no history is…

In this scenario, there is no shared context or prefix between requests. Since prompt caching relies on identifying and reusing the exact same starting sequence of tokens, it provides zero cost benefit for a system that only processes isolated, unique messages without any recurring system prompts or reference documents.

Trap 2: A translation service that processes single words one at a time.

For very small prompts, the overhead of managing a cache and the minimum token requirements for caching often outweigh the benefits. Prompt caching is designed for large blocks of text (like documentation or multi-turn conversations) where the cost of re-processing thousands of tokens is significant, making it overkill and ineffective for single-word translation tasks.

Trap 3: A daily report generator that uses a completely different dataset…

If the dataset changes completely for every request, there is no static prefix to cache. Prompt caching only provides savings when the same tokens are sent in the same order at the beginning of the prompt. A 'daily' change means the cache would be invalidated and rewritten constantly, providing little to no financial advantage for the developer.

A
A chatbot where every user query is unique and no history is maintained.
Why it fails: In this scenario, there is no shared context or prefix between requests. Since prompt caching relies on identifying and reusing the exact same starting sequence of tokens, it provides zero cost benefit for a system that only processes isolated, unique messages without any recurring system prompts or reference documents.
B
A translation service that processes single words one at a time.
Why it fails: For very small prompts, the overhead of managing a cache and the minimum token requirements for caching often outweigh the benefits. Prompt caching is designed for large blocks of text (like documentation or multi-turn conversations) where the cost of re-processing thousands of tokens is significant, making it overkill and ineffective for single-word translation tasks.
C
An AI assistant that references a 50-page technical manual for every user query.
This is the ideal use case for prompt caching. The 50-page manual acts as a large, static prefix that is sent with every request. By caching the manual, the developer only pays the full input price once, and all subsequent queries only pay for the much cheaper cache read tokens, resulting in massive long-term cost savings.
D
A daily report generator that uses a completely different dataset every morning.
Why it fails: If the dataset changes completely for every request, there is no static prefix to cache. Prompt caching only provides savings when the same tokens are sent in the same order at the beginning of the prompt. A 'daily' change means the cache would be invalidated and rewritten constantly, providing little to no financial advantage for the developer.

Question 3hardmultiple choice

A developer is optimizing a Claude-powered chatbot that handles 50,000 daily conversations. Each conversation starts with a 1,200-token system prompt that includes detailed instructions and examples. The system prompt is identical across all conversations. The developer wants to reduce input token costs. Which technique should be applied?

Trap 1: Shorten the system prompt by removing examples.

Removing examples may reduce token count but could degrade response quality and consistency. It also doesn't leverage the fact that the prompt is identical across calls. While it lowers cost, it is not the optimal technique because it sacrifices functionality and does not exploit the repetitive nature of the prompt as effectively as caching does.

Trap 2: Move the system prompt to the first user message.

Moving the system prompt into the first user message does not reduce token count; it merely relocates the same tokens. In fact, it may complicate prompt management and could interfere with how the model interprets system-level instructions. It does not provide any caching or cost benefit compared to keeping it as a system prompt.

Trap 3: Switch to a cheaper model for all conversations.

Switching to a cheaper model might reduce per-token cost but could harm response quality for complex conversations. It does not address the specific inefficiency of repeatedly sending the same 1,200-token system prompt. The scenario asks for reducing input token costs while presumably maintaining quality, making model downgrade a blunt instrument rather than a targeted optimization.

A
Shorten the system prompt by removing examples.
Why it fails: Removing examples may reduce token count but could degrade response quality and consistency. It also doesn't leverage the fact that the prompt is identical across calls. While it lowers cost, it is not the optimal technique because it sacrifices functionality and does not exploit the repetitive nature of the prompt as effectively as caching does.
B
Enable prompt caching for the system prompt.
Prompt caching allows frequently used prefixes, such as a static system prompt, to be stored and reused across API calls. After the first request, subsequent calls that share the same cached prefix are charged at a reduced rate for those tokens. Since the 1,200-token system prompt is identical across all 50,000 conversations, caching it will significantly lower input token costs.
C
Move the system prompt to the first user message.
Why it fails: Moving the system prompt into the first user message does not reduce token count; it merely relocates the same tokens. In fact, it may complicate prompt management and could interfere with how the model interprets system-level instructions. It does not provide any caching or cost benefit compared to keeping it as a system prompt.
D
Switch to a cheaper model for all conversations.
Why it fails: Switching to a cheaper model might reduce per-token cost but could harm response quality for complex conversations. It does not address the specific inefficiency of repeatedly sending the same 1,200-token system prompt. The scenario asks for reducing input token costs while presumably maintaining quality, making model downgrade a blunt instrument rather than a targeted optimization.

Question 4mediummulti select

A developer is writing an MCP client that must stay responsive while a server performs a slow operation during a tool call. The client should allow the user to cancel the request without terminating the whole session, and the server should be able to stream incremental output before finishing. Which two MCP features should the developer implement? (Choose two.)

Trap 1: Polling tools/list repeatedly to detect when the tool has finished…

tools/list enumerates available tools and their schemas; it reports nothing about the execution state of a specific call. Polling it would add load and still never reveal completion or partial output, so it does not provide progress or cancellation behavior for the slow operation.

Trap 2: Closing the transport and reinitializing the session to interrupt…

Dropping the transport aborts everything in the session, not just the one slow call, and forces a fresh initialize handshake. It is a blunt instrument that discards unrelated in-flight work and state, so it fails the requirement to cancel a single request while keeping the session alive.

Trap 3: Setting a long client-side timeout and retrying the same request…

Retrying a slow tool call risks duplicate side effects and provides no incremental output or user-driven cancellation. A long timeout simply makes the client wait blindly, which is the opposite of staying responsive, so this approach does not meet either stated requirement.

A
Request cancellation using the notifications/cancelled notification with the in-flight request ID.
A client can cancel an in-flight request by sending notifications/cancelled with the request ID it wants to abort. The server stops work on that specific request while the session and other requests continue, which matches the requirement to cancel without tearing down the whole connection.
B
Polling tools/list repeatedly to detect when the tool has finished executing.
Why it fails: tools/list enumerates available tools and their schemas; it reports nothing about the execution state of a specific call. Polling it would add load and still never reveal completion or partial output, so it does not provide progress or cancellation behavior for the slow operation.
C
Closing the transport and reinitializing the session to interrupt the operation.
Why it fails: Dropping the transport aborts everything in the session, not just the one slow call, and forces a fresh initialize handshake. It is a blunt instrument that discards unrelated in-flight work and state, so it fails the requirement to cancel a single request while keeping the session alive.
D
Progress notifications sent from the server using the progress token supplied by the client.
MCP allows a client to attach a progressToken to a request, and the server can emit notifications/progress messages referencing that token. This gives incremental feedback during a long-running tool call, satisfying the streaming-output requirement without ending the request or the session.
E
Setting a long client-side timeout and retrying the same request until it succeeds.
Why it fails: Retrying a slow tool call risks duplicate side effects and provides no incremental output or user-driven cancellation. A long timeout simply makes the client wait blindly, which is the opposite of staying responsive, so this approach does not meet either stated requirement.

Question 5mediummultiple choice

A company needs to summarize 500 academic papers, each approximately 20,000 tokens long. The summaries are needed for a weekly report due in three days. Which approach provides the best balance of cost-efficiency and model capability for this specific task?

Trap 1: Real-time Claude 3.5 Sonnet with Prompt Caching.

Prompt Caching is most effective when the same content is repeated across many requests. Since each of the 500 academic papers is unique, Prompt Caching would offer little to no benefit. The developer would pay full price for almost all input tokens, making this more expensive than using the Batch API.

Trap 2: Real-time Claude 3 Haiku.

While Haiku is cheaper than Sonnet, it may struggle with the complex reasoning and nuances required to accurately summarize 20,000-token academic papers. The loss in quality might outweigh the cost savings, especially when a more capable model like Sonnet could be used at a discount via the Batch API.

Trap 3: Claude 3 Opus via the Message Batch API.

Even with the 50% Batch API discount, Opus is significantly more expensive than Sonnet 3.5. Given that Sonnet 3.5 is generally more capable and faster for summarization tasks, choosing Opus would lead to higher costs without a proportional increase in the quality of the academic summaries produced.

A
Real-time Claude 3.5 Sonnet with Prompt Caching.
Why it fails: Prompt Caching is most effective when the same content is repeated across many requests. Since each of the 500 academic papers is unique, Prompt Caching would offer little to no benefit. The developer would pay full price for almost all input tokens, making this more expensive than using the Batch API.
B
Real-time Claude 3 Haiku.
Why it fails: While Haiku is cheaper than Sonnet, it may struggle with the complex reasoning and nuances required to accurately summarize 20,000-token academic papers. The loss in quality might outweigh the cost savings, especially when a more capable model like Sonnet could be used at a discount via the Batch API.
C
Claude 3.5 Sonnet via the Message Batch API.
The Batch API is perfect for this scenario because the deadline is three days away and the volume is high. It allows the company to use the highly capable 3.5 Sonnet model while benefiting from a 50% cost reduction, making it the most balanced choice for quality and budget.
D
Claude 3 Opus via the Message Batch API.
Why it fails: Even with the 50% Batch API discount, Opus is significantly more expensive than Sonnet 3.5. Given that Sonnet 3.5 is generally more capable and faster for summarization tasks, choosing Opus would lead to higher costs without a proportional increase in the quality of the academic summaries produced.

Question 6mediummultiple choice

Refer to the exhibit. If this request is sent to Claude, what will be the result of the generated output?

Exhibit

{
  "model": "claude-3-5-sonnet-20240620",
  "max_tokens": 1024,
  "messages": [
    {"role": "user", "content": "Analyze this log: <log>ERROR 404</log>. Use <thought> tags for logic."}
  ],
  "stop_sequences": ["</thought>"]
}

Trap 1: The model will ignore the stop sequence because it is inside an XML…

Stop sequences are treated as literal strings and are not affected by XML structure. If the model generates the characters '</thought>', the generation will cease regardless of the context. The API does not distinguish between tags and plain text when evaluating stop sequences during the inference process.

Trap 2: The API will return an error because the stop sequence must be a…

Stop sequences can be any string, including multiple words, special characters, or XML tags. There is no requirement for them to be a single word. In fact, using closing XML tags or newline characters is a very common and recommended practice for controlling the output format of Claude.

Trap 3: The model will generate the full answer, but the </thought> tag…

A stop sequence does not just hide the specified string; it stops the generation of any subsequent tokens. Therefore, anything that would have naturally followed the '</thought>' tag in the model's response will never be produced by the model. This results in a truncated response rather than a filtered one.

A
The model will output its reasoning and then stop, omitting the final answer.
Because the stop sequence is set to the closing tag of the reasoning block, the API will cut off the response the moment that tag is generated. This is useful for developers who only want to see the internal logic or who are running a multi-step pipeline where reasoning is the only required output.
B
The model will ignore the stop sequence because it is inside an XML tag.
Why it fails: Stop sequences are treated as literal strings and are not affected by XML structure. If the model generates the characters '</thought>', the generation will cease regardless of the context. The API does not distinguish between tags and plain text when evaluating stop sequences during the inference process.
C
The API will return an error because the stop sequence must be a single word.
Why it fails: Stop sequences can be any string, including multiple words, special characters, or XML tags. There is no requirement for them to be a single word. In fact, using closing XML tags or newline characters is a very common and recommended practice for controlling the output format of Claude.
D
The model will generate the full answer, but the </thought> tag will be hidden.
Why it fails: A stop sequence does not just hide the specified string; it stops the generation of any subsequent tokens. Therefore, anything that would have naturally followed the '</thought>' tag in the model's response will never be produced by the model. This results in a truncated response rather than a filtered one.