Everyone selling AI coding tools right now makes roughly the same pitch: our AI understands your codebase, helps you write better code faster, and integrates seamlessly into your workflow. The marketing decks all look the same. The demos all feel impressive. But what these tools are actually doing under the hood - what they are sending to the model, how they construct context, what they know about your project versus what they are guessing - is almost entirely opaque to the engineers using them.
Until now, at least for one developer who decided to find out.
A methodical experiment documented at The Red Beard ran four major AI coding tools - including tools in the category occupied by GitHub Copilot, Cursor, and comparable competitors - while intercepting and analyzing every API call each tool made. The result was 3,177 API calls worth of ground truth about what these tools are actually putting in the context window that gets sent to the underlying language model.
For anyone evaluating these tools professionally, the findings are required reading. Let me explain why the context window question matters so much.
Large language models are stateless. They do not remember your codebase from session to session. Every time you ask an AI coding tool a question, the tool has to construct a context - essentially a package of relevant information that gets sent along with your query so the model has enough context to respond helpfully. That context can include your current file, surrounding files, documentation, recent edits, error messages, or nothing at all beyond the line of code you are working on. The tool decides what goes in.
Those decisions matter enormously. They determine whether the model actually understands the structure of your project, whether it hallucinates function signatures that do not exist in your codebase, whether it catches dependencies across files, and how much each API call costs you. They also have privacy implications - if a tool is sending your entire codebase or significant chunks of proprietary code to a third-party API with every request, that is a security posture decision your company should be making deliberately, not accidentally.
What the intercept experiment found is that the four tools take significantly different approaches. Some are relatively conservative about context inclusion, sending mostly the immediately relevant code. Others are more aggressive, pulling in surrounding files, recent edits, and project structure information. Some tools make many small, cheap API calls. Others batch more aggressively. The approach has direct implications for both cost and quality.
There are also differences in how tools handle ambiguity. When a function is referenced but not in the immediately visible scope, does the tool look it up in your project files and include its definition? Or does it wing it and let the model guess? The answer varies, and it is part of why the same underlying model can feel dramatically different depending on which tool is wrapping it.
For developers choosing between AI coding tools, the marketing and benchmark comparisons you will find on vendor websites tell you very little about these operational differences. The technology is impressive. Understanding what it is actually doing on your behalf is what separates informed adoption from expensive hope.
The full analysis at The Red Beard is worth reading if you have any role in evaluating developer tooling. This is what good technical investigation looks like - not a benchmark press release, but an engineer with a proxy and a lot of patience finding out what is actually true.
