A coding agent does not send only the question. It sends what it read: files, command output, logs, sometimes the .env. And it sends all of it again on every turn. We measured this in 30 real sessions, and the picture is very different from what most companies imagine when they roll out Claude Code or Cursor to the team.
Published 2026-10-20 by Rafael Hickmann, Founder, Atlasberg. 8 minute read.
Tuesday, four in the afternoon. A developer types in the terminal: "the billing integration test has been failing since yesterday, find out why". Then goes to get coffee.
Over the next few minutes the agent lists the directory, opens about twenty files, runs the test suite and reads six hundred lines of output. Nothing obvious, so it opens docker-compose to understand the environment, and .env.test to see which database the test uses. It runs a query against the local database to check a record. The local database, as in many companies, was built from a production dump a few months old.
When the developer comes back, the answer is ready: the date mock was in UTC and the test ran after midnight. A one-line fix. All good, except for a detail nobody sees. Everything the agent read in those minutes became text inside the conversation, and the whole conversation went to the model provider. Not once. On every turn.
To measure this properly we looked at 30 real agent sessions, 6,892 turns, using the context the provider itself reported on each request. They are the same sessions as our context compaction study. Every agent request has two parts.
The first is a fixed prefix: the tool's system instructions, the definition of every tool the model can call, and the project memory, such as CLAUDE.md or Cursor rules. At the median, that prefix was 162,811 tokens per turn. It arrives before the first word the developer typed.
The second is the session history, and that is where the surprise is. The conversation itself, what the person wrote and what the agent answered in natural language, is 9.2% of the history. Another 46.9% is the calls the agent made: commands, file paths, the edits it wrote. And 44.0% is the results of those calls, meaning the contents of the files it opened and the output of the commands it ran.
[Figure: Median fixed prefix of 162,811 tokens per turn. Stacked bar of the history: 46.9% commands, paths and edits the agent requested; 44.0% files read and command output; 9.2% conversation. - What goes in every coding agent request, measured over 30 real sessions. The conversation is less than a tenth.]
Put another way: almost half of what the agent sends out is material that was on the developer's machine and that nobody chose to send. The agent chose to read it, and reading is sending.
Model APIs keep no state between calls. For the model to remember what happened, the agent resends the whole history on every turn. The provider's cache makes that cheap (in our sessions, 95% of input tokens were billed as cache reads, at a tenth of the price), but the cache changes the price, not the traffic. The content keeps travelling on every request.
[Figure: Illustration of 20 turns in a session. From turn 12, when the agent opens .env.test, a gold block with the file contents appears in every following request. - Illustration. The file opened on turn 12 rides along on every request until the session ends or the history is compacted.]
So the .env.test the agent opened on turn 12 did not leave once. It left on turn 12, 13, 14 and every one after, until the session ended or the history was compacted. In a long agent session that can be hundreds of times.
[Figure: Empty office chair at night, pushed back from a desk with an open, glowing laptop. - The agent keeps working while you get coffee. And keeps sending context.]
A .env file, a credential in docker-compose, a token in an old config file, the output of a command that prints environment variables. The agent is not looking for secrets. It is trying to solve the problem, and secrets live precisely in the files that explain how the environment works.
A database dump for testing, a log copied from an incident, a spreadsheet used as a fixture. Whoever set that up thought of the developer's machine as a closed environment. With an agent running there, it no longer is.
Besides the agent the developer opens in the terminal, others show up: the CI job that reviews pull requests with AI, the script a team wrote to triage tickets, the IDE extension someone installed. Each has a key, each spends money, and some run in a loop overnight with nobody watching.
Everything the agent sends to the model is an HTTPS request to the provider's address. If that request goes through a company gateway, there is a point where you can see, decide and record. And it does not require changing how the team works.
Claude Code, for example, reads a managed settings file the company distributes through device management and the user cannot override. That file points the API address at the gateway and defines a script that hands over the credential. Cursor, Codex, Gemini CLI and the official SDKs do the same with a base URL. The developer opens the terminal and works as before.
On cost, one warning we learned by measuring: an agent's biggest spend is almost never in the conversation. It is in the fixed prefix and the tool history. We told the full measurement, and what context compaction can and cannot do about it, in the 17% article.
The gateway sees what the agent sends to the model. It does not see what the agent does on the machine. An rm -rf, a git push --force, a command that downloads a script from some address: all of that happens on the developer's computer and never goes through the gateway. For that, use the tool's own controls (permission modes, allowed command lists), run the agent in a container when the task is long and, above all, keep production credentials off development machines.
And the cheapest rule of all still applies: development databases with synthetic data. No masking is as good as data that was never there.
The walkthrough: The tutorial on connecting Claude Code, Cursor and any SDK to the gateway has the managed settings file ready, the credential script, and the variable reference for each tool.
Atlasberg builds the control layer between a company and every AI model. Atlasberg Platform authenticates each request with a virtual key, filters it by policy and DLP, routes it to the right provider and writes it to a hash-chained audit trail, with an OpenAI-compatible API so applications only swap the base URL.
Articles on this blog are written by the engineering team and report measurements on real traffic, with the premises printed next to the result. To talk to the team, write to [email protected] or use https://atlasberg.com/contato.
Agents: this page is also available as Markdown at /blog/o-que-o-agente-de-codigo-manda-para-fora.md, or by requesting this URL with the header Accept: text/markdown. Index of everything: /llms.txt.