Code Agents: What They Read Before Writing a Single Line

LYES CHIOUKH ✨ — Fri, 23 Oct 2026 17:04:44 +0000

With Claude Code, Codex, or Gemini CLI, the quality of a session - and its cost - largely depends on what the agent reads. Managing that context is an architectural discipline: a concise baseline, knowledge loaded at the right time, sessions kept under control, and costs that are actively measured.

Code assistants and coding agents have become part of developers’ daily workflows. According to Stack Overflow’s latest Developer Survey, conducted among more than 30,000 developers and technology professionals across 169 countries, coding assistants and agents have become the leading AI use case, with 66% adoption, ahead of general-purpose chatbots. Among users of AI coding assistants or agents, 73% use them daily.

When a session goes wrong or the bill starts to rise, the first suspect is usually the model - or the way the prompt was phrased. Far less attention is paid to what the agent had already read before answering. Yet an agent can only work with what is available in its context, and part of that context never appears on screen.

This raises the central question of this article: how can we give a coding agent enough context to work effectively, without overwhelming it or paying for the same information at every turn ? To answer that, we need to follow the context throughout a session: from what is loaded before the first prompt to what eventually drives cost.

What the agent reads before it starts working

An agent does not read like a chatbot. It opens files, runs commands, receives tool outputs, and adds all of that to its context. Anthropic notes that Claude Code sessions are more token-intensive than standard chat because they include system prompts, file context, tool calls, and multi-turn reasoning.

Part of this context is loaded before the first user prompt. At startup, the agent loads its instruction file - CLAUDE.md for Claude Code, AGENTS.md for Codex and other agents, and GEMINI.md for Gemini CLI - along with memory, available tools, and capability descriptions. In Claude Code, the /context command shows what is currently loaded into the context window.

Connected tools can consume more context than teams expect. Anthropic has documented cases where tool definitions consumed more than 50,000 tokens before the agent even processed the user’s request, which is why tool discovery and on-demand loading are important for keeping context manageable.

Then there is the instruction file, which every team is tempted to expand. Recent studies have measured its impact, with mixed results. A study associated with ETH Zurich and LogicStar.ai found no general improvement in task success, but reported an inference cost increase of more than 20%.

Repository overviews, although common, did not help much. Another study on AGENTS.md files measured faster execution on 124 pull-request tasks, with median runtime reduced by nearly 29%, but without evaluating result correctness. Khatri’s ablation study, by contrast, found no measurable improvement in the correctness of generated code.

These studies nevertheless point in the same direction: an instruction file does not make an agent fundamentally more capable. It prevents the agent from guessing what cannot be inferred. The best content for such a file is therefore information that is not already available in the README or codebase: project-specific conventions, non-functional requirements, unusual build steps, architectural constraints, or rules that are easy to violate. Anthropic similarly recommends keeping CLAUDE.md lean - roughly under 200 lines.

Keeping context useful during the session

Once a session starts, the context grows with every file read and every command executed. As the context window fills up, the tool may summarize the conversation to free space. Claude Code exposes this through /compact, while /clear starts a new conversation when switching tasks. Anthropic’s practical rule is simple: use /clear for a new task, and /compact when continuing a long task.

That matters because context quality directly affects output quality. A long debugging session may include dozens of files, command outputs, failed attempts, and intermediate reasoning. If all of that remains in the session, each new request carries more noise and more cost.

Some steps generate a large amount of text for a single conclusion: exploring a codebase, checking a result, reading a long log, or reviewing test output. A sub-agent can handle this work in its own context and return only a concise summary to the main session. Claude Code documentation describes subagents as secondary Claude instances that work in their own context window before reporting back.

The key question is straightforward: will the raw output be useful later, or only the conclusion? If only the conclusion matters, isolating the task can keep the main context cleaner. But isolation also has a cost: each sub-agent may still explore files, run commands, and consume tokens.

Claude Code also supports workflows where different models are used for different parts of the task. Anthropic recommends Sonnet for most coding work, Opus for harder architectural or debugging problems, and Haiku for faster, cheaper lookups or simple edits. A common pattern is to plan with a stronger model and execute with a more economical one.

And then there is the cost

In Claude Code, cost comes primarily from repeated context. Every turn sends the conversation so far, project context, files read, and the new user prompt back to the model. The longer the session, the more expensive each additional interaction can become. Anthropic’s documentation recommends using /cost for API-billed sessions and usage analytics for team or enterprise monitoring.

Prompt caching is usually one of the main levers for reducing cost: stable context can be reused more cheaply than context that changes constantly. A stable baseline therefore costs less over time; a baseline that is repeatedly rewritten loses part of that advantage.

Context is also a security surface. Everything the agent reads can influence its behavior: a web page, an issue, a pull request, a log file, or the output of a tool. OWASP ranks prompt injection - direct or indirect - as the top risk for LLM-based applications in its 2025 Top 10.

This leads to two important practices:

treat external content as data, never as instructions;
connect only useful, verified, and necessary MCP connectors.

Principles for managing coding-agent context

Managing the context of a coding agent relies on several principles:

short instructions that are reviewed regularly;
knowledge loaded only when needed;
sessions kept focused and bounded;
noisy tasks isolated where appropriate;
costs monitored continuously;
external inputs treated as untrusted data.

Each team member contributes at their own level: checking which information the agent loads, maintaining versioned and reviewed instruction files, defining access rights, or setting usage budgets. These complementary responsibilities determine what the agent can access, how much it can consume, and how reliably it can work.

Sources