Chapter 6: Context Economy¶

Where the Money Actually Goes¶

1. Two Budgets, One Decision¶

The monthly bill doubled and nothing in the product had changed. The AI model was the same model, the price was the same price, and the team had shipped fewer changes than the month before. What had changed was the Law: a status table had been added to it, because it was convenient to have the table where everyone already looked. Every session loaded it. Every run paid for it. Nobody had ever decided to buy it.

That is the shape of the problem. The three structures cost money to operate — every rule, every file, every retrieved unit is tokens — and the bill is decided by the input side, not by the price list.

There are two sides to that budget, and they are often confused.

The input side is yours: what may enter the prompt, how large the always-loaded set is, how much a task retrieves. The routing chapter decides what may enter; this one prices it, bounds it, and records it. The market side is not: what the model charges per token, and how that changes. Designing against the second is a race you lose; designing the first is a decision that holds.

flowchart LR
  A["task"] --> R["routing units<br/>the input decision"]
  R --> C["context sent"]
  C --> P["price per token<br/>the market side"]
  R --> RW["rework and retries<br/>the measured cost"]
  RW -.->|"usually larger"| P

What this shows: the two budgets — one you design, one you observe — and where the money actually leaves.

💰 Cost Check: the bill is not dominated by the price of a token; it is dominated by how many tokens a run sends and how many runs it takes. A routing decision that halves a context, and a gate that halves the retries, do more for the monthly number than any model choice — and neither one requires renegotiating anything.

🎯 What You'll Learn¶

What may enter the prompt, and why that is a design decision
How to size context by task scope rather than by repository size
Where agent cost actually goes — and it is not the per-token price

Where the Money Actually Goes¶

Claimed cost driver	The measured driver
the per-token price	oversized context on every run
the model tier	rework: the same task done three times
the tool	retries: a failed step re-run from the top
—	a bloated Law loaded into every session

The per-token price is the only line everyone discusses and the smallest lever anyone controls. The large levers are oversized context, rework and retries — all three of which the earlier chapters in this part reduce.

✅ What to Check¶

Take one task. What did it load, and how much of it was used?
Count the retries in the last week. That number is a cost driver, and it is a routing or gate problem.

2. The Always-Loaded Set¶

The routing chapter sizes the context per task: a single-file edit, a feature change, a cross-cutting change, each with its own load unit. That is the variable side of the bill.

The always-loaded set is the one to guard. The Law is loaded into every session, so every sentence costs on every run. Bloating the Law with a view — a dashboard description, a status table — is the classic mistake: it is paid for continuously and read once.

Model tiering is for reasoning difficulty, not context volume. Escalating to a larger model to "fit more context" is the expensive way to avoid the routing decision; the routing decision is free by comparison.

The Budget Rules¶

# budget rules — stated once, checked per task type
always_loaded: { max_lines: <n>, may_include: [rules, map-pointer] }
per_task:      { unit_budget: <n files>, escalation: only-for-reasoning }
tiering:       { default: <tier>, escalate_when: <reasoning difficulty> }

✅ What to Check¶

How many lines is your always-loaded set, and is any of it a view?
Has any task been escalated to a bigger model because the context did not fit? That is a routing gap.

3. Compaction, Summary, Cache¶

Compaction shortens a session's history so the work can continue. It is a mechanism: adopt it, and never treat its output as the record — the record is the log.
Summarisation replaces detail with a summary. Useful for resumption, dangerous for audit: a summary of a decision is not the decision.
Caching reuses what was already computed. It reduces cost and can hide staleness — a cached read is a read you did not make.

The rule: a mechanism that reduces context must never reduce evidence — the continuity chapter's rule, applied to a cost decision. If compaction drops the gate results, the resumed session cannot know what passed.

✅ What to Check¶

After a compaction, can the session still name the gates that ran?
Does any cached value have a freshness rule?

4. Recording Spend¶

Cost is a signal, and a signal needs a record. The execution log carries it: task, tokens or cost, retries, and the model tier. That makes three questions answerable from the repository:

which task types cost most — a routing or sizing problem;
which runs retried — a gate or procedure problem;
which sessions were over budget — a context-economy problem.

Three tasks, as the record holds them:

task                 tier      tokens   retries   wall
change a migration   standard  41,200   0         6m
add an endpoint      standard  38,900   2         24m
rotate a credential  standard   9,400   0         2m

Read across, and the three questions answer themselves. Which task type costs most? The migration and the endpoint, at four times the credential task. Which run retried? The endpoint, twice — a procedure or gate problem, not a context one. Which session went over budget? The endpoint again, at more than twice its unit's median, which is a sizing problem.

That is where the two budgets meet: a routing decision moves the token column, and a gate moves the retry column. Read together, they turn cost from a bill into a signal — and each signal points at a different chapter's fix.

A per-tool dashboard is a view. Adopt it if it helps, but the log is the record; a dashboard that cannot be reconstructed from the log is a second truth that disappears with the tool.

✅ What to Check¶

Can you answer "what did last month cost, by task type?" from the repository alone?
If that per-tool dashboard were removed, would you still know which runs retried?

5. Build the Budget¶

Artefacts¶

Artefact	What it is for	Where it lives
budget rules	always-loaded cap, per-task unit budget	the Law
tiering policy	when a bigger model is justified	the Law, beside the routing table
spend record	task · cost · retries · tier	the execution log
cost review	the monthly read of the record	the Playbook

Decisions¶

Choice	Default	What changes if you choose otherwise
what may enter the prompt	the routing units, nothing else	convenience loading, paid on every run
always-loaded contents	rules and a Map pointer only	a view in the Law, paid forever
when to escalate the model	reasoning difficulty	context volume, which routing should fix
the cost record	in the log, per task	a dashboard that cannot be reconstructed

✅ Checks¶

The always-loaded set is under its cap, and contains no view.
A run over its unit budget is reported, not silently paid.
Cost per task is answerable from the log alone.

Sequence¶

Measure the always-loaded set. Checkpoint: it is a number, and it contains no view.
Write the budget rules and apply them to one task type. Checkpoint: a run over budget is visible.
Write the tiering policy. Checkpoint: escalation names a reasoning reason, not a volume one.
Record spend in the log and read it once. Checkpoint: three questions answered from the record.

Done When¶

The always-loaded set is small, rule-only and capped.
Over-budget runs are reported, not absorbed.
Cost, retries and tier are answerable from the log, without a vendor dashboard.

6. 🔑 Chapter Summary¶

Context is the one budget you design; the price is not.

Two sides — the input side is a decision, the market side is not.
The real cost is oversized context, rework and retries, not the per-token price.
Guard the always-loaded set: the Law is paid for on every run, so it stays rule-only and capped.
Tier for reasoning difficulty, not volume — volume is a routing problem.
Record spend in the log so cost is reviewable without the vendor's dashboard.