context-tax-audit · git:20261029.49a3ff4 · 2026-10-29 · sha256 afd253b0ba4b1328

context-tax-audit git:20261029.49a3ff4A

Immutable. This exact content never changes and is served at /api/v1/blob/afd253b0ba4b1328.

---
name: context-tax-audit
description: Inventory everything an agent injects into each request besides the user's message, such as system prompt, environment info, skill list, tool definitions, per-turn context blocks and reminders, and check necessity, frequency, precision, position and prompt-cache impact. Use when reviewing an agent's prompt assembly, chasing low cache hit rates, or trimming per-turn overhead.
---

# Context Tax Audit

Every request carries more than the user's sentence: system prompt,
environment info, the skill list, tool definitions, per-turn context blocks,
reminders. Most of it is worth paying for. The audit finds what is not, and
what is placed so that it breaks the prompt cache.

Companion to MCode Engineering Notes 05 (how the agent learns the
current time — and why stuffing `date` into the system prompt breaks the
prefix cache).
Plain-text checklist: `checklists/context-tax.md`.

## 1. Inventory one real request

Capture an actual request the agent sends (debug log, proxy, or the code that
assembles it). List every part except the user's message:

| Part | Where it sits | How often it changes | Tokens |
| --- | --- | --- | --- |

Count tokens with a tokenizer and name it; treat the counts as relative.
Do a fresh-session first request and a later turn, since they often differ.

## 2. Necessity - what breaks if you delete it?

For each part, write one sentence: "without this, the model would ...".
Typical answers: without environment info it guesses the OS and shell; without
the current time it assumes its training year; without a time budget it does
not wrap up before a deadline. If you cannot write the sentence, the part is a
candidate for removal.

## 3. Prompt-cache placement

Caches match on prefix. One changed byte invalidates everything after it.

1. Content that is **at the front and changes every request** is the most
   expensive. Move it later.
2. Content **written into history and never edited** costs once and then stays
   cacheable.
3. Content **attached only to the current request** is never cached and is
   paid at full price every time. Control its frequency.

Rules of thumb:

- Stable first, volatile last. Keep `# Environment` free of current time; put
  time in per-turn `<agent-context>` (or the equivalent user-message block).
- Never rewrite reminders already in history; change only future turns.
- Use only the precision you need. A timestamp to the second guarantees every
  copy differs once placement is already right.
- Request-only reminders never enter the cache — control how often they fire,
  but do not confuse that thrift with protecting the prefix.
## 4. Run the checklist

| Item | Question |
| --- | --- |
| Prefix awareness | Can you point to the stable prefix vs what changes every turn? |
| Necessity | For each part, where does the model go wrong without it? |
| Position | Is anything volatile inside the system prompt or tool definitions? (e.g. time in `# Environment`) |
| Frequency | Does a changing field need every turn / request, or only at the start, key points, or on change? |
| Precision | Does it need seconds, exact counts? Higher precision means more turn-to-turn variation. |
| History | Are reminders already in history ever rewritten later? |
| Recovery paths | If you remove something, does it vanish entirely on compaction, session resume or subagents? Who restores it? |
| Measurement | Before and after a change, do you look at cache hit rate, cost per turn and task quality, not just token count? |

## Output

The inventory table, a list of parts to cut, move, reduce in frequency or
reduce in precision (each with the reason), and what to measure to confirm
the change helped.