I would not try to fill 64K. The window is capacity, not a target. First ask what decision the model has to make next. Is it locating the bug, choosing an edit, interpreting a failed test, or checking whether the task is done? The evidence for those decisions is different.

Suppose the current step is to fix a parser regression. The next call probably needs the user's actual request and constraints, current repository revision and changed files, the exact failing assertion and command that produced it, the parser function, nearby tests, and a compact statement of what has already been tried. It does not need every issue comment, three entire package trees, and the full output of a passing test suite.

I would build the context from three sources with different authority. Durable task state holds the goal, current constraints, plan, changed files, verified effects, and unresolved work. The repository and tools hold current code and observed results. Summaries of earlier discussion help the agent navigate, but they are not the authority for what the code currently says or whether a tool call succeeded. If a summary says “tests pass” and the last test run is from before the latest edit, the claim is stale.

The assembly step can use a budget, but not a fixed percentage recipe. Reserve room for the model's response, expected tool output, and any reasoning tokens the chosen model consumes. Keep policy and active user constraints intact. Then include high-value evidence in its original form where losing one token can change the decision: the failing assertion, relevant code branch, error message, and exact API name. Compress repetitive stack frames, long build logs, and old exploratory branches. Store file paths and commit hashes so the agent can read more on demand.

I would explicitly label each item: source, path, revision, tool invocation, timestamp, and whether it is an observation, user instruction, or hypothesis. That prevents a note like “probably caused by Unicode normalization” from becoming a verified fact on the next context reset. A tool result is data. A command inside a README or an issue comment is not an instruction to the agent. The runtime has to keep those trust boundaries even when the text looks useful.

Relevance is not only embedding similarity. Code dependencies matter. If the parser calls a shared decoder, include the call site and the decoder's contract. If the failing test depends on a fixture, include the fixture. Use repository search, symbols, imports, and the current diff to find the needed slice. Anthropic's context engineering article describes keeping lightweight references and loading detail when needed. That is a useful pattern here: preserve the handle to the file, not its entire contents in every turn.

Now the test failure changes the plan. I would persist the new observation with its command, environment, and revision, mark the earlier hypothesis as unconfirmed or disproved, and rebuild context around the failure. The agent might need the exact test and one neighboring code path more than it needs the old implementation plan. If the error comes from a dependency that was not previously in context, fetch it. Do not keep the previous plan at the top and append the new failure after tens of thousands of old tokens. That makes the system behave as if the test is an afterthought.

The interviewer asks, “What if that test is flaky?” One failure is evidence, not proof of a code defect. Rerun under the same revision, inspect history and logs, compare a control branch, and note the uncertainty. The context should keep the failure as an observation and the flakiness hypothesis as a hypothesis. A summary that says “test is flaky” without that evidence can hide a real regression.

I would measure context quality by task outcome and by the first stage of failure. Did the needed file enter the prompt? Was the text current? Did the agent use it? Did it hallucinate a completed test? Did it make an unnecessary tool call because the relevant result was buried? Run ablations: full history versus selected context, current code versus stale summaries, and different amounts of test output. Compare patch correctness, unsafe changes, latency, and tokens, with the same repository snapshot. More tokens are only useful when they help the next decision.

The 64K figure has another trap. The exact token accounting and reserved output space vary by model and API. OpenAI's conversation state documentation notes that the context limit includes input, output, and reasoning tokens. I would test the actual model path rather than assume 64K of source files can be sent safely. The principle stays the same: keep constraints and verified state stable, load task evidence just in time, and let a new observation change what the next call sees.