HN on context engineering: nobody agrees when to reset, everyone agrees what to keep

Drew Breunig's "The State of Context Engineering" drew 40 comments on Hacker News this weekend, and the thread could not agree on the one number everyone wanted: how full a coding agent's context can get before it degrades. Reported reset points ran from about 128,000 tokens to 800,000. Where the thread did agree was on what to do at a reset, and that agreement is the useful part. The people who coped wrote things down outside the context. Our view: the first thing to write down is the evidence that the work was checked, because it is the first thing compaction throws away.

The post

Breunig's post argues that long context did not solve context problems: "Long contexts let you fit in more information, but they also let you fit in more errors." He resets at 200,000 to 300,000 tokens, lists six tactics (augmentation, tool loadout, quarantine, pruning, offloading, summarization) and ends on a line several commenters quoted back: the job is choosing "when to be deterministic (what to put in code) and when to be probabilistic (when to let the model drive)".

One sentence in it matters most for anyone verifying agent work: "Early stages of compaction often strip out tool results you no longer need."

What the thread said

We read all 40 comments, 19 of them top-level. Three positions came up repeatedly.

The reset point is personal. Five commenters gave a number, and so did Breunig:

A sixfold spread on one question is not a measurement problem. It says the number depends on the model, the task and the harness, and that a fixed rule will be wrong for most people.

Too little is also a failure. jdw64 pushed back on the "shrink it" reflex: "if there's too little information, it also ends up working in strange ways" (comment). ethanj8011 made the same point from the other side: the model fills 250k "very quickly (presumably mostly by looking through the codebase)", and "without that context I find the models perform badly".

What survives is an artifact. The most practical comments did not argue about size. They described what they keep when the context goes. kadoban has the model "write a handoff file" and clears everything. DenisM checkpoints "into artifacts (code, design, intent)" and resumes with fresh context, noting that the design doc and execution plan "are now outcomes of coding process, not inputs to it" (comment). viccis uses "a lightweight ticket system", where "planning creates very detailed tickets with acceptance criteria" and implementation writes back what future work needs (comment).

antleys tied it to Breunig's closing line, and to a choice they face often: "ask the AI to do a task for me or B) ask the AI to build something that can do the task for me" (comment).

What is missing from the list

Look at what the artifacts hold: the plan, the design, the intent, the acceptance criteria. Not one commenter described keeping the result of checking the work. DenisM comes nearest: a second agent validates the approach, which checks the plan, not the outcome.

That gap is not academic. An agent's evidence that a change works is a tool result: a test run, a page read, a network log. Breunig's own sentence says those are what early compaction strips. So the common sequence is: the agent checks its work, the check scrolls out, the context compacts, and the next turn sees only the agent's summary, "done, verified". The summary survives; the proof does not.

viccis's setup comes closest, because acceptance criteria written on a ticket are a test the next session can re-run. The missing half is writing the outcome back next to the criteria: what was run, what it returned, against which commit.

The takeaway

Put the check in Breunig's deterministic column. Acceptance criteria are already being written down; make each one something a script can re-run without a model, and store its last result as an artifact, not as a line in the agent's memory. Then a reset costs nothing on the question that matters most. Instead of trusting a summary that says "verified", the next session re-runs the check and reads the answer.

The thread will keep arguing about 200k versus 800k, and it should, because the answer moves with every model. Whether the work was checked should not depend on how much of the context survived.