11.3 The "context budget" technique

Overview and links for this section of the guide.

The core idea: allocate context intentionally

Context is limited. When you exceed it, things get dropped. When you nearly exceed it, quality often degrades.

The “context budget” technique treats context as a budget you allocate across:

  • spec/constraints,
  • acceptance criteria (tests/examples),
  • evidence (errors/logs),
  • code,
  • buffer for output.
Budgeting prevents “paste everything”

Most context problems come from dumping too much text. Budgeting forces you to choose what matters.

A simple budget that works

A practical allocation (adjust as needed):

  • 15%: spec + constraints
  • 15%: acceptance criteria + examples
  • 10%: errors/logs/evidence
  • 45%: code (relevant slices only)
  • 15%: buffer for the model’s response

The key is the buffer: if you fill 100% with input, you force truncation and get incomplete outputs.

How to apply the budget (step-by-step)

  1. Write a spec block and keep it short.
  2. Choose acceptance criteria (3–10 items), not a novel.
  3. Paste only relevant evidence (error excerpt, failing test output).
  4. Paste only the code slice needed for the change.
  5. Summarize everything else (file map + state summary).

If you feel forced to paste too much code, that’s a signal to split the task (small modules pattern) or focus on one step.

Split tasks to fit the budget

If the change can’t fit into your context budget, it’s too big for one iteration. Break it into steps with ship points.

Tradeoffs: what to cut first

When you need to cut, cut in this order:

  1. old chat history (replace with a summary),
  2. unrelated files,
  3. long logs (keep the relevant excerpt),
  4. secondary code paths,
  5. only then cut spec and acceptance criteria (last resort).

Spec and acceptance criteria are often the most important text you provide.

Copy-paste templates

Template: context budget header

Context budget:
- Spec/constraints: short and explicit
- Acceptance criteria: 5–10 bullets
- Evidence: minimal failing output
- Code: only relevant files/functions
- Buffer: keep room for a full diff + explanation

Template: “slice request” to reduce scope

This is too much to do in one step.
Pick the smallest slice that is both:
- testable (has a clear pass/fail), and
- useful (moves the project forward).

Propose a plan with that slice as step 1 only.

Where to go next