Deep dive · developersRevised October 2026

Cost & Context.

Measure a whole task. Keep the information that helps it finish.

David Budáč

In practice

Make one change you can measure

Cost

Separate billing categories and choose a suitable access route.

Context

Trim repeated instructions without losing behavior.

Exercise

Compare correctness as well as tokens.

Use the invoice task throughout. No paid live run is required.

In practice

Start with how the work will run

Need	Check before choosing
Daily interactive work	Native client, plan limits and actual monthly usage.
Custom service, batch or CI	Supported API authentication, rate limits and a budget.
Organizational controls	Identity, data handling, audit, residency and procurement requirements.

Compare current offers against these requirements. Detailed shopping questions are in reference material.

Count the work

Count each billing category separately

Category	What to record
Uncached input	New input processed at its applicable input rate.
Cache writes and reads	Separate token counts and the configured cache rates.
Generated output	Output usage, including billable reasoning where applicable.

Bill = sum of each category’s tokens × its rate, plus any separate tool or service fees.

In practice

High input volume does not identify the largest cost

Generated output may use a higher token rate than input.
Cached input may be much cheaper than newly processed input.
Reasoning, retries, cache writes and tool fees can change the balance.

Use the usage record and elapsed time; a shorter visible answer alone does not prove less computation.

Worked arithmetic

One cache-hit request: about five cents

Illustrative usage and rates	Cost
19,000 cached input × $0.20 / million	$0.0038
3,700 new input × $4 / million	$0.0148
1,600 output × $20 / million	$0.0320
22,700 input + 1,600 output in total	$0.0506

Assumed rates, not a measured bill. Without the cache hit: $0.0908 input + $0.0320 output = $0.1228.

Context quality

Keep the facts that the next decision needs

Keep

The invoice rule, failing case, relevant code, decisions and latest test result.

Summarize or remove

Duplicate file dumps, stale logs and abandoned approaches, once their useful findings are captured.

Watch for missed requirements and repeated work. There is no universal “dumb zone” or safe fill percentage.

Context reference

Inspect what actually enters a request

Standing instructions and applicable project rules.
Tool definitions and relevant skill content.
Retained conversation, selected files and tool results.
The current user message.

Use a request inspector or provider token counters for real sizes. Avoid summing overlapping categories.

Make it repeatable

Store the rules needed on most tasks

# Project instructions — illustrative invoice repository - Test with: pytest tests/test_invoice.py -q - VAT rates come from the order record. - Preserve existing assertions; explain test changes. - Ask before changing the stored invoice schema.

Use the instruction-file convention your harness actually loads. Keep standing rules short and specific.

In practice

Shorten the file while preserving its constraints

Before

Long project history, duplicate style advice, VAT rules, test commands and an old incident log.

After

Keep VAT source, rounding rule, test command and schema boundary. Link occasional procedures from a skill.

The acceptance check is unchanged behavior on the same tasks, not the smallest file.

In practice

Choose from the state of the task

Unrelated next task

Start fresh with its own scope and needed project context.

Same task, long history

Summarize the goal, evidence, decisions, failed attempts and next check.

Check what survives compaction. Neither a fresh session nor a summary has zero context cost.

Split the work · subagents

Delegate a question; ask for evidence back

Fresh helpers need a self-contained task and relevant inputs. Forks can inherit existing history.
Keep intermediate investigation in the helper’s context; return findings with file references.
Review the result. Delegation adds coordination cost and does not itself isolate filesystem access.

Example return: VAT calculation locations, the failing path, supporting lines and unresolved questions.

In practice

Find the relevant span, then enough surrounding context

Search for the invoice entry point and failing test.
Read the function, its callers and relevant rules before editing.
Delegate broad investigation only when the returned evidence justifies the overhead.

A repeated read can be useful after a file changes. Diagnose before calling it waste.

In practice

Exercise · compare two versions fairly

10 minutes A: the long instruction file. B: the shorter version. Use identical task inputs, repo state, model and tools. Record: acceptance results, all usage, time and retries. Repeat runs if available; inspect failures before choosing.

Output: a comparison worksheet and one justified decision. A smaller prompt that drops the VAT rule loses.

In practice

No runtime? Check the proposed rewrite on paper

Requirement	A	B
VAT from order + rounding rule	present	verify preserved
Exact invoice test command	present	verify preserved
Schema change approval	present	verify preserved
Measured task usage and results	not run	not run

Discuss what B removed and which regression case would expose a lost rule. No savings are claimed.

In practice

Measure, trim, then verify again

Record a baseline task outcome and full usage.
Remove one stale or repetitive instruction group.
Repeat the acceptance cases and keep the change only if the tradeoff holds.

Keep the task evidence with the instruction change.

Optional reference material

Sources

Sources and further reading

Primary documentation checked 3 October 2026. Examples are illustrative unless explicitly attributed.