r2ai: LLM-assisted reversing inside the radare2 shell
LLM-based reversing for radare2
At a glance
- What is it?
- r2ai is an MIT-licensed radare2 plugin that puts a language model behind an r2 command, so you can ask about the function you are already looking at. It installs through r2pm, and its value depends on how much of the analysis you are willing to hand to a model.
- Who is it for?
- Adopt r2ai if you already work inside radare2 and want model output attached to the function under the cursor, with local models via ollama or a remote provider. Skip it if you need a self-contained decompiler or cannot send binary context to a third party.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 23 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The gap r2ai fills in a radare2 session
Static analysis in radare2 produces names, signatures and control flow, but it does not produce prose. A reversing session is full of small interpretive questions: what does this function do, which libraries do these imports belong to, would a better variable name make this readable, does this loop look like a vulnerability. Today those questions get answered by the analyst, in their head or in a separate notes file.
r2ai is for the analyst who wants a model to answer them without leaving the shell. The README describes it as an AI plugin for radare2, with a companion r2js plugin called decai that focuses on decompilation. Both live in the same repository, so installation and versioning are shared. The intended user is not someone who wants an autonomous agent that drives radare2 on its own. The README points elsewhere for that, naming r2agent for autonomous workflows, r2mcp as the official radare2 MCP server, and r2copilot for CTF-focused MCP use. r2ai is the in-shell, human-in-the-loop option.
How the plugin connects a model to the current function
The mechanism is a new r2ai command inside the radare2 shell. The README states that the plugin adds this command and that it can also be run as a wrapper in $PATH through r2pm -r r2ai. Prompts are named and user definable, and the README lists the built-in set: explain, devices, libs, varnames, autoname, vulns, signature, dlopen and decompile. Each name maps to a task, and the listing shows the trailing dash as the place where the current function or context is substituted.
Two data paths matter. The first is context: the plugin can embed the output of an r2 command and resolve questions on that data, which is how a prompt ends up grounded in disassembly rather than in the model's memory. The second is retrieval: the README describes RAG over markdown, code or text files using a native vector database, so you can point the model at documentation or source alongside the binary.
The README also documents an automatic ReAct mode that solves tasks through function calling. That is the closest the project gets to agent behaviour, and it is opt-in rather than the default interaction. Model choice is a configuration value, not a hardcoded dependency: the README lists local and remote options including ollama, openai, grok and anthropic.
Installing r2ai with r2pm and asking a first question
The README calls r2pm the recommended installation path. Both plugins install from the same package manager, and the -Uci flags update the package index and install in one step. Run these in a shell where radare2 is already available.
$ r2pm -Uci r2ai
$ r2pm -Uci decaiAfter installation the r2ai command exists inside the radare2 shell. The README gives this one-liner as the way to invoke it without entering the interactive prompt:
$ r2 -qc r2aiYou can also call the wrapper directly from $PATH, which the README documents as:
$ r2pm -r r2aiBefore any prompt will work you need credentials for a remote provider, or a local model. The README shows environment variables for two providers:
$ export ANTHROPIC_API_KEY=sk-ant-api03-CENSORED
$ export OPENAI_API_KEY=sk-proj-6rlSPS-zN1v...Keys can instead be stored in the api keys file at ~/.config/r2ai/apikeys.txt. The README says to run r2ai -K to edit that file.
Settings can be saved so they load with the plugin. The README recommends the OS default settings file, for example ~/.radare2rc on Linux, and gives r2ai -E as the command that writes the configuration. The example it provides selects Claude 3.7 and raises the output token limit:
r2ai -e api=anthropic
r2ai -e model=claude-3-7-sonnet-20250219
r2ai -e max_tokens=64000With that in place, the first useful interaction is the prompt list. Typing r2ai -q inside the r2 prompt prints the available prompts and their descriptions, which is how you discover that explain targets the current function and varnames asks for better variable names. Pick the prompt that matches the task rather than asking a free-form question; the prompt list is the interface.
What r2ai does not do, and when to reach for something else
The README is explicit about scope in one direction and silent in another. It is explicit that autonomous agent work belongs to r2agent and that MCP integration belongs to r2mcp or r2copilot. If your goal is a tool that drives radare2 through a long sequence of steps without you, r2ai is the wrong component in this family.
The silence is around operational detail. The README does not document token accounting, cost estimation, or what happens when a provider returns an error mid-session. It does not document rollback for a prompt that produced a bad rename, and it does not describe a review step before a suggested name is applied. Treat generated names and signatures as suggestions to verify, not as analysis results.
A second boundary is data handling. The README lists remote providers alongside ollama, and it documents the api key file, but it does not describe a redaction layer between your binary and the provider. If the artifact is under an NDA or export restriction, that decision is yours to make before the first prompt, not something the plugin resolves for you. The local path through ollama is the option the README offers for keeping inference on your machine, and it is a configuration choice rather than a default.
r2ai against a general-purpose assistant workflow
The obvious alternative is copying a disassembly listing into a chat interface or a coding assistant and asking there. The difference is context assembly. With a chat window you select and paste, and you lose the connection to the live session. With r2ai the context comes from an r2 command whose output the plugin embeds, so the model sees what the session sees, and the answer arrives at the r2 prompt where the next command is typed.
The other credible alternative is the MCP route the README itself names. r2mcp exposes radare2 to external agents, which suits people who already have an agent harness and want radare2 as one of its tools. r2ai inverts that: the model is the guest inside radare2, and the analyst stays in the r2 prompt. If your workflow is built around an external agent, r2mcp is the closer fit. If your workflow is a terminal and a binary, r2ai keeps everything in one place.
Maintenance, licensing and the cost of upgrading
The repository is not archived, and the last push was on 2026-09-06, the same day as the 1.4.4 release. Releases in the visible list run from 1.4.0 on 2026-06-03 through 1.4.2 on 2026-08-16 to 1.4.4 on 2026-09-06, so the cadence over that period is roughly monthly. That is the maintenance picture the repository supports; anything beyond it would be speculation.
The licence is MIT, which is permissive and places few obligations on how you redistribute or embed the plugin. That statement covers the plugin code only. It says nothing about the terms of the model providers the README lists, and it says nothing about what happens to the data you send them. Those are separate agreements between you and each provider, and they are worth reading before you point the plugin at client work.
Upgrade cost is mostly configuration drift. The README shows settings written into ~/.radare2rc and an api keys file at ~/.config/r2ai/apikeys.txt. New releases can change which model identifiers are sensible, and the README's own example pins a dated model name. When you update with r2pm -Uci r2ai, re-check the api and model values in your saved config rather than assuming the old pair still behaves the same way.
Editorial conclusion
Adopt r2ai if you already work inside radare2 and want model output attached to the function under the cursor, with local models via ollama or a remote provider. Skip it if you need a self-contained decompiler or cannot send binary context to a third party. Before relying on it, check which provider and model your saved config selects, and confirm that the prompt you invoke matches the task.
Frequently asked questions
How do I install r2ai?
The README recommends r2pm and gives the command r2pm -Uci r2ai, with r2pm -Uci decai for the decompilation-focused companion plugin. After that, the r2ai command is available inside the radare2 shell.
Which language models can r2ai use?
The README lists local and remote options including ollama, openai, grok and anthropic. The provider is selected with the api setting and the model with the model setting, as in the README's example that sets api=anthropic and model=claude-3-7-sonnet-20250219.
Where does r2ai store API keys and settings?
Keys can be exported as environment variables such as ANTHROPIC_API_KEY or OPENAI_API_KEY, or written to the api keys file at ~/.config/r2ai/apikeys.txt, which the README says to open with r2ai -K. Settings are saved with r2ai -E into your OS default settings file, for example ~/.radare2rc on Linux.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/radareorg-r2ai)