Eleven puts an ACP agent inside a reverse-engineering workbench, with you approving every change

The agent reads the disassembly, not your paste buffer

Eleven is described as an agent-first reverse-engineering app for macOS, Windows and Linux, and the design goal is stated plainly: drop in an app, a binary, an Android APK, a GPU kernel, a shader or a model and ask what it does.

The mechanism is the Agent Client Protocol. Any agent that speaks ACP can read the code, follow references, rename functions, leave notes and suggest patches, while you watch and approve in the same window.

That last clause is the whole design. This is not a chat interface with a code panel attached. The agent drives the application itself. Eleven serves its own MCP tools so an agent can open a function, switch views, rename, add notes, change types and propose patches. The agent is a first-class participant in the workbench rather than a bystander you paste screenshots for.

The feature list names the agents explicitly: Aster, Claude, Codex, Gemini, Cursor, Copilot, OpenCode and any other ACP agent, and you can run several on the same project, each in its own chat. Bring your own agent is the framing.

There is also a selection flow for the reverse engineering itself. Select lines in pseudocode, assembly or a source file and ask, explain or copy them. The answer opens under the lines, and a suggested rename arrives as a card you accept or decline.

The last piece of the model is trust. Every change by you or an agent is logged with its author and can be undone, and byte patches from agents arrive as suggestions you accept or decline.

The project is Apache-2.0 licensed with a THIRD_PARTY_NOTICES.md at the root, the primary language is TypeScript, and the homepage is eleven.chizi.app. The last push was on 2026-10-19.

Which decompiler reads which format

The engine choice is not cosmetic, and the README is direct about the trade.

Native code is read by Ghidra through REA, or by Rizin when you want files to open in seconds. The install section puts it the same way: Rizin opens most apps in seconds, while Ghidra 12.x with Java 21 is slower and gives the clearest pseudocode.

That is a genuine engineering choice rather than a preference. Rizin gets you to a first look quickly, Ghidra's decompiler output is the one you would trust when reading logic. A project that supports both, and lets you pick per session, is solving the real problem that the two tools answer different questions.

Android apps are read by jadx. An APK opens with Java from jadx, smali from apktool when it is installed, plus string resources, and the manifest, res, assets and native libraries in a Resources list. Split bundles such as .xapk and .apks open with every split in place, which is the detail that matters for anyone who has tried to open a modern Android app and found it half empty.

The binary formats covered are Mach-O, ELF and PE, with functions, pseudocode, assembly, control-flow graph, cross-references, strings, segments and hex. You can change a line's type, whether it is code, procedure, data or string, and the number format, using Hopper's keys.

There is also a source reconstruction path. Eleven finds the source files a binary was built from, reads Swift types straight from the binary, and has your agent recreate a whole file with each function linked back to its address.

That last capability is where the agent earns its place. Reading a decompiler's guess is one thing; having an agent rewrite a function in the language it was probably written in, with the addresses still attached, is a different job.

Beyond native code: shaders, models, kernels and diffs

The scope goes past the usual disassembler features, and this is where the project gets its topic tags.

GPU kernels are covered: CUDA and HIP fat binaries open as highlighted PTX, with notes beside each block and rewrites in CUDA C++, HIP C++ or Metal. Shaders and models open in the workbench too, with Metal shaders and ML model files in GGUF, safetensors, PyTorch and ONNX format linked to the code that loads them. The README says you can profile with Instruments.

Rewriting a function in another language is a general feature rather than a GPU one. You can show a function's pseudocode rewritten by your agent in C, C++, Rust, Go, Swift, Python, TypeScript, Java, C# or Zig. Ten target languages from one button, with the original still on screen.

Diffing compares two builds by function and reads the changes like a code review. That is the feature that turns the tool from an inspector into something you can use on a regression, where the question is not what does this function do but what changed between the last release and this one.

Debugging runs a program under LLDB, lets you break on the function you are looking at, step and read locals. The environment table shows the variable ELEVEN_LLDB_DAP and a note that it is for lldb-dap for the debugger.

Playbooks are described as built-in skills such as first look, name functions, trace a feature and network map, and they work with any agent. The naming gives you a sense of what an agent session on this app looks like in practice.

Export covers pseudocode, assembly, control-flow graphs as PDF and Objective-C class inventories.

Projects save to one .eleven file

The project model is small and worth understanding, because it is what makes the agent arrangement coherent.

A project is one app or binary, and it holds its chats, agents, renames, bookmarks, notes and patches. Press the shortcut to save it as a single .eleven file you can share. The README is explicit that nothing is written there until you do.

That last sentence matters more than it first appears. An agent that can rename functions and propose byte patches is working on a shared artefact, and the alternative to a project file is loose notes scattered across a chat history. One file per binary means a colleague can open it, see the renames, the notes and the patch proposals with their authors attached, and decide what to take.

The three related mechanisms reinforce each other. Patching edits bytes at an address and writes a patched copy, and the original is never touched. Diffing compares two builds by function. Every change is logged with its author and can be undone.

That combination is what makes the approve-and-decline flow in the rest of the app safe enough to use. An agent rename arrives as a card, you accept or decline it, and the accept is a logged change you can undo. An agent byte patch arrives as a suggestion and the original file is never modified. The design assumes the agent will occasionally be wrong, and puts the cost of being wrong on a click rather than on a git revert.

The support section says Eleven is free and built by one person, that sponsoring on GitHub pays for notarized builds, a Linux release and the debugger.

Installing it, and what first run does for you

The install section is per platform, and each platform has a caveat.

On macOS 14 or later on Apple Silicon, one command.

curl -fsSL https://eleven.chizi.app/install.sh | bash

That installs Eleven.app into /Applications. The README notes that builds are not notarized yet, so the installer clears the download quarantine for you. That is worth understanding rather than glossing over: an unnotarized build is one macOS will refuse to open normally, and the workaround is that the installer removes the quarantine attribute that triggers the warning. On a managed machine that permission change may not be available to you.

On Windows x64, in PowerShell.

irm https://eleven.chizi.app/install.ps1 | iex

On Linux x64, you download the AppImage or the tar.gz from the latest release.

On first run the app walks you through picking an engine and an agent, and installs what is missing. Ghidra 12.x with Java 21 is downloaded, or copies already present in ~/.local/share, ~/Applications or GHIDRA_INSTALL_DIR are used. ACP adapters are installed when they are needed. Android apps additionally need jadx, and apktool is optional and adds smali.

So a first run pulls a decompiler, a JDK and possibly an agent runtime. That is a heavy first-run cost, and it is why the project also documents a from-source path with Bun, Node 20 or newer, Ghidra and a JDK, plus a checkout of REA 6.x next to the repository or ELEVEN_REA pointing at one.

git clone https://github.com/Zfinix/eleven
git clone https://github.com/Zfinix/rea
cd eleven/app
bun install
bun run dev

Where Eleven is the wrong tool

The first limitation is the maturity of the release line. The versions are 0.1.7, 0.1.8 and 0.1.9, all published on 2026-10-16 within hours of each other, and the current version is 0.1.9. A 0.1.x tool in October 2026 is a project in the early part of its life, whatever the pace of commits suggests, and an application whose releases can ship three versions in one day has no stable upgrade path for a production workflow.

The second is that it is a desktop workbench, not a pipeline. Everything here is interactive: you open a binary, you look at it, you ask about it. There is no documented batch mode, no CI integration and no scripting interface, so if your task is to run the same analysis over four hundred binaries, this is not the tool.

The third is the dependency on the platform. macOS 14 on Apple Silicon only for the installer, and a Linux release that the README lists as something sponsorship pays for. A reverse engineering team working across three operating systems will find the Windows and Linux paths less polished than the macOS one.

The fourth is the not-yet-notarized build. On macOS that is a visible warning, and for an organisation with a managed device estate it may be a policy problem rather than an annoyance.

The fifth is that an agent with rename and patch authority is still an agent. The approve-and-decline design limits the damage, but the quality of what you get back depends on the model you bring, and the README says nothing about how to evaluate an agent's suggestions at scale.

How it compares with Hopper, Ghidra and the chat window

The comparison everyone will make is with the commercial tools and with the alternative of using a decompiler and an agent separately.

Against Hopper and Ghidra on their own, Eleven is not trying to replace the decompiler. It drives Ghidra through REA and offers Rizin as a faster alternative, and the feature list mentions Hopper's keys for changing a line's type and number format. The value it adds is the agent layer and the project file: renames that arrive as reviewable cards, notes attached to addresses, and a single file that carries the analysis of a binary to a colleague.

Against the pattern of pasting pseudocode into a chat window, the difference is the round trip. In a chat, the pseudocode leaves your screen, the answer comes back as text with no link to the address, and applying a rename means editing a list by hand. In Eleven, the agent is inside the application and holds a reference to the function it is talking about, so a rename is a change to the project rather than a suggestion you reimplement.

The third alternative is to script it yourself. Ghidra has a headless mode and scripting support, and jadx has a command line. That route gives you repeatability and CI integration, which Eleven does not offer, at the cost of building the agent loop, the diff view and the patch review yourself.

The honest summary is that Eleven optimises for the interactive session with an agent in the room. If your work is one binary at a time with a human in the loop, it is a better fit than a script. If your work is a pipeline over many binaries, the headless tools are the better fit and Eleven is the wrong shape.

Editorial conclusion

Eleven fits a reverse engineer who wants to keep their agent inside the disassembler rather than pasting pseudocode into a chat window, and who wants the agent's renames, notes and byte patches to arrive as proposals inside a log they can undo. It does not fit a team that needs a reproducible toolchain, since the version line is still 0.1.x with releases on consecutive days in October 2026, and it does not fit anyone who wants a static analysis pipeline rather than an interactive workbench. Before adopting, read the install section for the platform, because the macOS build is not notarized yet and the installer clears the quarantine for you, decide which engine you will rely on, since Rizin and Ghidra give very different pseudocode, and check the environment table so your Ghidra, REA, Rizin, jadx and LLDB paths are the ones the app uses rather than the ones it finds.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. Zfinix/eleven on GitHub