How Context Engineering Reduces Token Spend

Context engineering is the discipline of deciding what actually goes into a prompt before it reaches Claude.

It sits upstream of prompt wording and model selection, and it is often the single largest lever a team has over API cost.

A team that writes a great prompt but pastes in an entire repository has already lost most of the savings available to it.

This page builds the mental model behind three techniques that recur throughout this section: minimal-context prompting, summarization, and model tiering.

Each of these reduces token spend, and each does so through a different mechanism, so it is worth understanding them as distinct levers rather than one blurred idea of "being efficient."

Summary

Token spend is a function of what you choose to send Claude, not just how you phrase the request, so trimming, condensing, and routing context are all direct cost controls.
Insight: Input tokens are billed on every call, and large contexts also slow responses and can dilute the model's attention on the parts that matter.
Key Concepts: minimal-context prompting, summarization, model tiering, dependency graph trimming, context window budget.
When to Use: Any production system that sends more than a few hundred tokens of supporting material per call, especially agent loops, RAG pipelines, and code assistants.
Limitations/Trade-offs: Cutting context too aggressively can remove information Claude actually needed, so every technique here trades some risk of under-context for a guaranteed reduction in cost.
Related Topics: dependency graph trimming, pre-call summarization, the effort parameter, context rot.

Foundations

Every request to Claude has a cost that scales with the number of input tokens and output tokens involved.

Input tokens include the system prompt, the conversation history, any retrieved documents, and any tool results injected into context.

Most teams focus first on output length or on choosing a cheaper model, but for many workloads the input side of the ledger is larger and easier to control.

Minimal-context prompting is the practice of sending only the specific snippets a task needs rather than the full source file, the full document, or the full repository it was pulled from.

Summarization is the practice of using a cheap, fast model to compress a long document into a shorter representation before that representation is sent to a more expensive model for the real work.

Model tiering is the practice of routing a request to the cheapest model in a lineup, such as Claude Haiku 4.5, that can still meet a quality bar, and reserving a stronger model like Claude Opus 4.8 for the requests that actually need it.

A simple analogy: think of Claude's context window as a desk.

You can pile the entire filing cabinet on the desk so nothing is ever missing, or you can pull only the folders relevant to the task in front of you.

The second approach costs less to prepare, and it also keeps the desk usable.

# A minimal-context call: only the relevant function, not the whole file
prompt = f"""Review this function for a null-pointer bug.
 
{relevant_function_source}
"""

Mechanics & Interactions

These three techniques act at different points in a request's lifecycle, and understanding where each one sits clarifies when to reach for it.

Minimal-context prompting acts at assembly time: before you build the prompt string, you decide which snippets, rows, or paragraphs are relevant and exclude the rest.

This is usually the highest-leverage technique because it removes tokens entirely rather than compressing them, so there is no secondary API call and no compression cost.

The trade-off is that it requires some upfront work to know what is relevant, whether that is a search step, a dependency graph, or a retrieval index.

Summarization acts at pre-processing time: a long document exists, it is too large or too unfocused to send whole, and a cheaper model reduces it before the expensive model ever sees it.

This adds one extra API call, but that call uses a cheap model, so the net cost is still lower than sending the full document to the expensive model.

Summarization is most valuable when the same long document will be referenced across many calls, because the summarization cost is paid once and the savings compound.

Model tiering acts at routing time: for each incoming request, a decision is made about which model in the lineup should handle it.

def choose_model(task_complexity: str) -> str:
    if task_complexity == "simple_lookup":
        return "claude-haiku-4-5"
    if task_complexity == "standard_reasoning":
        return "claude-sonnet-5"
    return "claude-opus-4-8"  # multi-step reasoning, high-stakes output

The three techniques compose well together.

A pipeline might use minimal-context prompting to select relevant files, summarization to condense any file that is still too long, and model tiering to decide whether the final call needs Sonnet 5 or can run on Haiku 4.5.

None of them requires the others, but stacking them produces multiplicative, not additive, savings, because each technique reduces a different dimension of spend.

Advanced Considerations & Applications

At scale, these techniques stop being isolated tricks and start becoming policy decisions that a team documents and revisits.

A context window budget, for example, sets a hard ceiling on how much context an agent is allowed to accumulate before something has to give, whether that is summarization, truncation, or ending the session.

Model tiering decisions benefit from an explicit checklist rather than ad hoc judgment calls, because "does this task need Opus" is a question that different engineers will answer inconsistently without shared criteria.

Minimal-context prompting for code tasks scales further with dependency graphs: instead of hand-picking snippets, a graph of imports and call sites tells you exactly which files are structurally relevant to a change, which scales to large codebases in a way manual selection does not.

It is worth being honest that all three techniques can be pushed too far.

Removing too much context, over-compressing a document, or routing a genuinely hard task to a cheap model all produce a cost saving that is paid for in wrong answers, and a wrong answer that has to be re-run is more expensive than the tokens it saved.

Technique	Strength	Weakness	Best Fit
Minimal-context prompting	Removes tokens entirely, no extra call	Requires knowing what's relevant	Code review, targeted Q&A, RAG
Summarization	Compresses reusable long documents	Adds a call, can lose nuance	Long docs referenced repeatedly
Model tiering	Matches cost to task difficulty	Wrong tier degrades quality	High-volume, mixed-difficulty workloads

The common thread across all three is that they are decisions made before the expensive model call, not after.

Optimizing a prompt's wording after the context is already bloated recovers far less cost than deciding what belongs in the prompt in the first place.

Common Misconceptions

"A bigger context window means I don't need to trim context." A larger window changes what you can send, not what you should send; unnecessary context still costs tokens and can still degrade answer quality.
"Summarization always saves money." It only saves money when the summarized document is reused across multiple calls or is large enough that the summarization call's own cost is small by comparison.
"Model tiering means always using the cheapest model." Tiering means matching cost to difficulty; routing a genuinely hard task to a cheap model produces wrong answers and re-runs, which cost more than the tokens saved.
"Context engineering is just prompt engineering with a new name." Prompt engineering optimizes wording and structure; context engineering decides what information enters the prompt in the first place, which is a separate, earlier decision.
"Trimming context is risky, so it's safer to send everything." Sending everything has its own risk: context rot, where irrelevant material degrades the model's focus on what matters, in addition to the guaranteed extra cost.

FAQs

What is context engineering, in one sentence?

Context engineering is deciding what information to include in a prompt, as opposed to how to word it or which model should receive it.

Is context engineering the same thing as prompt engineering?

No.

Prompt engineering shapes wording, instructions, and structure.
Context engineering shapes what material (snippets, documents, history) is included at all.
The two are complementary and usually applied together.

Which of the three techniques should I implement first?

Minimal-context prompting is usually the highest-leverage starting point because it removes tokens outright with no added API call, whereas summarization and tiering both require some infrastructure to set up.

Does sending more context ever hurt answer quality, not just cost?

Yes.

Irrelevant or excessive context can dilute the model's attention on the details that actually matter.
This effect is sometimes called context rot, and it means trimming context is a quality lever, not only a cost lever.

How does summarization actually save money if it requires an extra API call?

The summarization call uses a cheap, fast model, while the original document would otherwise be sent in full to a costlier model on every use; when a document is referenced many times, the one-time cheap summarization cost is far smaller than the repeated cost of sending the full document.

What is model tiering in practice?

Model tiering routes each request to the cheapest model in the Claude lineup, such as Haiku 4.5, that can still meet the required quality bar, reserving stronger models like Sonnet 5 or Opus 4.8 for tasks that genuinely need deeper reasoning.

Can these techniques be combined?

Yes, and combining them is typical in production systems.

Minimal-context prompting narrows what's sent.
Summarization compresses anything still too long.
Model tiering decides which model handles the resulting request.

What is a dependency graph and why does it relate to context engineering?

A dependency graph maps which files or modules a piece of code imports or calls; sending that graph plus only the relevant snippets keeps a code-related prompt focused, instead of pasting an entire repository.

Is there a risk of trimming context too aggressively?

Yes.

If relevant information is excluded, the model may produce a wrong or incomplete answer.
A wrong answer that must be corrected or re-run typically costs more than the tokens that were saved by trimming.

How does the effort parameter relate to context engineering?

The effort parameter controls how much reasoning the model applies to a given prompt; it is a separate lever from context size, but both are swept and evaluated the same way, from a cheap setting up to the strongest one that still passes quality checks.

Does context engineering apply outside of code-related tasks?

Yes.

Minimal-context prompting applies to any retrieved document, support ticket, or database row, not just source code.
Summarization applies to any long text: transcripts, reports, legal documents.
Model tiering applies to any classification of task difficulty, regardless of domain.

What is the biggest mistake teams make when trying to reduce token spend?

Optimizing prompt wording before addressing what's included in the prompt at all; wording changes save a small percentage, while context decisions often account for the majority of spend.

How do I know if my system needs context engineering at all?

If your prompts regularly include full files, full documents, or full conversation histories rather than the specific parts relevant to the current request, there is very likely room to reduce spend without touching model choice.

Prompt and Context Engineering Basics - a hands-on walkthrough of trimming a bloated prompt and measuring the savings.
Trimming Context: Dependency Graphs Instead of Full Repos - applies minimal-context prompting to code tasks specifically.
Summarization Before the Call - a deeper look at pre-condensing long documents with a cheap model.
Model Tiering Checklist - concrete criteria for choosing between Haiku, Sonnet, and Opus.
Context Rot: Why More Tokens Doesn't Mean Better Answers - the quality-side argument for the same discipline covered here.

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.

It sits upstream of prompt wording and model selection, and it is often the single largest lever a team has over API cost.

A team that writes a great prompt but pastes in an entire repository has already lost most of the savings available to it.

This page builds the mental model behind three techniques that recur throughout this section: minimal-context prompting, summarization, and model tiering.

Each of these reduces token spend, and each does so through a different mechanism, so it is worth understanding them as distinct levers rather than one blurred idea of "being efficient."

Summary

Token spend is a function of what you choose to send Claude, not just how you phrase the request, so trimming, condensing, and routing context are all direct cost controls.
Insight: Input tokens are billed on every call, and large contexts also slow responses and can dilute the model's attention on the parts that matter.
Key Concepts: minimal-context prompting, summarization, model tiering, dependency graph trimming, context window budget.
When to Use: Any production system that sends more than a few hundred tokens of supporting material per call, especially agent loops, RAG pipelines, and code assistants.
Limitations/Trade-offs: Cutting context too aggressively can remove information Claude actually needed, so every technique here trades some risk of under-context for a guaranteed reduction in cost.
Related Topics: dependency graph trimming, pre-call summarization, the effort parameter, context rot.

Foundations

Every request to Claude has a cost that scales with the number of input tokens and output tokens involved.

Input tokens include the system prompt, the conversation history, any retrieved documents, and any tool results injected into context.

Most teams focus first on output length or on choosing a cheaper model, but for many workloads the input side of the ledger is larger and easier to control.

Minimal-context prompting is the practice of sending only the specific snippets a task needs rather than the full source file, the full document, or the full repository it was pulled from.

A simple analogy: think of Claude's context window as a desk.

You can pile the entire filing cabinet on the desk so nothing is ever missing, or you can pull only the folders relevant to the task in front of you.

The second approach costs less to prepare, and it also keeps the desk usable.

# A minimal-context call: only the relevant function, not the whole file
prompt = f"""Review this function for a null-pointer bug.
 
{relevant_function_source}
"""