Model Selection and Optimization
Free Claude Certified Developer (CCDV-F) practice — 6 questions on Model Selection and Optimization, with explanations. No sign-up. Full 12-question mixed test →
A fintech company processes 40,000 customer support conversations per day through Claude, currently sending every conversation to Opus. Finance mandates a 60% cost reduction, but quality must not drop on complex billing disputes that require multi-step reasoning. Which approach BEST achieves this?
Tiered routing matches model capability to task complexity: Haiku serves the high-volume routine tier at a small fraction of Opus pricing, while Opus is reserved for the disputes that need it. Prompt caching further cuts the repeated system-prompt input cost across 40,000 daily conversations.
A document-processing platform extracts structured data from 2 million pages per month using Sonnet. Results are delivered to customers within 24 hours, not interactively. The extraction instructions are identical across requests, and costs must come down significantly without changing models. Which combination is MOST cost-effective?
The workload is asynchronous with a 24-hour delivery window - exactly what the Batch API's discounted pricing is designed for - and a cached shared instruction prefix eliminates most repeated input-token cost across 2 million near-identical requests.
A financial services application processes 50,000 document classification requests daily. Each request includes a 4,000-token context (account history) that remains static for 24 hours, plus a 200-token variable query. The application currently uses Claude 3.5 Sonnet with prompt caching disabled. Which optimization will provide the greatest cost reduction while maintaining performance?
Prompt caching provides a 90% discount on cached tokens (cache reads) versus standard input tokens. With 4,000 static tokens per request × 50,000 requests, caching the static context saves ~180M tokens daily at cache-read pricing versus fresh input pricing. Cache writes occur once per 5-minute TTL window, making the write overhead negligible. This delivers 85-90% cost reduction on the bulk of input tokens while maintaining Sonnet's quality.
An e-commerce platform routes customer service inquiries using this pattern: Claude 3.5 Haiku analyzes sentiment and intent, then escalates complex cases to Claude 3.5 Sonnet. During a promotional campaign, 40% of inquiries are escalated. Average response times are Haiku: 800ms, Sonnet: 2.1s. The business requires 95th percentile response time under 3 seconds. Which change will meet the latency requirement with minimal cost increase?
Current 95th percentile for escalated requests is ~2.9s (800ms Haiku + 2.1s Sonnet), barely under the 3s limit. Async escalation returns the Haiku response immediately (800ms), meeting the latency SLA for 100% of requests. Background Sonnet escalation still improves quality for 40% of cases without blocking the user. This maintains cost efficiency (60% Haiku-only, 40% both) while guaranteeing latency compliance.
A legal document analysis system uses Claude 3.5 Sonnet with extended thinking enabled (budget: 10000 tokens). The system processes 30-page contracts (avg 15,000 input tokens) and generates 2,000-token summaries. Extended thinking typically uses 6,500 tokens. After enabling prompt caching on the contract text, costs increased by 12% instead of the expected 60% decrease. What is the MOST likely cause?
Prompt caching has a 5-minute TTL. With 8-minute gaps between batches, every request triggers a cache write (charged at 25% above standard input token rates) for the 15,000 tokens, then immediately misses on the next request. Cache writes cost 1.25× versus 0.1× for cache reads. This results in 1.25× cost versus the baseline (1.0×) instead of the expected ~0.1× from cache hits, explaining the 12% cost increase. Sequential processing with >5min gaps defeats caching.
A code review application uses this two-stage process: (1) Claude 3.5 Sonnet identifies potential issues with extended thinking (budget: 8000), (2) Claude 3 Opus with extended thinking (budget: 15000) reviews complex issues flagged in stage 1. The team wants to add adaptive thinking to stage 2 to handle variable complexity. What is the primary technical tradeoff of enabling adaptive thinking for the Opus stage?
Adaptive thinking (thinking.type: 'adaptive') allows the model to dynamically use only the thinking tokens needed for each request, up to the specified budget. For simpler flagged issues, Opus might use 3,000 thinking tokens instead of the full 15,000, saving ~80% of thinking token costs on those requests. Complex issues still get the full budget. This provides cost efficiency for variable-complexity workloads while maintaining quality. The tradeoff is that cost per request becomes less predictable.
Ready for the real thing?
The full course: two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed explanations.
$54.99 $17.99 with code FREETEST33 — valid through September 1.
Get my $17.99 deal →