Claude Models, Prompting & Context Engineering

Model selection questions are almost never "which is best." They give you a workload with a stated constraint and ask which choice serves it. The two wrong instincts are always reach for the most capable model and always reach for the cheapest: both appear as distractors, and both ignore the constraint the scenario put in front of you.

The current lineup, verified against the models overview as of July 2026:

Model	ID	Context	Max output	Input / output per MTok
Claude Fable 5	claude-fable-5	1M	128K	$10 / $50
Claude Opus 5	claude-opus-5	1M	128K	$5 / $25
Claude Sonnet 5	claude-sonnet-5	1M	128K	$3 / $15
Claude Haiku 4.5	claude-haiku-4-5	200K	64K	$1 / $5

Note that Haiku 4.5 is the only one of these with a 200K context window rather than 1M. If a scenario hinges on holding a very large document set in context, that is the differentiator, not raw capability.

Three practical selection rules:

Match the model to the hardest step, not the average one. A pipeline whose steps vary in difficulty does not need one model. Classification and routing can run on a cheaper tier; the step that requires genuine reasoning runs on a more capable one. Mixing tiers across stages is good design.

Do not switch models mid-conversation to save money. Prompt caches are model-scoped, so the switch throws away the cache and you often pay more than you saved. If a sub-task genuinely wants a cheaper model, run it as a separate call or a sub-agent rather than swapping the model on the main loop.

Effort is a real lever, separate from model choice. output_config.effort (low through max) controls how much the model thinks and how much it does. On current models a lower effort setting often delivers comparable quality at a fraction of the latency and tokens, which means "drop to a cheaper model" and "keep the model, lower the effort" are competing answers, and the second is frequently better.

Prompt caching is a prefix match. Any byte that changes anywhere in the prefix invalidates everything after it. Nearly every caching question is this rule applied to a specific mistake.

Content renders in a fixed order: tools → system → messages. A breakpoint on the last system block therefore caches the tools and the system prompt together.

Design follows directly. Stable content must physically precede volatile content. Order things by how often they change: never → per-session → per-turn → per-request. Then place cache_control at the boundary between the stable part and the part that varies.

The economics, from the caching docs:

• Cache read costs ~0.1× the base input price.
• Cache write costs 1.25× base for the default 5-minute TTL, 2× for the 1-hour TTL.

So a 5-minute cache breaks even at two requests (1.25 + 0.1 = 1.35 against 2.0 uncached), and a 1-hour cache needs three (2.0 + 0.2 = 2.2 against 3.0). The 1-hour TTL survives gaps in bursty traffic but needs more reads to pay for itself.

Limits worth remembering: up to 4 breakpoints per request, and a 20-block lookback when searching for a prior cache entry, long agentic turns that add many tool-call blocks can silently blow past that window and miss.

The minimum cacheable prefix is model-dependent, and, this catches people, it is not monotonic across generations:

Model	Minimum
Opus 5, Fable 5, Mythos 5	512 tokens
Opus 4.8, Sonnet 5, Sonnet 4.6, Sonnet 4.5	1,024 tokens
Opus 4.7	2,048 tokens
Opus 4.6, Opus 4.5, Haiku 4.5	4,096 tokens

Below the minimum, nothing caches and no error is raised. That is the diagnostic point: caching fails silently in both directions, too-short prefixes and invalidated prefixes both look like a working system that costs too much.

Verify with the usage object, not by assumption. usage.cache_read_input_tokens is the number that matters. If it stays at zero across repeated requests that should share a prefix, something is invalidating it. The usual culprits, in rough order of frequency:

• a timestamp or now() interpolated into the system prompt
• a request ID or UUID near the front of the content
• JSON serialized without sorted keys, or a set iterated in non-deterministic order
• a user or session ID baked into the system prompt, so nothing is shared across users
• a tool list that varies per request: tools render first, so this invalidates everything

Also note usage.input_tokens reports only the uncached remainder. Total prompt size is input_tokens + cache_creation_input_tokens + cache_read_input_tokens. A long-running agent showing 4K input_tokens is not a small prompt; it is a well-cached one.

A 1M-token context window is not permission to put everything in it. Every token is paid for on every request, and relevance degrades as you pack in material that does not bear on the question.

Four levers, each solving a different problem:

Retrieval: pull only the relevant material in, per request. The default answer for large corpora.

Compaction: when a conversation approaches the window limit, earlier context is summarized server-side into a compaction block. The critical implementation detail: append the full response.content back to your messages, not just the extracted text. The compaction blocks are how the API replaces the compacted history on the next request, and pulling out only the text string silently loses that state.

Context editing: clears stale tool results or thinking blocks outright rather than summarizing them. Compaction summarizes; context editing prunes. Knowing which is which is a fair exam-level distinction.

Memory: persists state across sessions, not just within one. A file the agent reads and writes, surviving process restarts.

Long-running agents commonly use all four: retrieval to get material in, editing to drop stale tool output, compaction as a backstop near the limit, memory for anything that must outlive the session.

Choose the prompting technique by naming the failure mode first. This is the reasoning the exam rewards, and it inverts the usual instinct to apply every technique at once.

• The model does not know the format you want → give worked examples (few-shot). Examples teach shape better than description does.
• The model does not know the domain rules → put them in the system prompt as explicit constraints.
• The model gets the shape right but the reasoning wrong → let it reason before answering, or raise the effort level.
• The model is right but too slow or expensive → this is not a prompting problem. Lower effort, cache the stable prefix, or restructure the call.

A system prompt at production quality establishes role, constraints, and refusal behavior: what to do when the input is out of scope, ambiguous, or adversarial. "What should it do when it can't do the task" is the part most often missing, and it is exactly what separates a demo from a deployment.

Structure prompts as composable templates rather than concatenated strings. This is not tidiness for its own sake: a template with a frozen prefix and a clearly separated variable tail is what makes caching possible at all. Prompt structure and prompt economics are the same problem.

Skills package task-specific instructions and files that the model loads only when relevant. Their description sits in context by default; the full content is read when the task calls for it. That progressive-disclosure property is the point, a large body of specialized guidance stays available without occupying the context window on every request.

One caution worth carrying into any question about instruction strength: on current models, aggressive phrasing ("CRITICAL: you MUST always…") tends to overtrigger. Prompts written to overcome an older model's reluctance now cause the behavior to fire when it shouldn't. If a tool is being over-used, the fix is usually to soften the instruction, not to add another guardrail on top.