Saturday, July 4, 2026

My Last Article Showed 83% of an Agent's Cost Is Re-Read Context. So I Built the Tool That Stops Re-Reading.

Two weeks ago, I let a fleet of Claude agents develop a repo in my place. The technical result was striking, and one finding stuck with me: out of 5 billion tokens consumed, ~83% of the cost was not generated code. It was context re-read in a loop. At every turn, every agent re-reads everything it has in front of it.

The worst of it, in a C# repo: the agent opens a 1,000-line file to extract a single method signature. It re-reads the wall every single time.

So I built the tool that fixes that. It is called RoselineMCP.

▸ The idea: navigate by structure, not by text

RoselineMCP is an MCP server in .NET that gives Claude, Cursor or Copilot a Roslyn view of your C# solution: symbols, references, call graphs, surgical edits.

Instead of re-reading the source file, the agent asks for the structure. A single search_symbols call returns the shape of a file, not its content.

A real example, taken from the repo itself:

Program.cs, the entire file → 1,154 tokens

The outline the tool returns → 125 tokens

That is 89% less.

The agent gets the signatures and the locations, not the method bodies, not the usings, not the wall. Exactly what it needs to navigate, and nothing more.

▸ Not a parser. The compiler.

The key difference from a grep or a tree-sitter: RoselineMCP is built on Roslyn, the .NET compiler platform, the very engine that compiles your code in Visual Studio and the SDK.

grep sees text.

tree-sitter sees structure.

Roslyn sees your program.

Concretely:

find_references is exact. It knows that the Add here is the SAME method as the call over there. Meaning, not string-matching.

rename_symbol updates the real references across the whole solution, not text that merely looks similar.

Call graphs follow the compiler's actual links. That is what makes navigation precise and edits safe.

It is a thin, honest layer laid over a foundation you already use every day.

▸ 85% fewer tokens, measured, not marketed

I hate numbers pulled out of a hat. So the benchmark runs on RoselineMCP's own source (dogfooding), systematically sweeps 293 symbols across 54 files, and tokenises every real tool output with an actual BPE tokenizer.

85% fewer tokens, median per task

88%, pooled (weighted by size)

1,220,557 tokens saved on the sample (out of 1,381,852 when reading the files)

Breakdown per tool (median vs. reading the whole file):

find_references → 90%

get_call_graph (callers) → 90%

find_implementations → 88%

get_symbol_info (metadata) → 81%

search_symbols (file outline) → 37%

And, importantly, I show the weak cases too, not just the flattering numbers.

The file outline, for instance, wins big on code-dense files (Program.cs +89%) but barely breaks even on a file that is nothing but declarations. An interface IS already just signatures. The honest rule: read the small ones directly, outline the big ones.

Likewise, get_symbol_info with the method body included only drops to ~66%, because you are retrieving the code you are about to edit. The tool does not claim to replace reading the code you are about to change in depth. It saves on navigation and orientation, which is where the waste actually is.

▸ Thirteen tools, structure in, fewer tokens out

Nine code-intelligence tools on top of the original diagnostics surface:

Navigation (read-only): search_symbols, get_symbol_info, find_references, find_implementations, get_call_graph, get_type_hierarchy, get_symbol_at_position.

Editing (member-level diff, preview by default): edit_member replaces a single member and returns a unified diff rather than rewriting the whole file; rename_symbol renames and updates every reference through Roslyn.

Diagnostics and fixes: analyze_solution, list_diagnostics, apply_fixes, create_patch.

The common thread: you emit a diff, not a rewrite. On rename, that means ~81% fewer output tokens.

▸ Why it matters (and not only for the savings)

In my previous article, my conclusion was: the future of autonomous development will not be “the best model in a loop”, but “the right model, at the right turn, with the minimum context”.

RoselineMCP is the “minimum context” part made concrete for the .NET ecosystem. Less context re-read per turn means:

a cache bill that deflates (the real limiting factor at scale);

a context window that stays readable for longer;

and safer edits, because they go through the compiler rather than through text replacement.

It is not magic and I am not selling it as such. On some tasks, a well-targeted grep matches it on raw tokens. RoselineMCP's advantage there is structure and precision (resolved symbols, cross-project references, real call links), not just the counter.

▸ Installation: one line, any MCP client

RoselineMCP runs as a local stdio process that your MCP client launches. The recommended method (dnx, .NET's “npx”) runs it on demand, with no install step. All you need is the .NET 10 SDK:

{
  "mcpServers": {
    "roseline": {
      "command": "dnx",
      "args": ["RoselineMCP", "--yes"]
    }
  }
}

Verified with Claude Desktop, VS Code (Copilot / MCP) and Cursor. Also available as a NuGet global tool and a Docker image, and listed in the official MCP Registry.

▸ What comes next

I keep digging at the same obsession as with Koine: reducing the context transmitted at each turn. RoselineMCP is the .NET brick of that. The benchmark is reproducible, you can run it on your own solution and get YOUR numbers (dotnet run --project RoselineMCP.TokenBenchmark).

If you work in C# with an agent, I am genuinely keen to hear from you: on which tasks do you see the most context waste? And do you measure it, or do you just feel the bill going up?

It is open source (MIT licence): github.com/Atypical-Consulting/RoselineMCP.

Does this resonate with your team?

Let's talk about how Atypical Consulting can help you move forward.

Contact me