Show and tell: Reducing token waste in REA workflows. What are you using?

[jaelliot]

Hey everyone,

I've recently contributed to REA's generic MIPS and PSP/Allegrex support ([#1362](#1362) and [#1599](#1599)), and I've been building a personal reverse-engineering lab around REA, Ghidra, and Codex.

One thing I'm particularly interested in is reducing LLM token consumption during reverse engineering.

These investigations can become pretty context-heavy. Between large decompilation results, function inventories, cross-references, tool responses, and agents repeatedly exploring the same code, it's easy to consume a substantial amount of tokens without necessarily making much progress.

I've been experimenting with a few approaches in my other development work and am now adapting them to my RE lab.

What I'm currently working with

• REA + Ghidra: My primary binary-analysis stack. I'm focusing on bounded function queries, targeted cross-references, reusing analysis sessions, and retaining evidence rather than repeatedly analyzing the same material.
• CodeGraph: Structural code intelligence for exploring architecture, call relationships, and dependencies in source repositories.
• Serena: More targeted symbol and reference retrieval through language servers, avoiding unnecessary whole-file reads.
• Context7: Retrieving relevant API and library documentation instead of relying on broader searches.
• [Ponytail](https://github.com/DietrichGebert/ponytail): Simplicity-focused engineering guidance intended to discourage unnecessary abstractions and overengineering.

The source-code tooling has been useful in my other projects, although I'm still integrating and benchmarking the overall approach in my reverse-engineering environment.

I'm also working on more disciplined agent workflows: limiting investigation scope, using appropriate models and reasoning effort, maintaining checkpoints between sessions, and keeping large raw analysis artifacts outside the model's context until they're actually needed.

What I'm curious about

How are other people optimizing their REA workflows for token efficiency?

I'd be especially interested in hearing about approaches to managing large Ghidra results, caching analysis across sessions, reducing repetitive MCP calls, and keeping agents focused during long-running investigations.

Are there other MCP servers, code-intelligence tools, caching mechanisms, or agent-harness features that you've found particularly effective?

I'm also curious whether anyone has benchmarked these approaches against actual token usage rather than just output size. Fewer bytes and fewer tool calls are useful, but ultimately I'd like to measure something closer to tokens per verified finding, while preserving correctness.

I don't think the goal should be to make REA return less information indiscriminately. It's more about ensuring the agent retrieves the right information, at the right time, without unnecessarily repeating work.

I'd be interested in hearing what people have tried, what has worked, and what hasn't. If anyone has benchmark results or an interesting setup, I'd love to take a look.

I'm planning to run some controlled comparisons in my own lab and would be happy to share the results as that work progresses.

[CassieFox23]

TL;DR: I don't have token numbers either. What helps me most is splitting the work. One main agent plans, cheaper agents do the digging, and only short reports come back. Everything lands in files, so nothing gets found twice.

Thanks, jaelliot, for starting this. I first picked up REA to help troubleshoot huge modpacks for single-player games. I liked the project a lot, so now I help by running tests on PRs and issues where I can. So my setup is a Linux test lab for REA pull requests, more than an RE lab. The context problems are the same, though.

The box: Nobara 44 (Fedora-based), Ryzen 9 5900X, 32 GB RAM and a Radeon RX 6700 XT with 12 GB. I drive Claude Code from its extension in VSCodium (MIT), and from Paw, my own build of the foot terminal (MIT), inside tmux (ISC). My notes live in an Obsidian vault.

What I run

• A hub and helpers. One main agent, Opus 5.5, holds the plan and talks to me. It hands each job to a helper with a fresh context. Sonnet 5.5 runs tests, and Haiku 5.5 scouts GitHub, read-only. Fable 5.1 gave advice here and there. The helper's transcript stays out of the main context. Only its final report comes back.

• One shared brief. Every helper reads the same rules file first: paths, how to build, what never to touch, and how to report. That saves explaining it in each prompt. A fix in one place reaches every agent.

• Checkpoints on disk. Each job writes a results file, a draft and raw logs to its own folder in the Obsidian vault. A later job reads the results file, not the old transcript. Before the context gets compacted, the main agent writes a short handoff file.

• Local models for chores. llama.cpp (MIT) runs behind llama-swap (MIT). Qwen3.5 4B and 9B take the chores, and KAT-Coder-V2.5-Dev is the code seat, at 32k context. The brief tells helpers to hand big logs to them first, so only the findings come back. Any number they give gets checked again with a script.

Large REA results

• Ask narrow questions: one function, one address, one xref list. Skip the full inventory until it's needed.

• Raw REA output goes to a file in the job folder. The agent reads the part it needs.

• feat(mcp): add operator tool selection #1669 (operator tool selection, still open) narrows the MCP tool list. I tested it on Linux. Fewer tool descriptions should mean less context, but I didn't measure tokens.

What went wrong

• A helper ran a tool with no path, and it walked my whole home folder. Now every tool that walks files gets an explicit path.

• Helper numbers were sometimes off. The main agent now checks one claim per report against the source, like a commit, a code line or a log.

A local model and REA

#1065 counts REA's tool list at about 141k proxy tokens, before some later trims. My local code model has 32k, so MCP can't fit. #1669 would be one way in.

So today I tried the CLI route. OpenCode (MIT) ran KAT-Coder with rea allowed in bash, on a tiny test program. It didn't work yet. In four runs the model never called rea. It looped on other tools instead, like reading the binary as a text file. REA itself was fine: rea inspect took 8 seconds and about 1,000 tokens of output.

On this card the model reads prompts at about 320 tokens per second and writes about 26. Next I'll try with bash as its only tool.

Measurements

Edit: I counted my real token use from the session logs on my box. This covers all my agent sessions from October 9 to 11. Nearly all of it was REA testing. It also includes some small personal tasks that weren't REA, so the numbers are a bit muddied. Treat it as a rough count until I run a clean REA-only benchmark.

Three days	Tokens
Model replies	22,463
Fresh input	about 70k
Output	7.5M
Cache writes	73.7M
Cache reads	3.56B

• Fresh input is tiny. Almost all input is cache reads, where the same conversation is read again each turn. Long sessions drive that number up.
• The main agent wrote about 78% of the output. Helpers wrote the rest: test helpers about 7%, scouts about 4%, and other helpers about 11%.
• I don't have tokens per verified finding yet.

My other REA benchmark is MCP start-up time. If you share your baseline, I'm happy to run it on Linux.

🤖 Generated with Claude Code (Opus 5.5) 🦊

[jaelliot]

Thanks for the detailed breakdown. This is exactly the kind of practical experience I was hoping to hear about.

The coordinator/helper separation is particularly interesting to me. I've been building something conceptually similar in my RE lab, but I haven't properly benchmarked whether separate agent contexts reduce overall token usage.

Your cached-input numbers also stood out. It makes me wonder how much we could save by keeping the main agent focused on coordination and delegating the actual investigation work to agents that return short, evidence-backed reports.

A couple of questions:

• Do you use a standardized format for your helper reports, or is it mostly Markdown with task-specific findings?
• How do you decide when something warrants a separate helper versus keeping it in the main agent's context?
• Have you noticed any tradeoff between the savings from fresh contexts and the additional overhead of starting new agents?

I also took a look at #1669. Being able to restrict the MCP tool catalog seems particularly useful for local models with smaller context windows. Your OpenCode experiment is interesting because it suggests that simply exposing the REA CLI isn't enough to get reliable tool selection.

I'd definitely be interested in comparing benchmarks. I'm working on a source-owned baseline for my lab, and I'd like to test the difference between a single agent and a coordinator/helper setup while keeping the same tasks and verification requirements.

If we can establish a reproducible benchmark, I think we could get some genuinely useful measurements out of this.

[CassieFox23]

TL;DR: Yes, my helper reports follow one fixed shape. A job goes to a helper when it means lots of reading and I only need the answer. Starting a helper costs about 23k tokens. My main agent carries about 300k on a typical call, so the start-up cost is small next to that. I'd like to compare benchmarks.

Thanks, jaelliot. Good questions. I've also named the parts in my first comment now. I drive Claude Code from its extension in VSCodium. Opus 5.5 is the main agent. Sonnet 5.5 runs the tests, and Haiku 5.5 does the GitHub scouting. Fable 5.1 gave advice here and there.

Report format

It's Markdown, but the shared brief fixes the parts. Every test helper ends with:

• A one-line headline result.
• A table of each command it ran, with its exit code.
• The path to its draft, plus the draft's plain-language grade.
• What it didn't run, and anything it didn't check itself.
• Anything surprising.

The full detail goes to a results file in my Obsidian vault. That file has every command, exit code and number. The main agent reads the short report. It opens the results file only to check a claim.

Scouts use their own brief. It holds a list of triggers, like a new commit on a PR I tested. A scout reports which ones fired, and it suggests a few new PRs to test.

Helper or main agent?

• Helper: anything that reads many files, runs long, or builds and tests. I only need the conclusion from those. Tests go to Sonnet, and read-only GitHub sweeps go to Haiku.
• Main agent: a single quick lookup, checking a helper's claim, and anything posted under my name.

Start-up cost

I measured this from the logs of my REA session, October 9 to 11. "Context" here means all the tokens sent on one call.

Who	Count	Context at first call (median)	Context at last call (median)
Sonnet helpers	144	23.9k	119k
Opus helpers	76	23.2k	114k
Haiku helpers	49	22.9k	73k
Main agent, per call	5,292 calls	—	302k

• A new helper starts at about 23k tokens before it does anything. That's its own setup plus the job prompt.
• The main agent's context is much bigger, so work kept there rides on about 300k each call. A helper's work rides on 24k, growing to about 119k by the end.
• I haven't run the same task both ways yet. So I can't say how much this saves in total.

The costs that aren't tokens matter more to me:

• A helper doesn't know what the main agent knows. Everything has to be in the brief or the prompt.
• Helpers break rules more often, so the main agent checks one claim per report.
• Several helpers share one box. Timings get noisy, and once they filled my temp disk.

A benchmark

I'm in. Here's what I'd suggest: the same task list, run once by a single agent and once with a main agent and helpers. Keep the same rules for what counts as verified. I count tokens from the Claude Code session logs, and I'm happy to share the script. When your baseline is ready, I'll run it on Linux.

🤖 Generated with Claude Code (Opus 5.5) 🦊

[CassieFox23]

TL;DR: I tried a free local model as a helper for REA. It reads REA output well when a script hands it over. It can't run REA on its own yet. So a local model can save tokens on reading, but Claude still has to drive.

Following up on helper costs. The cheapest helper is one that costs no tokens at all, so I tried a model on my own GPU.

Setup

• Model: KAT-Coder-V2.5-Dev from Kwaipilot (Apache-2.0). I use a 4-bit IQ4_XS file with 32,768 tokens of context. It runs on llama.cpp (MIT) behind llama-swap (MIT), on a Radeon RX 6700 XT with 12 GB.
• REA 6.3.0 through the CLI, not MCP. The MCP tool list alone is far bigger than the model's context.
• The target is a tiny C program of my own. It checks a secret word and prints whether you got it.

Results

Try	How it works	Result
A: agent loop	The model drives REA from OpenCode (MIT)	5 runs, and it never called rea. It looped on other tools, or wrote the command as text and stopped.
B1: script feeds it	A script runs 3 REA commands. The model gets all the output and answers questions.	Works. 3 of 3 answers agreed, and none made up the secret.
B2: it picks, a script runs	The model writes the next rea command as text. A script runs it if it passes an allowlist.	Half works. All 16 replies began with a valid rea command, and 12 of them ran. It never gave a clean final answer in 8 steps.

• The secret isn't in the file. The compiler folded the word into a length and a hash. So "8 letters, and this hash" was the best possible answer. The model said that, and it didn't invent a word.
• The B2 slips: twice it put its answer under a command line, where my script didn't look. Twice it wrote fake tool output of its own. Four times my script refused a command with quotes or a colon in it, and my error text didn't say how to fix it.
• Speed: in an earlier run it wrote 26 tokens a second. Tonight's B runs were much slower, and the CPU was busy with other work then. The biggest prompt in any run was about 18,000 tokens, well inside its 32,768.

What it means for helpers

A local model works as a reader. Give it REA output and a narrow question, and it answers well for free. It doesn't yet work as a driver that picks tools and knows when to stop. So for now Claude plans and drives, and the local model can take the reading.

Not run

• B2 with the fixes: accept an answer anywhere in the reply, explain refused commands, and add a way to test a guess.
• Fresh speed numbers on a quiet box.
• Other local models, and REA over MCP with a trimmed tool list.

More detail

• The B1 commands were inspect, decompile main and a strings search, each with --provider ghidra and --token-limit 1500. Each took 11 to 13 s.
• In B2 the model wasted early steps. It ran inspect and then analyze, which gave the same output, then searched for strings it guessed at. One run reached decompile on step 5, the other on step 8.
• In one buried answer it tried the hash maths by hand and got the numbers wrong.
• A cold model load took about 30 s, from the llama-swap log.

Test setup

• Box: Nobara 44 (Fedora 44 base), Linux 7.2.9
• CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads
• RAM: 32 GB DDR4-3600
• GPU: Radeon RX 6700 XT, 12 GB
• Node: 24.18.0
• REA: 6.3.0, with Ghidra 12.1.4 (Apache-2.0) and JDK 21
• Model: KAT-Coder-V2.5-Dev IQ4_XS, 32,768 context, thinking off, 22 expert layers on the CPU

🤖 Generated with Claude Code (Opus 5.5 and Sonnet 5.5) 🦊

[CassieFox23]

A follow-up to my KAT-Coder note above. I fixed the loop and reran it on a quiet box. It now ends with an answer every time, but it guessed in all 3 runs. Twice it made up the word "FoxVault" from the program's banner. The setup where a script runs REA and the model only reads stayed honest, 3 of 3. Details are in #2006.

🤖 Generated with Claude Code (Opus 5.5) 🦊

[morluto]

This is an interesting thread. Originally REA was designed as a proto codemode MCP but the thing is that most clients had built in forms of lazy loading for servers so tool context windows were no longer an issue.

Search + execute doesn't work well as a surface for most agents, but I do think that programmatically allowing agents to interact with tools is something that's worth exploring.

There was someone on localLLAMA that had modified his REA MCP's ghidra bridge to allow for this.

Just sharing my 2 cents on it

[CassieFox23]

Thanks, morluto, that matches what I saw with local models.

How the model used REA	Result
Picked tools itself, in an agent loop	Didn't work. It looped on other tools or never stopped.
Wrote the next rea command, and a script ran it	Good commands, but no clean finish
A script ran REA, and the model only read the output	Worked. The two 27B models had no wrong numbers and made nothing up.

So the programmatic route was the one that held up. My notes are above, and the five-model results are in #2006.

Do you remember the localLLaMA post? That modified Ghidra bridge sounds worth a look.

🤖 Generated with Claude Code (Opus 5.5) 🦊

[TheodorNEngoy]

A suggestion for the planned single-agent versus coordinator/helper comparison: keep unsuccessful and inconclusive tasks in the cost total. Tokens per verified finding can look better if a setup quietly stops tackling the hard cases.

I would keep one row per fixed task: outcome (verified, unknown, or incorrect), fresh input, cached input, output, and wall time. Aggregate the coordinator and every helper, including startup and failed attempts. Separate cold-start and resumed-session results, since reused analysis is part of what you are testing.

I have not benchmarked REA, so this is a proposed measurement layout, not a savings claim.

Written with Codex assistance.

[ashishmishra26]

Managing token consumption with large decompilation outputs is a very real challenge. Dumping full function inventories or large cross-reference graphs into the context window burns through tokens quickly and often dilutes the agent's focus.

One approach that helps significantly is shifting from a "push" model (dumping context) to a "pull" model using retrieval. By indexing the decompiled code and function metadata locally, you can give the agent tools to search and retrieve only the specific snippets it needs at that moment. Hybrid search is particularly effective for reverse engineering—you need exact keyword matching (BM25) for specific registers, memory addresses, or symbol names, combined with vector search for semantic queries like 'find the encryption initialization routine.'

If you're looking for tools to back this, I've been using Infino. It's an open-source retrieval engine that runs embedded (in-process, like SQLite), so you don't have to manage a separate search cluster for your personal RE lab. It handles hybrid search over Parquet files and includes an MCP server (@infino-ai/mcp-server) and a codebase-context tool (@infino-ai/code-context) designed specifically to let agents query their own context dynamically. This keeps the prompt lean and token usage tied directly to the investigation's progress.

Disclosure: I work on Infino.
Infino AI