r2ai: LLM prompts and function calling wired into the radare2 shell
LLM-based reversing for radare2
At a glance
- What is it?
- r2ai is a radare2 plugin that adds an r2ai command for talking to local or remote language models from inside the disassembler, plus a second plugin called decai aimed at decompilation. The design bets that keeping the model one command away from your analysis session beats exporting context to a chat window.
- Who is it for?
- Adopt r2ai if you already drive radare2 from its prompt or via r2pipe and want model output attached to the current function rather than pasted into a separate chat. Skip it if your workflow lives in Ghidra or IDA, or if you cannot send binary-derived context to a remote provider and have no local ollama instance to point it at.
- 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 9 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 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap r2ai fills between the disassembler and the model
Reversing with an LLM usually means copying a function out of your disassembler, pasting it into a browser tab or a CLI client, and copying the answer back. Context is lost at every hop, and the model never sees the surrounding session state. r2ai is a native radare2 plugin that adds an r2ai command to the radare2 shell, so the prompt runs where the analysis already is. The README describes the intended audience indirectly through its feature list: configure different roles and customize prompts, script it via r2pipe through the r2ai command, and use it live in a repl or batch mode from the CLI or the r2 prompt. There is also a wrapper you can run from $PATH with r2pm -r r2ai, which matters if you want the plugin outside an interactive session. The second component in the repository, decai, is an r2js plugin with what the README calls special focus on decompilation, so the project covers two entry points: a general prompt-and-answer plugin and a decompilation-oriented one.
Roles, ReAct mode, and a native vector database
The mechanism is a set of named roles rather than a single free-form prompt. Running r2ai -q lists them: explain, devices, libs, varnames, autoname, vulns, signature, dlopen, and decompile. Several of these read as prompt templates bound to the current function, which is why the explain role is described as Explain the current function and autoname as Automatically suggest a better name for this function. The README also documents an Automatic (ReAct) mode that solves tasks using function calling, which is the more consequential feature: instead of the model only producing text, it can invoke tools. A separate feature list item says the plugin can embed the output of an r2 command and resolve questions on the given data, and another says it can do RAG over markdown, code, or text files using its own native vector database. That last point is worth pausing on. Bundling a vector database into a C plugin means the retrieval index lives inside the tool rather than in a Python sidecar, which keeps the dependency surface small but also means the indexing and retrieval behaviour is the project's own, not a library you can swap out. The README does not describe chunking, embedding model choice, or index persistence, so those are open questions rather than documented behaviour.
Installation, keys, and where settings actually live
The recommended install path is the radare2 package manager, and the README gives two commands: r2pm -Uci r2ai for the native plugin and r2pm -Uci decai for the r2js decompilation plugin. The CI badge in the README references radare2 6.0.4, which is the version the project tests against. Keys go either into environment variables or into a configuration file. The README shows ANTHROPIC_API_KEY and OPENAI_API_KEY as environment variables, and names ~/.config/r2ai/apikeys.txt as the file alternative, opened for editing with r2ai -K. Settings are handled differently from keys: r2ai -E is the command that lets you customize and save configuration into your OS default settings file, with ~/.radare2rc on Linux given as the example. The README's worked example sets Claude 3.7 as the default with a large output budget, expressed as three commands to place in that file: r2ai -e api=anthropic, r2ai -e model=claude-3-7-sonnet-20250219, and r2ai -e max_tokens=64000. Note the shape of that: api and model are separate keys, so switching providers is a two-line edit rather than a reinstall. The feature list names ollama, openai, grok, and anthropic as supported backends.
What the README does not tell you
The documentation is thin in places that matter for a tool that sends binary-derived text to a third party. There is no description of what leaves your machine for each role, no token accounting, and no statement about whether function context is truncated before it is sent. The RAG feature is listed but not specified: no supported file types beyond markdown, code, and text, no index format, no explanation of how the vector database is built or where it is stored. The ReAct mode is described in one line about function calling, with no list of which tools the model can call or what guardrails exist when it does. Error handling is likewise undocumented. If a role returns an empty answer, the README gives no way to distinguish a provider failure from a prompt that did not fit the model. None of this is disqualifying, but it means the first hour with r2ai is exploratory rather than procedural, and you should expect to read the src/README.md and decai/README.md files that the top-level README points to for the parts it omits.
The wrong tool, and a real alternative
r2ai is the wrong choice if your reversing happens outside radare2. The plugin is loaded by the radare2 shell, so a Ghidra or IDA user gets nothing from it, and the r2pipe scripting path assumes you are already driving radare2 programmatically. It is also a poor fit if policy forbids sending disassembly to a remote provider and you have no local model: the feature list includes ollama, so a local path exists, but the README's own configuration example points at a hosted Anthropic model, and nothing in the material describes running fully offline end to end. The closest alternative named in the README is r2copilot, described as an MCP with a focus on CTF, alongside r2mcp, which the README calls the official radare2 MCP. The difference in approach is architectural rather than cosmetic. r2mcp and r2copilot expose radare2 as a tool server that an external agent drives over MCP, so the model loop lives in the agent and radare2 is a capability it calls. r2ai inverts that: the model loop lives inside the radare2 session, and the r2ai command is the interface. If you want an autonomous agent orchestrating many tools, the MCP route fits better. If you want a prompt answered against the function you are currently looking at, without leaving the prompt, r2ai is the shorter path. The README also lists r2agent for autonomous radare2 workflows, which sits on the agent side of that same split.
Maintenance surface and licence
The plugin tracks radare2 itself, and the README's CI badge pins the tested version at 6.0.4, so a radare2 upgrade is the event most likely to break your install. That is a normal cost for a native plugin, but it is a real one: r2pm -Uci r2ai is the upgrade command, and re-running it after a radare2 bump is the cheap insurance. The second cost is provider drift. Model identifiers appear in configuration, and the README's example uses claude-3-7-sonnet-20250219, a dated model string that will eventually stop resolving. Because api and model are separate settings, updating is a one-line edit in ~/.radare2rc, but nothing in the material suggests the project tracks provider deprecations for you. The repository is MIT licensed, which is permissive and imposes no copyleft obligation on your own code; that is a statement about the licence text, not legal advice, and if you are redistributing r2ai inside a product you should read the licence and any provider terms yourself. The API keys you configure are a separate matter entirely, governed by whichever provider you point api at.
Who should install it
Install r2ai if radare2 is already your disassembler and you want model output bound to the current function through named roles rather than pasted between windows. The presence of ollama in the backend list makes a local-only setup plausible, and the native vector database means RAG does not require a Python environment. Do not install it if your analysis runs in another disassembler, or if the idea of binary-derived context leaving the machine is a blocker and you have no local model to substitute. The first thing to verify after r2pm -Uci r2ai is not the install but the roles: run r2ai -q, pick explain and autoname against a function you already understand, and check whether the answers are grounded in the disassembly or generic. That single test tells you more about fit than any feature list, because a role that returns plausible-sounding text unrelated to the actual code is the failure mode this design is most exposed to.
Editorial conclusion
Adopt r2ai if you already drive radare2 from its prompt or via r2pipe and want model output attached to the current function rather than pasted into a separate chat. Skip it if your workflow lives in Ghidra or IDA, or if you cannot send binary-derived context to a remote provider and have no local ollama instance to point it at. Before installing, run r2pm -Uci r2ai on a radare2 6.0.4 build and confirm which prompt roles (explain, autoname, vulns, decompile) actually fire against your chosen model, because a role that returns nothing useful is indistinguishable from a model that cannot do the task.
Community notes