A customer service platform uses Claude with a 12,000-token system prompt containing comprehensive product knowledge, tone guidelines, and escalation rules. Response latency at P95 is 8.2 seconds, which is above the 5-second SLA. The team identifies that 70% of the system prompt is product catalog data that changes monthly. They're evaluating: (A) prompt caching on the full system prompt, (B) moving product catalog to RAG and shrinking the system prompt, (C) splitting into a 2,000-token core system prompt plus dynamic context injection per query. Which optimization strategy should be prioritized FIRST, and why? A load test with caching enabled brings P95 down to 6.3 seconds.

The sequenced plan is right because the stem gives measured evidence for both halves of it. Prompt caching reuses the processed prefix of a repeated prompt, and Anthropic's documentation says it generally improves time to first token for long prompts while cache reads bill at a fraction of the base input price. That makes it the fastest, lowest-risk change to ship first. The load test, however, shows caching alone lands P95 at 6.3 seconds, still above the 5-second SLA, so a second step is required. Moving the monthly-changing catalog, about 70% of the prompt, into retrieval shrinks every request and also removes the cache invalidation that each catalog update would cause. Relying on caching alone fails because it claims the SLA will be met when the measured result already shows it is not. Starting with the retrieval migration delays any relief for weeks while a cheap improvement sits unused. Starting with a core-prompt-plus-injection refactor reorganizes the prompt without reducing tokens by itself and still has to choose caching or retrieval afterward. On the exam, prefer the answer that fits the numbers in the stem over one that promises an outcome the data contradicts. Operationally, re-run the P95 load test after each phase and track cache hit rate alongside latency.