2.4 Extended Thinking, Prompt Caching, Batch & Vendor Choice
2.4.1 Extended Thinking: A Cost Lever, Not a Free Upgrade
Turning on a thinking budget lets Claude produce internal reasoning before its final answer, which improves performance on hard, multi-step tasks. The catch that the exam leans on hard: thinking tokens are billed as output tokens. Extended thinking is a capability-vs-cost lever, not a free quality upgrade -- reserve it for the steps whose reasoning depth genuinely pays for the added tokens and latency, not uniformly across an entire pipeline.
# A mixed-effort pipeline: thinking only where the reasoning depth pays off
classification = client.messages.create(
model="claude-haiku-4-5", max_tokens=64,
messages=[{"role": "user", "content": f"Classify this ticket: {ticket_text}"}],
) # cheap, fast -- no extended thinking needed for a routine classification
decision_memo = client.messages.create(
model="claude-opus-4-5", max_tokens=4096,
thinking={"type": "enabled", "budget_tokens": 8000}, # reserved for the hard step
messages=[{"role": "user", "content": f"Synthesize a recommendation from: {findings}"}],
)Extended thinking also imposes a non-negotiable structural requirement on multi-turn, tool-using conversations: every thinking block the API returns must be passed back on the next request completely unchanged. Each thinking block carries an opaque signature field the API uses to confirm the reasoning it's receiving back is exactly what it produced -- not edited, not summarized, not reconstructed. Modify the block in any way and the signature no longer matches; the API rejects the request rather than silently accepting tampered reasoning.
This applies identically to redacted (encrypted) thinking blocks. Their contents are ciphertext -- unreadable, not meant to be inspected -- but that does not exempt them from the rule. They still have to be returned in the same position, completely untouched, on the next turn. The most common way this gets violated: a developer worried about context growth strips thinking blocks out of history before resending it to save tokens. That optimization breaks the very next request. If context budget is the real concern, the fix is the context-engineering toolkit applied to the conversation as a whole -- not surgery on an individual thinking block.
Exam trap
Stripping or summarizing a thinking block to save context before the next tool-use turn breaks its signature and fails the very next request -- this applies to redacted/encrypted thinking blocks too, even though their content can't be read.
2.4.2 Prompt Caching: Discount a Reused, Stable Prefix
Mark a stable prefix -- a system prompt, long reference documents, tool definitions -- with cache_control so it's cached server-side. Requests that reuse that identical prefix pay a large discount on the cached tokens and start faster, since the cached portion doesn't need to be reprocessed from scratch. Cache writes cost a bit more than normal input tokens (a one-time premium the first time a prefix is cached); cache reads are much cheaper. The economics only work when many requests actually share a long, unchanging prefix -- caching a prefix that's different on every call has nothing to discount.
# Stable content first and marked cacheable; variable content goes last
messages = [{
"role": "user",
"content": [
{
"type": "text",
"text": LONG_POLICY_DOCUMENT, # long, stable, reused every request
"cache_control": {"type": "ephemeral"},
},
{"type": "text", "text": user_specific_question}, # varies every request, goes last
],
}]Where this shows up on the exam
Prompt caching pays off precisely when many requests share a long, unchanging prefix. If every request's content is different, there's no repeated prefix to discount and caching adds a write premium for no later benefit.
2.4.3 Putting the Levers Together
These four levers -- extended thinking, prompt caching, batch processing, and vendor choice -- are easy to study in isolation and easy to misapply in combination, because a real system typically needs more than one at once. A high-volume, cost-sensitive, latency-tolerant workload that also happens to share a long stable system prompt across every request is a batch job that should also be cached where the batch API supports it; an interactive, low-volume, high-stakes workload that occasionally needs deep multi-step reasoning is a realtime, streaming integration that reserves extended thinking for just the hard step, not the entire turn.
The exam's scenario questions on this task statement often describe a workload with two or three relevant signals at once (a stable prefix AND high volume AND a tolerant deadline, say) specifically to test whether you reach for one lever when the requirement actually calls for a combination. Treat each signal in the scenario as pointing at a specific lever, and don't stop analyzing once you've found the first one that fits.
Study tactic
Extended thinking, prompt caching, batch processing, and vendor choice answer four different questions: how much reasoning, what's reused, how urgent, and which cloud. A scenario can require more than one lever at once -- don't stop at the first match.
2.4.4 The Message Batches API for Bulk, Tolerant Work
For large, latency-tolerant workloads, submit many requests as a single asynchronous batch instead of many synchronous calls. Anthropic processes the batch within a 24-hour window at a substantial per-token discount -- roughly half the standard rate. This is the correct choice for an overnight bulk job where cost matters more than immediacy, and it is a distinct API, not a description of firing many realtime calls at once.
| Need | Use |
|---|---|
| Interactive, user is waiting right now | Messages API (realtime), often with streaming |
| High volume, results tolerable within 24h, cost-sensitive | Message Batches API |
The realtime-vs-batch decision, straight from the five extraction questions in 2.1.
Exam trap
"Batch is just parallel realtime calls" is a persistent misconception. The Message Batches API is a distinct asynchronous API with its own 24-hour SLA and a real per-token discount -- firing many synchronous requests concurrently doesn't capture that discount and isn't the same mechanism.
The exact limits are concrete and testable: a single batch call accepts up to 100,000 requests or 256 MB, whichever limit is hit first. Submitting the batch returns a batch_id immediately -- the batch has only been accepted, not processed yet. Your application polls using that id until the batch reports completion, then downloads the results.
The order results come back in bears no relationship to the order requests were submitted in -- that's documented API behavior, not an edge case to guard against defensively. Because of that, every request in a batch needs its own custom_id, since that's the only dependable way to tie a returned result back to whichever input produced it. Code that pairs results with the original request list purely by position will silently scramble inputs and outputs the moment the API's ordering diverges from submission order, which it's free to do on any given call.
batch = client.messages.batches.create(requests=[
{"custom_id": "ticket-001", "params": {"model": "claude-sonnet-4-5", "max_tokens": 256,
"messages": [{"role": "user", "content": ticket_1}]}},
{"custom_id": "ticket-002", "params": {"model": "claude-sonnet-4-5", "max_tokens": 256,
"messages": [{"role": "user", "content": ticket_2}]}},
# ... up to 100,000 requests OR 256 MB total, whichever limit is hit first
])
results_by_id = {}
for result in client.messages.batches.results(batch.id):
results_by_id[result.custom_id] = result # never assume result order == submission order2.4.5 Vendor Choice: Direct API, Bedrock, Vertex AI
The same Claude models are available through Amazon Bedrock and Google Vertex AI, in addition to Anthropic's direct API. The message format is largely consistent across all three -- what differs is authentication, endpoint/region, and model-ID naming, not the underlying model's behavior. Choose a vendor for reasons like existing cloud footprint, data-residency requirements, and procurement constraints, not because one vendor is expected to produce a qualitatively different answer from the same model.
- •Existing cloud footprint -- already deep in AWS or GCP tooling and billing.
- •Data residency -- regulatory requirements about where requests and data are processed.
- •Procurement -- existing vendor contracts or approval processes that favor one path.
- •None of these change what the model itself does -- they change the integration mechanics around it.
Key Takeaways
- ✓Extended thinking produces internal reasoning before the answer, but thinking tokens are billed as output tokens -- reserve it for steps whose reasoning depth pays for the cost, not as a default.
- ✓Prompt caching (cache_control) discounts and speeds up requests that reuse an identical, stable prefix; it delivers the most benefit when many requests share a long, unchanging prefix, not when every request differs.
- ✓Cache writes cost a bit more than normal input; cache reads are much cheaper.
- ✓The Message Batches API processes many requests asynchronously within 24 hours at a substantial per-token discount -- it is a distinct API, not parallelized synchronous calls.
- ✓Amazon Bedrock and Google Vertex AI host the same Claude models as the direct API; differences are auth, endpoint/region, and model-ID naming, not model behavior. Vendor choice follows cloud footprint, data residency, and procurement.
- ✓Every thinking block carries a signature and must be passed back to the API completely unchanged on the next turn -- this applies to redacted/encrypted thinking blocks too, even though their content is unreadable.
- ✓A single Message Batches API call accepts up to 100,000 requests or 256 MB, whichever limit is hit first, and returns a batch_id you poll for completion.
- ✓The order batch results arrive in has no fixed relationship to submission order -- every request needs a custom_id to tie its result back to it; matching by position breaks silently.
Check Your Understanding
Test what you learned in this lesson.
Q1.When does prompt caching deliver the most benefit?
Q2.A developer enables extended thinking on every call in a pipeline, including simple ticket-classification steps. What's the issue?
Q3.A team needs to process 50,000 documents overnight and states cost as the primary concern. Which is the correct mechanism, and why?
Q4.A company already has deep AWS infrastructure and a data-residency requirement met by their existing AWS region. What most directly informs their choice to access Claude via Amazon Bedrock instead of the direct API?
Q5.A developer strips thinking blocks out of a multi-turn, tool-using conversation's history to save context before the next request. What happens?
Q6.A batch of 60,000 requests is submitted to the Message Batches API. When the results come back, in what order do they arrive, and how should the application match them to their original inputs?
Practice This Lesson