LeanREA vs REA: Why Smaller Agent Skills Can Win

LeanREA vs REA is more than a comparison between two reverse-engineering helpers. It is a useful stress test for a larger question facing every team building with coding agents: when does adding more tools make an agent better, and when does it simply make the agent slower, costlier, and harder to steer?

A video from the creator behind LeanREA makes a pointed case for the latter. The creator benchmarked an approximately 8KB skill file against REA (Reverse Engineer Anything), a much broader MCP and CLI-based reverse-engineering toolkit, and reported that the smaller setup delivered nearly identical task accuracy while finishing faster, using fewer turns, and costing less. Those results are self-reported and limited in scope, but the underlying design lesson deserves attention: an agent often needs a better operating manual, not another hundred buttons.

What LeanREA and REA are trying to solve

Reverse engineering is a natural fit for coding agents. A developer may need to inspect a desktop application, understand an Electron bundle, identify a binary’s imported libraries, recover dependency information from a Go executable, or trace a protocol from disassembly. These tasks require a mixture of file inspection, static analysis, shell commands, and disciplined evidence gathering.

REA packages that work into a comprehensive agent-facing system. Its official project describes a workflow where an agent inspects an application or website, returns code and runtime observations, then helps explain or rebuild a feature. It spans targets such as desktop apps, native binaries, mobile packages, websites, and firmware. That breadth is useful because reverse engineering is not one task: the best approach for a Mach-O binary is not the right approach for an Android APK or a minified web bundle.

LeanREA takes the opposite implementation path. Rather than providing a large MCP tool catalog, it gives the agent a compact skill file: a set of routing rules, command patterns, first-pass reconnaissance steps, target-specific notes, and evidence conventions. The agent continues to use its existing shell access and locally installed analysis utilities.

In practical terms, the contrast looks like this:

• REA: exposes a large reverse-engineering capability layer through MCP and a CLI, helping agents discover and invoke specialized operations.
• LeanREA: tells an agent which standard command to use for a target, how to combine checks efficiently, and what edge cases are easy to miss.
• The shared goal: obtain defensible answers about software behavior from artifacts the developer is authorized to inspect.

The comparison should not be read as “MCP is bad” or “specialized tooling is unnecessary.” MCP is an open protocol designed to connect AI applications with tools, resources, prompts, and outside data. Its purpose is interoperability. The LeanREA test instead raises a narrower engineering question: if the agent already has a shell and the relevant tools, is another abstraction layer the fastest way to reach the answer?

LeanREA vs REA benchmark results at a glance

According to LeanREA’s public repository and the accompanying video, the benchmark used Claude Code in headless mode with Sonnet 5.5 on macOS arm64. It compared three configurations across four reverse-engineering tasks, with each task run three times:

1. No skill, no MCP: the model used its ordinary environment and shell tools.
2. LeanREA: the model received the lightweight skill instructions.
3. REA: the model used REA’s MCP server plus its official skill material.

The four tasks covered an Electron application, a native addon, a stripped Go binary, and a deeper disassembly investigation. The reported aggregate results were:

Against REA, LeanREA’s reported outcome was 38% lower wall-clock time, 35% lower cost, 56% fewer turns, and 60% fewer tokens, while losing only one point in the evaluation. The reported miss involved naming an older version of an IPC channel when both the older and newer channels were present.

Those are striking results, but they need the right interpretation. This was not a large-scale, independently replicated study across providers, operating systems, models, or task categories. It was a 36-run benchmark: four tasks, three repetitions, three configurations, on one machine and one model. The creator also notes that some reverse-engineering utilities, including Ghidra and JADX, were not installed for the test environment.

That limitation does not invalidate the findings. It simply means the most defensible conclusion is narrower: for these tasks, in this environment, a short command-routing skill was more efficient than a broad MCP implementation. It is an important signal, not a universal performance law.

Why fewer turns matter more than they seem

The headline metrics—seconds and dollars—are easy to understand. The turn count is arguably the more useful metric for people designing agent workflows.

A turn is not just a line in a log. In an agent loop, each additional turn can mean the model has to decide which tool to select, form the call, wait for a result, interpret that result, recover from a vague or oversized output, and choose the next step. That creates latency even when individual commands execute quickly.

The LeanREA approach attempts to collapse exploratory loops into purposeful shell calls. Instead of asking an agent to discover an appropriate tool from a broad catalog and then interpret a custom response format, it gives the agent a known first move. For a native binary, for example, a compact command sequence can collect linked libraries, exported symbols, imported symbols, strings, and function listings in one pass.

That is a generalizable pattern for agent builders:

• Combine related read-only checks into a single command when the output remains readable.
• Use a routing table when the target type predicts the best diagnostic path.
• Give the model decision rules before it begins searching.
• Avoid tool outputs so large that the agent must spend later turns reopening, filtering, or summarizing them.
• Treat every tool call as both a latency cost and a context-management event.

The value is not merely speed. Fewer turns reduce opportunities for the model to drift into an irrelevant branch, choose an overpowered tool for a simple task, or make an ungrounded leap after being overwhelmed by output. In a production coding workflow, this can make results feel more predictable even before it makes them cheaper.

The real bottleneck: context and tool discovery

The most provocative part of the LeanREA vs REA test concerns startup context. The creator measured the token use associated with a simple instruction to reply with “okay.” In the reported setup, LeanREA added only a modest amount of context over the base Claude Code prompt. REA was also relatively restrained when Claude Code’s deferred tool-search behavior was enabled.

But when tool search was disabled and the full MCP tool catalog loaded up front, the reported prompt usage jumped dramatically: roughly 400,000 tokens for a trivial response, with a stated cost of $1.60. LeanREA’s repository attributes this to the cost of exposing 207 tools and their definitions to the model all at once.

This does not mean every MCP host behaves this way. In fact, the distinction is crucial. Modern MCP implementations can support tool discovery, caching, deterministic ordering, and deferred loading patterns. The MCP specification explicitly recognizes that clients discover and invoke tools, while recent protocol work has emphasized cacheable tool-list results. A well-designed client can mitigate catalog overhead substantially.

Still, the benchmark identifies a real architectural risk: tool count is not a neutral number. A tool can impose costs before it is ever called.

Tool bloat has three separate costs

When teams debate whether to add another tool, they often focus only on execution cost. There are at least three other costs to consider.

1. Prompt and context cost

Tool descriptions, parameter schemas, examples, and usage rules may consume context. Even if prompt caching reduces marginal cost, larger catalogs make it harder to preserve space for the actual artifact, logs, source code, or user request that the agent needs to reason about.

2. Selection cost

A model must distinguish among overlapping choices. A catalog containing separate commands for inspecting metadata, dependencies, symbols, strings, bundle contents, decompilation, and tracing can be helpful—but it can also force the agent into a planning problem before it begins the investigation.

3. Output-shaping cost

Wrapper tools frequently return structured but verbose objects. Structure is valuable when downstream systems need it. But for an agent trying to answer one precise question, a small grep result or a direct go version -m output may be easier to reason over than a giant JSON response.

The LeanREA test’s Electron example illustrates the third point. The creator reports that the REA path initially hit an integrity issue, then produced a very large JSON result after an additional flag was used. The lean path extracted the archive and searched it with ripgrep, returning a small result containing the needed evidence. That is not a criticism of structured output itself; it is a reminder that output format should match the decision the agent needs to make next.

The core LeanREA idea: instruction compression

LeanREA’s central innovation is not a novel reverse-engineering engine. It is instruction compression.

The skill reportedly maps target categories to direct commands, keeps only the quickest practical option for common cases, and retains a handful of domain-specific tricks discovered by examining REA’s implementation. It covers Electron apps, minified bundles, macOS, Linux, and Windows binaries, Go, Rust, .NET, Android packages, Flutter artifacts, WebAssembly, SQLite databases, packet captures, firmware, and websites.

This is a different kind of product thinking. Instead of asking, “What functions should the agent be able to call?” it asks, “What does the agent need to remember before calling tools it already has?”

A strong agent skill can contain four high-leverage elements:

A target router

The agent first determines what it is looking at: archive, executable, bundle, APK, database, capture file, or website. The skill then routes it to an appropriate first command. This eliminates a large portion of vague exploration.

Ready-to-run reconnaissance commands

These should be safe, read-only, compact, and designed to return several useful observations at once. The point is not to automate every conclusion; it is to rapidly establish the facts needed for the next decision.

Edge-case notes

This is where compact skills can outperform generic model behavior. The video identifies examples such as Electron fuse inspection, locating Go build information, and finding a Flutter snapshot hash. These are details a capable model may know imperfectly, forget, or fail to prioritize at the right moment.

Evidence labels

LeanREA reportedly instructs the model to label findings as seen, inferred, or unknown. That small rule is especially valuable. It counteracts a common failure mode in AI-assisted technical analysis: treating an absence of evidence as evidence of absence.

For engineers, this is the broader takeaway: the best instruction files do not just describe commands. They govern epistemics. They tell the agent what counts as proof, when to state uncertainty, and when not to overclaim.

What the results do—and do not—say about MCP

It would be a mistake to turn this benchmark into a verdict against MCP servers. MCP solves problems LeanREA does not attempt to solve.

A standardized server interface can be valuable when a team needs shared access to remote systems, controlled credentials, auditability, permissions, typed inputs, managed installation, reusable workflows, or tools that cannot reasonably exist as local shell commands. An organization may need an agent to query a private code intelligence system, open a ticket, inspect a cloud environment, or retrieve data from an internal database. A skill file alone is not a substitute for those integrations.

REA itself also has advantages that a compact skill may not replicate:

• A broad, packaged workflow is easier for newcomers who do not know which local utilities are required.
• A dedicated tool surface can normalize behavior across machines and team members.
• Structured outputs may be easier to consume in automated pipelines.
• Comprehensive coverage matters when investigations move beyond common command-line paths.
• A mature toolkit can encode years of edge cases that have not yet made it into a lean instruction file.

The appropriate conclusion is therefore not “replace every MCP server with a markdown file.” It is: do not build an MCP server merely to wrap commands that the agent can already execute reliably.

If the server adds unique capability, governance, portability, safe access to remote data, or robust structured analysis, it can be worth the overhead. If it mainly introduces a new name and wrapper around a local command, a focused skill may be a better starting point.

A fair reading of the LeanREA benchmark

The video is unusually candid about its own limitations, and that candor improves the value of the comparison.

First, the plain “no skill” setup performed well. Its cost was nearly the same as LeanREA’s in the reported data. LeanREA was faster and used fewer turns, but the benchmark does not show that every developer must add a skill to get useful reverse-engineering assistance. Modern models can often reason effectively with standard shell utilities.

Second, REA achieved the top accuracy score in the test. LeanREA was close, but not identical. For situations where a missed detail is expensive—security review, forensic work, interoperability analysis, or a difficult unfamiliar artifact—a richer workflow may justify its additional cost.

Third, not all tools were available in the test environment. A system that can use Ghidra, JADX, Hopper, or other specialized analyzers may behave differently on tasks that truly need those packages. An abstraction layer may become more useful as the environment becomes more complex.

Fourth, the benchmark used hand-made answer keys. That is a reasonable approach for a practical test, but it makes external replication important. The repository includes benchmark materials and raw metrics, which is the right direction. Teams evaluating either approach should reproduce tests against their own artifacts, platforms, policies, and agent models.

A good evaluation plan would measure more than speed:

1. Accuracy: Did the agent identify the correct function, protocol, dependency, or code path?
2. Evidence quality: Can a reviewer retrace each important claim to a command output or artifact?
3. Latency: How long until the first useful answer and final answer?
4. Cost: What are the model, tool, and operational costs per investigation?
5. Reliability: How often does the workflow fail, refuse, time out, or need human recovery?
6. Setup burden: How much installation, maintenance, and platform-specific configuration is required?
7. Safety and authorization: Can the workflow prevent destructive actions and keep investigators within approved scope?

Small skills still need testing and maintenance

One of the best practical lessons from the source is that small does not mean flawless. During testing, the LeanREA creator found two bugs in the initial instructions.

The first involved ripgrep. By default, ripgrep can skip hidden paths, and some Electron applications place relevant code inside a hidden .webpack directory. A search that appears to find nothing may therefore be incomplete. The updated guidance reportedly uses a more permissive ripgrep invocation for this situation.

The second involved shell compatibility. A marker string used in a command behaved differently under zsh, the default shell on many Macs, causing a failure until it was quoted. This is a familiar operational lesson: shell snippets are software. They need tests across the shells, platforms, permissions, and file layouts the team actually supports.

For teams creating their own skills, treat the file as a versioned production asset rather than a prompt you write once and forget. A practical maintenance checklist includes:

• Test every command on supported operating systems and default shells.
• Check behavior on paths containing spaces, unusual characters, and hidden directories.
• Ensure read-only inspection commands do not mutate customer or production artifacts.
• Pin or document external tool requirements and minimum versions.
• Keep a small regression corpus of known files and expected findings.
• Log commands and evidence references where policy permits.
• Add explicit “unknown” and escalation paths for ambiguous results.

The smaller the skill, the easier it is for an engineer to audit. That is one of LeanREA’s strongest arguments. A compact file can be reviewed line by line, edited quickly, and understood by the people who will depend on it.

Designing better agent skills for developers

You do not need to be building a reverse-engineering assistant to apply this pattern. The same approach works for debugging, codebase onboarding, incident response, SEO audits, data analysis, QA, and developer support.

Start by identifying the recurring decision points where agents waste time. In many workflows, the agent already has access to the commands, APIs, or files it needs. What it lacks is a concise strategy for choosing the right first action.

Use a “first moves” section

Give the agent a handful of reliable opening actions based on artifact type or user intent. For a repository issue, that could mean reading the relevant error output, locating the owning package, checking recent changes, and running the smallest targeted test. For a performance investigation, it could mean collecting a baseline, identifying the slowest path, and comparing before-and-after measurements.

Make the decision tree explicit

Do not force the model to infer your team’s preferred workflow from scattered documentation. State it plainly: if condition A is true, run check B; if the output contains C, inspect D; if the result is inconclusive, label it unknown and request the missing artifact.

Separate discovery from explanation

Tell the agent to collect evidence before producing a narrative. This reduces polished but unsupported answers. It also makes reviews easier because the evidence and inference steps are visible.

Prefer narrow outputs early

Huge command output is not inherently more useful. Early steps should answer focused questions that determine the next branch. Retrieve the complete artifact only when the investigation actually requires it.

Preserve an escape hatch

Lean workflows should not become rigid workflows. The skill needs a clear rule for escalation: when direct commands do not establish the answer, invoke a deeper analyzer, ask the user for authorization or context, or hand the case to a human specialist.

This is how a small skill avoids becoming simplistic. It does not pretend to solve every case; it gets routine cases to the right evidence quickly and recognizes when the routine path has ended.

Implications for AI tool builders and SaaS teams

For founders and product teams, LeanREA vs REA is a reminder that agent UX is often an information architecture problem before it is a model problem.

An impressive tool count can look like product depth. But users measure outcomes: how quickly the agent gets to a correct answer, whether they can trust the answer, how much it costs, and whether the workflow makes sense when something goes wrong. A concise, well-scoped layer can outperform a feature-rich system if it eliminates unnecessary planning and context handling.

This has several product implications:

• Market outcomes, not tool inventory. “207 tools” may communicate scope, but “trace an Electron feature to evidence in under a minute” communicates value.
• Instrument the agent loop. Track tool selection, redundant calls, output size, recovery turns, time to first evidence, and human correction rate.
• Make defaults progressive. Start agents with a small capability set and expose deeper options only when task signals demand them.
• Build for observability. Users need to see what command ran, what it returned, and which conclusion was inferred.
• Optimize for the common 80%. A compact default workflow can handle ordinary tasks while a richer system remains available for specialist cases.

There is also a cost-management angle. Token costs are only part of the bill. Slow, circuitous agent behavior can increase user waiting time, raise support burden, and reduce confidence in automation. In an AI product, perceived intelligence is often closely tied to decisiveness: the system should know the next sensible move without performing an elaborate ceremony first.

The broader trend: progressive disclosure for agents

The LeanREA debate fits a growing pattern in agent design: progressive disclosure. Give the model the smallest amount of capability and instruction necessary for the current stage, then expand only when the task requires it.

MCP itself is evolving in ways that can support this pattern. Its tooling model allows clients to discover available tools, and the protocol’s emphasis on cacheable lists and standardized interfaces gives implementers room to avoid repeatedly shoving an entire catalog into active context. The protocol is not the problem; indiscriminate exposure is.

For reverse engineering, progressive disclosure might mean:

1. Identify the file type.
2. Run a compact, read-only inventory command.
3. Search for the exact feature, symbol, endpoint, or string relevant to the question.
4. Escalate to decompilation or disassembly only if the initial evidence is insufficient.
5. Use specialized tooling only when the artifact and question justify it.

That sequence is not glamorous, but it is good operational design. It reflects how experienced analysts work: start with the cheapest, highest-signal observation and spend more effort only after the evidence points somewhere specific.

When to choose LeanREA, REA, or a hybrid approach

The right choice depends on the investigation and the environment.

Choose a LeanREA-style skill when:

• Your agent already has a reliable shell and local toolchain.
• Your team repeatedly analyzes a known set of artifact types.
• Low latency, low token use, and inspectable instructions matter.
• You want a workflow engineers can fully audit and modify.
• Most tasks are reconnaissance, feature tracing, metadata extraction, or targeted search.

Choose a fuller REA-style platform when:

• Your users need guided setup and broad capability without learning system tools.
• The work regularly requires specialized analyzers and integrated workflows.
• Structured results, portability, and standardized tool calls matter more than minimal overhead.
• You are handling diverse artifact types across varied developer environments.
• A shared team platform needs controlled configuration and repeatable operations.

Choose a hybrid when:

• A small skill handles initial triage and routine cases.
• The agent escalates to MCP tools only for tasks that need deeper analysis.
• You can defer loading large tool definitions until the agent has identified the target type.
• You want the auditability of direct commands alongside the reach of specialized integrations.

For many teams, the hybrid will be the strongest answer. The point is not to choose minimalism as an ideology. It is to make every capability earn its place in the agent’s active workflow.

Conclusion: better instructions can beat more integrations

The LeanREA vs REA benchmark should be treated as a useful engineering case study, not a final scoreboard for reverse-engineering agents. REA remains a substantial project aimed at giving coding agents broad investigative capabilities, while LeanREA demonstrates that many common tasks can be routed through a much smaller set of instructions and native commands.

The important result is conceptual. A capable model plus the right command-line access may not need hundreds of bespoke tool definitions to perform well. It may need a compact router, high-signal first moves, a few hard-won implementation notes, and strict rules about what counts as evidence.

For builders, that is an encouraging message. Before adding another server, function, wrapper, or tool schema, ask a simpler question: does this give the agent a genuinely new capability, or does it only make an existing capability harder to discover and more expensive to use?

FAQ

What is the main difference between LeanREA and REA?

REA is a broad reverse-engineering toolkit delivered through MCP and CLI workflows, while LeanREA is a small skill file that routes an agent toward direct shell commands and target-specific notes. LeanREA aims to avoid an extra tool layer when the underlying utilities are already available locally.

Is LeanREA proven to be better than REA?

Not universally. LeanREA’s public benchmark reports faster and cheaper performance with near-identical accuracy across four tasks, but it used one model, one machine, and three runs per test condition. Teams should replicate the comparison on their own artifacts and workflow requirements.

Does this mean MCP servers are inefficient?

No. MCP servers are useful for standardized integrations, remote systems, permissions, shared tooling, structured outputs, and capabilities that a local shell cannot provide. The lesson is to avoid loading or wrapping tools unnecessarily.

Why do fewer agent turns matter?

Each turn adds model reasoning, tool-selection, execution, and result-interpretation overhead. Reducing unnecessary turns can lower latency, token consumption, cost, and the chance that an agent gets distracted by irrelevant output.

Can the LeanREA approach apply outside reverse engineering?

Yes. The same design works for debugging, incident response, repository onboarding, QA, analytics, and marketing operations. Build a concise decision tree, provide high-signal first actions, require evidence labels, and escalate to heavier tools only when the task demands them.