Claude Models, Prompting & Context Engineering

This slice of the blueprint is about economics and control, not clever wording. The items ask you to match a model tier to a workload profile, to decide where knowledge lives at inference time, and to say what a system prompt can and cannot guarantee.

The trap is treating model choice as a quality ranking and prompts as disposable text. Candidates reach for the strongest tier by reflex, then meet a scenario with a fixed budget, a latency SLO, or a million-call-a-day classification path where the reasoning tier is the wrong instrument. The same instinct treats context as free — pasting an entire corpus into every request instead of retrieving it, caching it, or fetching it with a tool.

The idea that unlocks the domain: context is a budget you allocate, and a prompt is a versioned asset you own. Decide per workload what must stay resident (stable instructions, schemas, exemplars — all cacheable), what should be retrieved on demand, and what should be delegated to a tool. Then route to the cheapest tier that clears the bar, and let evaluation, not preference, promote or demote it.

• Profile the workload before you name a model. Volume, latency SLO, reasoning depth, cost of a wrong answer. The tier follows the profile, not the demo.
• Haiku for high-volume, latency-sensitive, well-bounded work: classification, extraction, routing, guardrail checks, cheap sub-agents inside a larger loop.
• Sonnet as the default workhorse: agentic tool loops, code, RAG synthesis, anything where quality and unit cost both matter.
• Opus where failure is expensive or the task is genuinely hard: ambiguous multi-step reasoning, architecture and research, and as the grader in an eval harness.
• Start high, then route down. Establish the achievable ceiling on the strongest tier, then demote until eval scores break. Starting cheap confuses model limits with prompt defects.
• Mixed-tier pipelines beat single-tier ones. A cheap tier drafts, extracts and triages; an expensive tier sees only escalated, low-confidence or high-risk cases.
• The system prompt is a contract: role, scope boundaries, tool-use policy, refusal and escalation rules, output schema. Durable policy never rides in the per-turn user message.
• Order the prompt for cache hits. Stable first — system prompt, tool definitions, schemas, exemplars, long static documents; volatile last — user turn and retrieved snippets. Cache breakpoints go only after immutable prefixes.
• Resident, retrieved or tool-called? Small and always relevant, keep it in context. Large corpus where few pieces matter, retrieve it. Live, authoritative or transactional, call a tool.
• Long context is not free context. Cost, latency and attention dilution all rise together; relevance density beats raw token count.
• Few-shot exemplars are the cheapest quality lever — spend them on edge cases and the exact output format, not the happy path.
• Version prompts like code: stable ID, named owner, changelog, eval gate before promotion, one-step rollback. No silent edits to a production prompt.

• One tier for everything is the signature mistake. Uniform Opus burns the budget on classification; uniform Haiku fails the small fraction of cases that carry all the risk.
• Prompt-as-config-string. Text pasted into code and duplicated per service drifts apart within weeks — no owner, no diff, no rollback, no shared guardrails.
• Window stuffing. Dumping the knowledge base into every call instead of retrieving: cost scales linearly with tokens, recall of the middle degrades, and the cache stops helping.
• Cache invalidation by carelessness. A timestamp, session ID or freshly shuffled retrieval block placed in the prefix voids the cached segment and silently doubles spend.
• Guardrails in the wrong layer. Instructions steer, they do not enforce. Anything that must never happen needs scoped tool permissions, output validation or a filter outside the model.
• Treating retrieved text as trustworthy. Documents, web pages and tool results are data, not instructions — delimit them, label them untrusted, and say so in the system prompt.
• Unbounded conversation growth. Long agent runs need compaction, summarization or external state, or they exhaust the window mid-task and lose the plan.
• Migration without a regression suite. Tier changes and prompt edits need a golden set and side-by-side scoring; "it looked fine in the console" is not a rollout criterion.
• Optimizing the wrong number. Price per million tokens is not cost. Measure cost per successfully resolved task, with retries, escalations and human review included.
• Output-token blindness. Verbose formats and unbounded reasoning often dominate spend; constrain schema, length and stop conditions.
• Prompt sprawl across teams. With no shared library of system-prompt fragments and templates, every team re-derives the guardrails and each one misses a different rule.
• How scenarios are framed: you are given a constraint — budget, SLO, volume, risk — and asked for the tier and context strategy that satisfies it. The right answer is the cheapest option that meets every stated constraint, not the most capable one.

TIERS — the order to make model and context decisions in.

• T — Task profile. Volume, latency SLO, reasoning depth, cost of a wrong answer. No tier discussion before this exists.
• I — Instructions. Write the system prompt as a contract: role, scope, tool policy, refusal and escalation rules, output schema.
• E — Evidence. Decide per fact whether it is resident in context, retrieved on demand, or fetched by a tool call.
• R — Reuse. Promote the prompt to a versioned asset: ID, owner, template library, eval gate, rollback path.
• S — Spend. Order the prompt for cache hits, cap output tokens, batch what is not interactive, and measure cost per resolved task.

Use it whenever a scenario names a budget, an SLO or a volume — walk TIERS in order and the constraint eliminates options for you.