Prompt & Context Engineering Best Practices

Cutting token spend and protecting answer quality are not competing goals: the same discipline usually achieves both at once.

This is a standalone checklist of practices for deciding what goes into a prompt, which model handles it, and how a long-running agent manages its context over time.

How to Use This Checklist

• Treat each category as a review pass over a specific prompt, task, or agent, not a one-time global audit.
• Check items off against a real workload, not in the abstract; a rule that sounds right but has no measured effect on your task isn't worth enforcing.
• Revisit this list whenever a task's inputs, volume, or stakes change meaningfully.
• Pair every rule here with an actual evaluation set where possible; a best practice without a way to measure its effect is a guess dressed up as a rule.

A - Minimize What You Send

• Send only the snippets a task needs, not entire files or repositories. Trimming to relevant material removes tokens outright, with no extra API call required.
• For code tasks, use a dependency graph to select relevant files rather than guessing. A one-hop neighborhood of imports and importers is usually enough context for a single-file change.
• Trim structured data (JSON, database rows) to an explicit allowlist of fields. An allowlist is safer than a denylist, since new fields added later won't silently leak into prompts.
• Drop stale conversation history that no longer affects the current task. Every prior turn kept in a multi-turn conversation is resent as input tokens on every future call.
• Measure token counts before and after trimming, not just intuition. A quick count_tokens call turns "this feels smaller" into a number you can track over time.

B - Summarize Reusable Long Documents

• Use a cheap, fast model to pre-condense long documents before sending them to a costlier model. The summarization call's own cost is small compared to the savings once the document is reused.
• Only summarize documents that will be referenced more than once. A single-use document rarely earns back the cost of the extra summarization call.
• Pass a focus instruction to the summarizer when you know what the downstream task needs. A generic summary risks dropping the one detail that mattered.
• Cache summaries by document identity, and invalidate the cache when the source changes. Re-summarizing an unchanged document on every call throws away the entire cost benefit.
• Avoid summarizing precision-critical text, such as contracts or exact figures. Summarization is lossy by nature; extract the exact relevant section instead when precision matters.

C - Match Model Tier to Task

• Route each task category to the cheapest model that still meets your quality bar. Reserve stronger models like Opus 4.8 for tasks that genuinely need deeper reasoning.
• Base tiering decisions on an evaluation set, not intuition. A model-tiering checklist narrows the search, but only measured pass rate confirms the choice.
• Let financial, compliance, or reversibility risk override a task's apparent simplicity. A task that looks easy by reasoning-step count can still warrant a stronger tier if a wrong answer is costly.
• Revisit tiering decisions when the task's inputs or a new model in the lineup change the picture. A tier decision made once at launch can go stale.
• Document which tier handles which task category, and why. Undocumented, ad hoc tiering is hard for a team to maintain or revisit.

D - Tune Reasoning Effort Deliberately

• Sweep the effort parameter from low to max against a real evaluation set, rather than defaulting to max. The cheapest setting that still passes your quality bar is the one to ship.
• Set the quality threshold based on the cost of a wrong answer for that specific task. A low-stakes task can tolerate a looser bar than a billing or compliance-adjacent one.
• Grow the evaluation set from real production failures over time. A handful of hand-picked cases will overfit to what you happened to think of when you wrote them.
• Treat effort and context size as independent levers. Raising effort doesn't fix a prompt missing needed context, and trimming context doesn't substitute for effort on a genuinely hard reasoning task.
• Re-run the effort sweep when the prompt template or model version changes. A sweep result is a snapshot, not a permanent fact about the task.

E - Manage Multi-Turn Agent Context

• Cache tool results and dedupe identical repeated calls within a session. A redundant tool call costs twice: once to execute, and again as it's carried forward in every future turn's history.
• Never cache mutating tool calls, only read-only lookups. Re-executing a write, such as charging a card, is the point, not a redundancy to eliminate.
• Set an explicit context window budget for long-running agents, not an implicit one. A budget that isn't documented tends to be discovered only after a session hits a hard limit.
• Define a concrete compaction trigger and what it preserves. Know exactly what condition fires summarization or truncation, and what must survive it, such as the original user goal.
• Scope tool-result caches by session, not globally, in multi-tenant systems. A shared, unscoped cache can leak one user's results into another user's context.

F - Guard Against Context Rot

• Treat "should I include this" as a real question, not a default yes. Irrelevant material can degrade answer quality, not just add cost.
• Watch for distractor content: irrelevant material that superficially resembles the right answer. A same-named variable or a stale duplicate definition can actively mislead a model rather than simply being ignored.
• Don't treat a larger context window as permission to skip trimming. A bigger window changes what fits, not what's relevant.
• Compare answer quality on a trimmed prompt versus a padded one when in doubt. If quality doesn't measurably drop with a smaller prompt, the extra material wasn't earning its cost.
• Balance against over-trimming. Cutting something genuinely relevant produces a different failure than context rot; the goal is relevance, not minimalism for its own sake.

G - Document and Revisit Decisions

• Write down context budgets, compaction triggers, and tiering decisions as they're made, not after the fact. An ADR-style record makes these decisions reviewable instead of tribal knowledge.
• Name an owner for each cost/quality decision. A decision with no owner tends to go stale as the underlying task or model lineup changes.
• Set a review cadence, not a one-time decision. Quarterly review is a reasonable default for high-volume task categories.
• Track a concrete metric that would signal the current settings are wrong. Compaction firing too often, pass rate dropping, or cost exceeding target are all signals worth alerting on.

FAQs

Related

• How Context Engineering Reduces Token Spend - the mental model underlying every practice on this page.
• Model Tiering Checklist - a deeper walkthrough of category C.
• Context Rot: Why More Tokens Doesn't Mean Better Answers - the reasoning behind category F.
• ADR Template: Setting a Context Window Budget for a Production Agent - a template for documenting the decisions in category G.
• Avoiding Redundant Tool Calls in Multi-Turn Agent Loops - a deeper walkthrough of category E.

Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5 - and the official anthropic Python SDK (latest 0.x release). Model names, pricing, and SDK versions move quickly - verify current specifics at platform.claude.com/docs before relying on them.