Context as a Limited Resource

How an AI coding agent actually works treated an AI coding agent (a software-development agent built on artificial intelligence, or AI) as a system made of a model, an application, tools and an execution environment. This unit focuses on what the system actually passes to the model for its next step. That is the context: not, by definition, the whole repository or the whole history, but a selected set of instructions, messages, tool results and data available to the model right now.

Context is limited not only by how much data can technically be supplied. If you add everything to a request, an important rule can get lost among repetitions, outdated decisions and large outputs. You need to manage both capacity and relevance: pass enough information to complete the current step, keep exact sources for decisions, and never credit the model with knowledge of something it was not given.

The product claims below were checked against official Anthropic and OpenAI pages on 23–26 September 2026. Vendor documentation may change; where a page shows no release date or version number, the sources say so. In the examples, all file names, rule versions, records, commands and states are invented. None of the examples describes a real environment or an actual run.

What "context" means, and where its boundary lies

The context budget is the working space of a single request to the model. It is usually measured in tokens, which are not the same as words, lines of code, files or pages. The context window sets how much tokenised content the model can take into account in a given run. Its exact size and accounting rules depend on the model, the application programming interface (API), the type of data and the product.

A token is a piece of text produced by the model's tokeniser. A token can coincide with a word, a syllable, a punctuation mark or a fragment. Code, non-English text, tables, JSON (JavaScript Object Notation, a text format for structured data), images and documents consume the budget according to the rules of the particular system; you cannot work out the exact number of tokens from a file's size in bytes.

A request has at least two different limits:

• The context budget: how much input, earlier messages and generated continuation the current exchange with the model can hold. For some models this also includes internal reasoning tokens or tool content.
• The response budget: how many tokens the model can generate in one call. It can be smaller than the whole context budget. If it runs out, the response can be cut off even though space remained in the context.

So "a window of N tokens" does not mean all N can be spent on files. Part is taken by system and developer instructions, the available tools, the history and the results of earlier calls; part may need to be kept free for the response or the next step. An API sometimes also has separate limits on request size, images or documents. Cost, latency and context capacity are related, but they are not the same thing.

The exact limits of models and specific products change. This unit deliberately contains no permanent table of numbers and no rule like "never exceed so many words": for an actual run, check the live documentation for the chosen model and API on the same date. The practically important question for each step is not "how much can I fit in at all?" but "what data does the model need to see to answer this question, and how much room does it need for its response?"

What consumes context

Depending on the product and its settings, the current request may contain:

• system, organisational and developer instructions, plus tool names, descriptions and schemas;
• the new user message and earlier messages, if the client passed the history or continued it via a session identifier;
• content read from files, web pages, documents or a database, as well as excerpts returned by search;
• tool results: for example shell output, a file listing, an error message or an API response;
• content generated by the model. For some models and calls, reasoning tokens or the results of tool calls also count towards the budget.

If an agent loop passes the whole history every time, long tool outputs can consume the budget again in every subsequent request. Some products keep part of the state on the server or clear out old results; that does not mean context can be treated as unlimited, or that every client works the same way. For example, OpenAI's documentation describes the context window as the sum of input and output tokens and, for certain models, reasoning tokens; Anthropic's documentation likewise lists the system prompt, messages, tools, images, documents and the generated continuation. These are examples from two APIs, not a universal accounting table for every product.

A file in the working directory is not yet a file that has been read. The model may not see a file until the application or a tool passes it into the request. Even the presence of a name in the file tree proves only that the system was told about the path; conclusions about its contents require the text that was actually read or some other real result. Conversely, the environment may automatically load some instructions or index documents. So what exactly was provided depends on the product and the actions of its harness: check the read log, the interface or whatever other evidence is available.

Calling a read tool does not guarantee that the whole file reached the model either: the tool may have returned only a range of lines, a search excerpt, a truncated result or a summary. For an important requirement, record which version and which part of the source was read. A list of files and a list of what was read are different records.

Why a longer context does not guarantee a better answer

Being technically able to pass a long sequence and being able to use all its parts equally well are different things. The primary study by Nelson Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni and Percy Liang, "Lost in the Middle: How Language Models Use Long Contexts", tested exactly this: how the result depends on where the needed information sits in the input.

The authors studied two tasks:

1. Multi-document question answering. For 2,655 questions from NaturalQuestions-Open, they assembled a Wikipedia passage containing the answer together with distractor documents. Passages were capped at 100 tokens; distractors were chosen with the Contriever retriever. In a controlled comparison they varied the total number of documents (10, 20 or 30) and moved the document containing the answer towards the beginning, the middle or the end, then measured answer accuracy. The model had not only to find the passage but to use it to answer.
2. Synthetic key–value retrieval. The model received a JSON object with random unique pairs and a request for the value of a particular key. The authors varied the length of the object and the position of the target pair. This is a simpler test of retrieving an exact value, not of complex reading of natural text.

The models tested included MPT (Mosaic Pretrained Transformers, a family of pretrained transformers from MosaicML), in particular MPT-30B-Instruct; LongChat-13B with a 16,000-token context; GPT-3.5-Turbo (GPT stands for generative pre-trained transformer) and its extended-context variant; and Claude-1.3 and Claude-1.3 with extended context. These are model names from that period, not recommendations for a choice today. For multi-document question answering, the authors observed a characteristic pattern: results were often better when the document with the answer came at the beginning or the end, and worse when it landed in the middle. For GPT-3.5-Turbo, accuracy at middle positions in some settings with 20 or 30 documents fell below its closed-book performance, that is, answering with no documents at all, which scored 56.1 percent. A larger context by itself gave the extended-context variant no consistent advantage on tasks that fitted in both variants.

In the random key–value task, some models retrieved the value without errors under the tested conditions; others also did worse when the target pair was in the middle. This refines the conclusion: the effect did not boil down to a single general inability to find exact text; the result depended on the model, the task and its difficulty.

A separate experiment with document retrieval for open-domain questions showed that adding more passages did not always bring proportionally more benefit. Under those specific conditions, going from 20 to 50 retrieved documents gave only a marginal improvement: about 1.5 percent for GPT-3.5-Turbo and about 1 percent for Claude-1.3. This is a result for a specific dataset and retrieval method, not an assessment of all retrieval systems.

Limits of the study. These are controlled experiments on defined question sets and 2023 models, published in February 2024 in the journal Transactions of the Association for Computational Linguistics (TACL). The work used greedy decoding, among other choices; the authors explicitly left other decoding methods for future work. Distractor documents, English Wikipedia, scoring by answer match and the precise placement of a single passage do not reproduce every real programming task, newer models, other languages, tools or indexing methods. The result does not prove that every model always has a "dead zone" in the middle, and it does not measure every modern system.

The practical conclusion is narrower: the size of the context window does not, by itself, prove that the model will reliably use every fact passed to it. For an important decision, supply relevant excerpts, ask a precise question, cite the source, and check the answer against it. Do not turn the paper's findings into a universal law about all models.

Context rot and context pollution: useful names, different evidential status

Context rot is a term used for the decline in a model's ability to work accurately with information as the input context grows. Anthropic's engineering material describes it as a tendency that varies in strength between models, not as a single formula or a threshold shared by all systems. Lost in the Middle provides measured results on specific controlled tasks: the position of a fact affected accuracy for the models tested. Those specific results are empirical evidence; the name "context rot" itself is not a separate standard test with a single threshold.

Context pollution is an engineering description of a situation where the active request is filled with unnecessary, outdated, duplicated, misleading or conflicting information. Such data makes it harder to find the authoritative rule and can distract from the task. It is a useful working concept, but not a standardised quantity you can simply measure with a universal number. Not every surplus token will cause an error, and not every error is caused by pollution: the cause may be the model, poor wording, a wrong tool action or a false source.

Do not confuse these concepts with the window simply overflowing. Overflow is when a request does not fit within the technical limits of a particular product. Rot is a drop in quality on a longer context under measured conditions. Pollution is an assessment of what the context contains, meant to help improve it. Large contexts can fit without any noticeable error, while a small but contradictory context can cause a serious one.

Open sources gradually

A useful sequence goes from the map to the exact excerpt, rather than passing in everything you can find at once:

1. Define the specific outcome and criterion. For example: "change the response text for an expired token while keeping the response code and the public contract".
2. Survey the project map. Find out the working directory, the branch, the state of the files, the top-level folders and the existing instructions. Surveying a listing is not yet reading every file.
3. Find the likely locations. Searching by symbol name, error text, route, data type or criterion can surface the source files, call sites, tests and configuration.
4. Read the relevant excerpt with enough surrounding context. Check the declaration, the conditional branches, the call handlers and the test examples; if the excerpt is too small, open the adjacent code.
5. Widen the circle when a dependency appears. If needed, read the API contract, the data schema, a migration, a neighbouring module or the instructions for that folder.
6. Note down what was actually checked. Give the path, the version or revision, and the specific result; do not write "checked the whole repository" if only a few files were read.

This approach is called progressive disclosure: the agent receives a general orientation and then loads the needed details itself or on instruction. Its advantage is not a guaranteed reduction in errors, but the fact that sources can be added to the context according to their relevance to the task, and you can stop once there is a sufficient basis for the next verifiable action.

Search and RAG are ways of selecting, not required equipment

RAG stands for retrieval-augmented generation: the system finds excerpts in an external corpus and adds them to the model's request. It describes a pattern, not a requirement to use any particular store.

Retrieval can be done with ordinary text search in the repository, file navigation, a database query, a documentation search or a dedicated index. A vector database is one possible option for semantic search over vector representations of text. It can help with a large corpus, but it is not a prerequisite for every RAG system and is not needed for every programming task. For a single method in a small project, exact search and reading its call sites may be simpler. A very broad corpus may need indexing, access filters, metadata and index updates.

Search results also need checking. Semantic search may miss an exact identifier; keyword search may miss a synonym; a stale index may point to a previous version; an excerpt without its heading may lose its meaning. For a decision based on a retrieved document, bring back into context the source's name, its date or revision, and enough of the surrounding text around the claim. Search suggests what to read next; it does not automatically establish that the find is the rule currently in force.

The whole repository or targeted files

Reading many or all files is justified when it genuinely matches the question: for example, when the team is running a documented inventory of every place a deprecated API is used and the criterion requires full coverage. The agent then has to define the boundaries of the search, find all possible occurrences, follow indirect dependencies and record how completeness was verified.

Targeted reading is appropriate when the question is narrow and the place to change is known or can be found. First check the instructions and the state of the repository, then read the incoming requirement and the code, its call sites, the relevant tests and contracts. If the search reveals a new connection, widen the scope. If not, there is no reason to bury the model in unrelated files. In both approaches, do not claim a completeness you did not actually verify. This unit establishes no universal ratio between the number of files read and quality.

Summaries, compaction and preserving evidence

When a conversation or a piece of agent work gets long, a product may compact the context: keep a shorter summary of the important information and remove part of the earlier history from the active request. This helps the work continue, but a summary is a transformation, not an exact archive. It can lose the exact wording, a negative example, the origin of a decision, an open question or an important prohibition. Another product may delete selected old results without creating a summary; that is not the same operation.

According to the official documentation, Anthropic's Messages API described server-side compaction, as of the verification date, as a beta feature that creates a summary block and continues the work from it. OpenAI describes server-side and separately invoked compaction in the Responses API; the returned compaction item is opaque and not intended to be read by a human. These are different API implementations; they do not prove that every client product compacts in the same way, or that the user sees every fragment that was lost.

For a summary to stay useful and verifiable, it should carry not just the agent's impressions but structured information:

• the goal and acceptance criteria: what observable completion is required;
• the working revision: the repository, branch or commit, and uncommitted changes that must not be lost;
• the sources of decisions: file names, versions, links or commit identifiers, important excerpts or exact statements with references to them;
• the status of each claim: confirmed fact, hypothesis or unknown; each decision together with its reason and source;
• what was done and verified: changed paths, runs and the results obtained, and what exactly they prove;
• what is open and what is forbidden: unresolved questions, deferred risks, side effects that were not performed and must not be performed without a specific condition;
• the immediate next step: one next task, its inputs and its stopping condition.

If a fact matters for acceptance, security, data or an external commitment, leave a reference in the summary to the primary source or to the state file. A summary should not become a new authoritative rule merely because it is shorter and more convenient. A new session, or the next step after compaction, must re-read the decisive sources and check the current revision before acting.

A summary should not be made as long as possible "just in case". Its purpose is to preserve the state and the routes to evidence, not to copy every message that already exists in files or in the history. Compaction helps manage the active context; it is not a backup, a transaction log, an approval or a guarantee that all instructions are preserved exactly.

Memory, prompt caching and durable state are three different things

The word "memory" can refer to several mechanisms. Before relying on one, find out what exactly is written, who loads it, in which sessions it is available and whether you can check that it is still current.

Mechanism	What it stores	What it does not guarantee on its own
Active context	What the application passed to the model for the current request: instructions, messages and selected content.	Persistence between requests, or the presence of any other file or message.
Product or agent memory	Selected notes, preferences or past experience in a profile, a memory file or a dedicated tool.	That every note is current, loaded for every request, or takes precedence over a new requirement.
Prompt prefix caching	Reused internal model states for an unchanged prefix, so the same beginning does not have to be computed again.	Semantic memory, new knowledge, persistence of the task or higher answer accuracy. Cached tokens usually still count as part of the request's context.
Durable state in a file or service	Facts deliberately saved in a commit, a progress file, version control, a database or another service.	That the model has already read this state, that it is not stale, or that the model's action matches the permission.

Anthropic describes Claude Code's memory as context, not enforced configuration: an instruction file may be loaded, but that is not the same as a technical block on a command. The page on the memory tool for the API shows a different mechanism: the model requests an operation, and the application performs the read or write against a store the developer controls. These are examples of specific products, not a claim that every agent has memory by default.

Caching should not be confused with memory either. OpenAI's documentation explains the prompt cache as stored intermediate states for reusing an identical initial prefix; Anthropic's documentation describes prompt prefix caching with checkpoints. Changing content before the cache point can break reuse or require a new write. It is a speed or cost optimisation for some requests, not a store of facts or an audit log. Do not carry over one vendor's caching details or retention periods to another.

The best place for a durable rule depends on its purpose. A versioned document can be the source of a policy; a commit in version control records the state of the code; a database stores a business fact; configuration or an environment control can physically prevent a dangerous action. A memory note helps restore orientation, but it should point to a source where you can verify that the rule is still in force.

What context to pass for a specific task

A useful starting context is a short working brief, not a transcript of all previous correspondence. It can be built in this order:

1. Goal and outcome. What should change, or what needs to be established?
2. Acceptance criteria. Which visible conditions will show that the result is correct? The difference between a criterion, a test and evidence is covered in test plans before coding.
3. Scope and exclusions. Which parts of the product are in scope, and what must not be changed or run?
4. Authoritative sources and revisions. Which file, document or record governs the decision? On which branch or commit is the work being done?
5. Current state and facts. What has already been done and read, which checks have finished, and with what actual results?
6. Decisions and unknowns. What has already been decided and on what basis, which assumptions remain unverified, and what needs clarification from a person?
7. Next step and limits. What is the next safe action? Which precondition must be met before moving on to a write or an external side effect?
8. Path to the details. Where can the primary files, tests, log or progress record be read if the condensed facts are not enough?

As work proceeds, only the details needed for the next action are added to the brief. If an agent has to change one adapter, it does not need a copy of every earlier research step; it needs the requirement, the adapter's contract, the relevant call sites and the tests. If an agent is checking a shared policy, it needs the source of the policy, its scope, its version and any conflicting evidence.

Do not load the whole history automatically just because it exists. It may contain repeated results, outdated agreements, instructions from another task or tool output that no longer matters. Include a specific old message only when its wording is itself evidence or a requirement; mark its date and origin rather than presenting it as the current rule.

A short brief must not hide uncertainty. "We need to find out whether the exception for old orders still applies; the documents give no answer" is better than a conclusion the summary arrived at without a source. "Not verified" is a useful work status, not a flaw to be disguised.

A separate context for a reviewer or a subagent

Dependency graphs discussed a shared reviewer and the dependency graph, and how an AI coding agent actually works discussed the agent's various boundaries. The context principle that matters here is this: another agent is useful if it receives enough material for its own task, but it does not need to carry the contents of all the implementer's research again.

For a review, pass on:

• the acceptance criteria and the source they come from;
• the relevant diff (a display of the differences between file versions) or the changed revision, the list of files and the exact areas of change;
• the relevant contracts and the architecture or policy decisions that affect the change;
• what was actually checked, what results were obtained and what was not checked;
• specific review questions: for example, missed call sites, behaviour on retry, compatibility with old data, tests that do not match the requirement.

Do not pass on only the author's phrase "it's all done" or their self-check. Let the reviewer read the diff and go to the source. At the same time, do not hide an important exception from them, so that the review does not become deliberately blind. A separate context means it contains none of the author's surplus reasoning; it does not mean it lacks criteria, instructions or evidence.

A reviewer with a cleaner context may notice that the implementer has grown used to a poor construct or accepted an assumption without evidence. But this does not guarantee an independent conclusion. Both agents may inherit the same ambiguous requirement, read the same outdated document, miss the same file or share a similar model bias. If the reviewer received only a condensed retelling, it does not check the facts hidden inside it. The best context for a review leads to primary sources and asks clear questions; it is not an endless history.

For a subagent with a narrow job, pass on a separate goal, the accessible area, the current instructions, the expected report format and the boundary of permitted actions. Ask it to return the sources it used, the exact files or search queries, the facts it found and the unknowns. Before integrating, the coordinator checks the conclusions against the current files and revision itself. A subagent's short report is a search result, not an automatically verified decision.

How to find out why an instruction was skipped

If an agent did not follow an instruction, the diagnosis "it forgot because the context was long" may be nothing more than a guess. First check four questions:

1. Was the instruction loaded? Did the application pass the file or message to the model? Is there a read record, an acknowledgement of instructions in the current session or other evidence? The mere existence of the file in the repository proves nothing. Check whether the instruction was cut off by search, by the product's configuration, by a disabled file or directory, or by a size limit.
2. Was the instruction in force for this action? Compare the date, the branch, the revision, the scope, superseded versions and the sequence of newer messages. An old note may accurately restate a rule that no longer applies.
3. Was the instruction worded clearly? Does it name the object, the action, the condition, the exception and the required result? "Be careful with migrations" does not say whether a command may be run; "do not connect to the database and do not apply this migration without separate permission from the owner" is far more specific.
4. Did it belong to the current scope? The requirement may apply only to a particular directory, environment, stage or role, while the current task is something else. Compare the condition with the actual action, not just with the file name.

After that, consider the next layer: if the correct instruction was passed, in force, clear and relevant to the action, check whether it got lost in contradictory context, whether compaction cut it, whether the agent generated a plan that contradicts it, and whether a tool executed a command despite a textual prohibition. Gather the visible evidence of the request and of the tool execution, if available. Do not draw conclusions about the model's internal mechanism from the final error alone.

The fix depends on where the failure occurred: add the instruction to a place that is guaranteed to be loaded; mark its source and date; rewrite a contradictory brief; narrow the request; keep a reference in the handoff; or move a critical control out of text into a tool permission, a check or an environment procedure. An instruction influences the model's behaviour; a textual order by itself is not a technical block. Claude Code's documentation specifically warns that an instruction file is not enforced configuration, and describes how to check which memory files were loaded into a session. That is a feature of that product's documentation, but the general diagnostic approach is useful for other systems too.

Continue the current conversation, start a new one, or hand the work over

Continue in the same session when the next step relies directly on recent facts, the context is still clear and the history contains verified sources. For example, after reading a function and its test, you can ask for the condition to be changed and the diff shown. But before a write or an external action, check the current revision and the relevant instruction, especially if the branch, the environment or the scope of work has changed.

Start a new session when you move to an independent task, when the history has accumulated a lot of irrelevant or conflicting results, when you need a separate review, or when the earlier work is better reset to a short state. A new session does not automatically mean a new working copy or a clean repository state: check which directory, branch and environment it runs in, which instructions were loaded, and whether the same tools are available.

Hand the work over when another implementer, another agent or a person will continue it, or when the task outlives several context windows. The handoff should contain the working brief described above, the path to the current plan and evidence, the state of the changes, the sources and the constraints. For uncommitted changes, name the working copy; for committed work, give the exact commit. State explicitly which side effects were performed and which are not permitted. Do not assume the new conversation has access to the previous history.

After the switch, read the brief and check the sources that determine the next decision. If a requirement has changed, update it with its origin and date rather than quietly rewriting the earlier decision. If a condensed retelling conflicts with a current document or log, resolve the conflict through the authoritative source, not by trusting whoever wrote last.

Worked example 1: two versions of a rule

The setup. A team asks for a return-window check to be added to an order service. The agent finds three pieces of information:

Find	What it says	Origin and status
docs/returns-policy.md, version 4.2, in the current commit a18c4d2	For eligible items, a return request must be submitted within 14 calendar days of delivery. The rule applies to orders created on or after 1 January 2026.	The current approved source: the register docs/policy-index.md marks version 4.2 as in force and as superseding 4.1; this record was checked in commit a18c4d2.
support/returns-runbook.md, version 4.1	An operator may accept a request within 30 days of delivery.	An old instruction; the register of current policy in commit a18c4d2 marks it as superseded by version 4.2.
A retelling of an earlier conversation	"I remember the window is 30 days for all orders."	No source or date given; this is evidence of an old message, not of current policy.

The current decision. Use version 4.2 as the source in force: implement the 14-day window only for orders created on or after the date it defines, provided the code confirms the required dates and their meaning. Do not apply this limit to older orders without a separate rule.

What remains unknown. The excerpts do not define a transition rule for orders created before 1 January 2026, the handling of items excluded from the policy, the time zone, or the behaviour when the delivery date is missing. These are not details to fill in by guessing. They need an authoritative document or a decision by the responsible policy owner.

How to hand the task on. The brief keeps the exact paths, versions, the commit, the effective-date condition and the unknowns. A reviewer can open the files and check the change themselves. If a later summary keeps only the sentence "returns within 14 days", it has already lost the scope and the exceptions; they must be restored from the primary source.

This example shows why the source, the current decision and the unknowns are separate fields. A date that looks newer does not always prove authority; a remark in conversation does not become policy; a compromise between two values does not resolve the conflict.

Worked example 2: do not apply a migration after compaction

The setup. An agent is preparing a database schema change for tracking booking attempts. The repository contains the file alembic/versions/b91ce2_add_booking_attempt_status.py and a task: review the SQL (Structured Query Language), write a rollout plan and describe the recovery step. The handoff conditions are unambiguous:

• it is permitted to read the migration, review its dependencies and run static analysis that does not connect to the database;
• it is forbidden to run the migration against a local, test, staging or production database;
• applying it requires separate approval from the database owner and a check of the backup plan;
• the current code revision is 7f91b0c; the changes have not been merged yet.

Before compaction, the agent read the file, recorded the work state and saw that the script adds a column and backfills it for existing rows. After compaction, the short summary says: "Schema ready; move on to validation." It does not repeat the prohibition on running it. The command alembic upgrade head, if run in a configured environment, could apply the changes to the database.

What to do after compaction. Do not run the migration command, and do not treat "move on to validation" as permission. The retelling did not preserve the critical constraint, so the agent first opens the state record and the original task, and checks the commit and the current configuration. After that it may run only a check that is known not to connect to the database. If the type of check is unknown or it might open a connection, first find out its mode, or do not run it.

A durable control. Keep the limits in a verifiable plan file tied to the revision: the status "not applied", the exact path of the migration, the permitted checks and the conditions for approval. Beyond the record, the environment must enforce the rule: the agent has no credentials or permission for staging or production without approval, and the deployment pipeline waits for manual confirmation by an authorised person. This stops an ordinary text summary from becoming the only barrier. If the system cannot technically block the action, do not run it, and obtain the necessary human decision before continuing.

Why a note is not enough. A summary can be short, incomplete or stale after the commit changes. Even a precisely written plan may not get loaded into the next session. And if the script has already been applied, a note saying "do not run" will not roll the schema back. That is why, for an operation with a side effect, permission controls, a manual gate, a separate apply command and a check of the actual state all matter. Text preserves intent and provenance; an environment control holds back the unwanted action.

The report after a safe check must name the actual mode and result, for example: "SQL read; static check without a connection run on revision 7f91b0c; no connection to the database was made; the migration was not applied; awaiting the owner's approval." You must not write "migration verified" in a way that sounds like confirmation that the migration was successfully applied.

This example shows why a constraint on an action has to outlive the chat history. Compaction can change the active context; it cannot grant authority to run something or replace an unchanging access control.

Worked example 3: the whole repository, or an index and targeted reading

The setup. In a fictional order-service repository, one error message for an invalid token needs to change. The requirement does not ask for an inventory of the whole project. At the start, the agent does not yet know which module produces this response.

First orientation: check the working directory, the branch and uncommitted changes; identify the root instructions in place; build a top-level map. A listing such as src/, tests/, docs/ gives navigational hints, not knowledge of what each file contains. If a section has its own instruction file, check that it gets loaded when the work reaches that folder.

Targeted search: find the current message text, the error code or the token handler; read the definition, the call sites and the relevant tests. Find the consumers of the response to make sure the task changes only the wording, not the status or the contract. Read the API requirement or the documentation for the public response if it defines compatibility. If the search reveals a shared implementation for several routes, widen the scope to those routes and their tests.

What not to load without a reason: the history of every module in the directory, third-party libraries, large logs, all the product documents and the entire earlier conversation. They may become necessary if a connection emerges, but their presence in the repository does not prove they are relevant to this request. The agent marks which paths it only saw and which it actually opened and checked.

When an index or a full read is the right choice. If the task changes to "find every place where the project treats an invalid token as valid", ordinary search by symbols and routes is the natural first tool. If you need to inventory several repositories with different names and semantic descriptions, a text index or RAG may be worth considering. A vector store is only one possible implementation; it is not required for a single known file. A full review of the repository is justified when the criterion requires coverage of all components or interactions; then you need to describe the search method, the exclusions and the evidence of completeness.

The answer after the investigation must be honest: "Read the root instructions, the handler in src/auth/token_handler.py, its call in src/api/login.py and the tests in tests/auth/test_token_handler.py at commit [identifier]. Other parts of the repository were not checked; no general audit of usages was carried out." If another call site or test turns up, add it and continue the search. This gives the reviewer a reproducible path to the sources.

No time, accuracy or percentage saving is attributed here to either the full read or the index: the result depends on the structure of the project, the search tool and the task. Only the fit between the method and the criterion is compared, not an invented benchmark.

Summary

Context is the content actually provided to the model for the current step, not a synonym for the working folder, the whole conversation or long-term memory. Tokens are spent on instructions, history, files, tool schemas, results and the response; the exact budget depends on the model and the product, and it changes. A file must actually be read or passed in, and the result checked, before you rely on its contents.

Large context windows do not guarantee equally accurate use of every fragment. The primary study Lost in the Middle measured a positional effect for certain tasks and older models; it does not establish a universal effect for all models. "Context rot" and "context pollution" are useful for describing possible problems, but they are not interchangeable standardised measures.

A good working context contains the goal, the criteria, the sources in force, the revision, the status, the unknowns and the next permitted action. Search, reading on demand and RAG help select data; a vector database is not required for every task. A summary after compaction compresses the history, so important decisions must stay tied to files, dates, commits and conditions. Product memory, prompt caching and durable state in files or services solve different problems.

A reviewer's clean context reduces unnecessary noise, but it does not guarantee independence or correctness. If an instruction was skipped, find out whether it was loaded, current, clear and within the scope of the current task. To continue, choose between the same session, a new session and an explicit handoff based on the state of the work; in every case, check the current source before an important action.

Sources and further reading

The official product pages and documentation below were checked on 23 September 2026. Live Anthropic and OpenAI pages that showed no publication date or revision number in the version reviewed are marked as current documentation with no visible update date; the links lead to pages that may change. API parameters and product features are described here as they stood on the verification date, not as a guarantee of access for every account.

1. Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni and Percy Liang, "Lost in the Middle: How Language Models Use Long Contexts", Transactions of the Association for Computational Linguistics, volume 12, pages 157–173, published February 2024; DOI (Digital Object Identifier) 10.1162/tacl_a_00638. The primary peer-reviewed paper and its experiments; the conclusions are limited to the described datasets, conditions and models of that period.
2. Anthropic, Context windows, current documentation with no visible publication date or version; checked 23 September 2026. Supports the description of what goes into the Claude API context, the interplay of input, output and reasoning, and compaction. Model limits may change; this unit does not fix them as numbers.
3. Anthropic, Compaction at a token threshold, current documentation with no visible publication date or version; checked 23 September 2026. Describes server-side compaction in the Messages API and its block in the response. The documentation marks the feature as beta as of the verification date.
4. Anthropic, Context editing, current documentation with no visible publication date or version; checked 23 September 2026. Distinguishes selective clearing of context from compaction; the specific API parameters depend on the current version.
5. Anthropic, Prompt caching, current documentation with no visible publication date or version; checked 23 September 2026. Describes prompt prefix caching and checkpoints; not a source of durable task state.
6. Anthropic, Effective context engineering for AI agents, engineering article published 29 September 2025; checked 23 September 2026. Explains the term context engineering, just-in-time retrieval of data, compaction, notes and subagents. This is vendor material, not an independent comparative benchmark.
7. Anthropic, Introducing Contextual Retrieval, engineering article published 19 September 2024; checked 23 September 2026. Explains one retrieval approach for RAG and its drawbacks; the claimed improvements relate to experiments run by the authors, not to every store or task.
8. Anthropic, How Claude Code remembers your project, current documentation with no visible publication date or version; checked 23 September 2026. Describes memory and instruction loading specifically in Claude Code, the tools for checking what was loaded, and the difference between text instructions and enforced configuration. The behaviour should not be assumed to carry over to other agents.
9. Anthropic, Memory tool, current documentation with no visible publication date or version; checked 23 September 2026. Describes how an application with its own store performs memory operations requested by the model through a tool.
10. OpenAI, Conversation state, current API documentation with no visible publication date or version; checked 23 September 2026. Defines input and output tokens and the context of the Responses API; also describes the durable Conversations API object. This is one specific API model for managing state, not a property of every ChatGPT session or any other agent.
11. OpenAI, Compaction, current API documentation with no visible publication date or version; checked 26 September 2026. Describes server-side and separately invoked compaction in the Responses API and notes that the compaction item is opaque to the reader.
12. OpenAI, Key concepts, current documentation with no visible publication date or version; checked 23 September 2026. Explains GPT as generative pre-trained transformer.
13. MosaicML, LLM Foundry repository (LLM: large language model), official repository; checked 23 September 2026. Expands MPT as Mosaic Pretrained Transformers.
14. OpenAI, Prompt caching, current API documentation with no visible publication date or version; checked 23 September 2026. Explains prefix reuse and the model's key–value (KV) states, the matching conditions and the effect of changing the prefix. Exact caching thresholds and behaviour may vary between models.
15. OpenAI, Codex documentation, checked 23 September 2026: the address redirects to the official ChatGPT Learn, whose navigation includes sections for Codex Desktop, CLI, IDE and Cloud. This records the redirect and the list of product surfaces as of the verification date; the page does not confirm a Codex API specification.
16. Alembic, Tutorial, current documentation with no visible publication date; checked 26 September 2026. Describes revision scripts in the versions directory and running managed migrations through the Alembic command.

Limits of the sources and conclusions. The empirical basis for the positional effect is a single primary 2024 paper on models and tasks defined by its authors. The current characteristics of Anthropic and OpenAI products come from the vendors themselves and confirm only the APIs or product documentation they describe as of the review date. They do not prove the behaviour of every configuration, the quality of a particular session, the completeness of a file read, or the availability of a feature to any given user. This unit uses no benchmark of its own and no invented numerical comparison.