OpenDeRisk: A Multi-Agent RCA Framework Built Around the OpenRCA Dataset
AI-Native Risk Intelligence Systems, OpenDeRisk——Your application system risk intelligent manager provides 7* 24-hour comprehensive and in-depth protection.
At a glance
- What is it?
- OpenDeRisk is an MIT-licensed Python system for root cause analysis that coordinates five named agents over logs, traces, and code. Its stated workflow depends on a roughly 26GB external dataset, and the repository itself notes that only part of the advertised architecture is implemented.
- Who is it for?
- Adopt OpenDeRisk if you want to study or extend a multi-agent RCA pipeline and you are willing to pull the OpenRCA dataset (the README cites a 26GB decompressed size and gives gdown links for the Bank and Telecom subsets). Do not adopt it as a drop-in production incident tool: the README states the code currently implements the highlighted parts of the architecture, and the primary evaluation path runs against a downloaded research dataset rather than your own telemetry.
- 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 12 days ago.
- What is it written in?
- Mainly Python, 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 OpenDeRisk Targets: Root Cause Analysis Without a Fixed Rulebook
Most incident tooling answers a narrow question. A metrics platform tells you a latency percentile moved. A log system tells you an error string appeared. Neither tells you why, and the step between detection and explanation is usually a human reading three systems in parallel. OpenDeRisk is aimed at that step. The README describes it as an AI-Native Risk Intelligence System and an application system's intelligent manager, and the first listed feature is DeepResearch RCA: locating root causes through in-depth analysis of logs, traces, and code. The intended user is an SRE or platform engineer who already has telemetry and wants a system that reasons over it rather than only alerting on it. The topics list (agent, ai-sre, rag, multi-agent-systems, mcp, sre) confirms the framing. This is not an observability backend. It is a reasoning layer that assumes telemetry exists somewhere and that a language model can be pointed at it.
Five Named Agents, One Dataset, and a Visualization Protocol
The architecture is a multi-agent system. The README names five participants: SRE-Agent, Code-Agent, ReportAgent, Vis-Agent, and Data-Agent. The stated division of labour is that they collaborate for deep RCA, with Code-Agent dynamically writing code for final analysis. That last detail matters more than it first appears. Rather than constraining the model to a fixed set of pre-built analysis functions, OpenDeRisk lets an agent generate code at analysis time, which is how it can move from a general question about a trace to a specific computation over that trace. The data flow described in the README has three layers. The data layer pulls the OpenRCA dataset, decompresses it locally, and processes it for analysis. The logic layer runs the agents. The visualization layer uses what the README calls the Vis protocol to render the processing flow, the evidence chain, and the switching between agent roles. The evidence chain visualization is the second listed feature and is presented as a way to make the diagnostic process auditable rather than opaque. Alert awareness, per the README, is based on Microsoft's open-source OpenRCA dataset. One honest sentence in the README is easy to miss: the code primarily implements the highlighted components of the architecture diagram. That is an admission that the diagram is partly aspirational, and it should shape how you read the feature list.
Two Install Paths: A curl Script or uv With Explicit Extras
The recommended install is a single shell command that fetches install.sh from the main branch and pipes it to bash. After it runs, the README says a default configuration file is initialized at ~/.openderisk/configs/derisk-proxy-aliyun.toml, which you edit to set API keys before starting the server with openderisk-server. The source path is more explicit and more useful for judging dependencies. It requires uv, installed via the standard astral.sh script for macOS and Linux or the PowerShell equivalent on Windows. You then clone the repository and run uv sync with --all-packages --frozen and a list of extras: base, proxy_openai, rag, storage_chromadb, derisks, storage_oss2, client, ext_base, and channel_dingtalk. The README flags channel_dingtalk as optional and skippable if you do not need DingTalk. That extra list is a reasonable proxy for the system's shape: a RAG component, ChromaDB for local vector storage, OSS2 for object storage, and an OpenAI-compatible proxy layer. For a zero-configuration start there are three documented options: uv run derisk quickstart, the ./start.sh script, or uv run derisk quickstart -p 8888 to pick a port. The web UI is served at http://localhost:7777. To run against a configuration file instead, the README gives uv run derisk quickstart -c configs/derisk-proxy-aliyun.toml, or the longer form invoking packages/derisk-app/src/derisk_app/derisk_server.py with the same --config flag.
The Dataset Dependency Is the Sharpest Constraint
OpenDeRisk's default AI-SRE mode does not analyze your production telemetry out of the box. It analyzes OpenRCA. The README states that the decompressed dataset is approximately 26GB, that the technical implementation section describes pulling a 20GB dataset from GitHub, and that the default is the Telecom dataset from OpenRCA, retrieved with a gdown command against a Google Drive file ID. A second subset, the Bank Dataset, has its own gdown link. Both are meant to land in pilot/datasets/ under the project root. This has three consequences worth stating plainly. First, the on-ramp is a multi-gigabyte download from Google Drive, which is a fragile distribution channel: link rot, quota limits, and regional access problems are all plausible, and the README gives no mirror. Second, the numbers in the README are inconsistent (26GB decompressed versus 20GB pulled), which suggests the figure has drifted across revisions. Third, and most important, the demo path is a research benchmark. Making the system reason about your own logs and traces means supplying your own data in whatever form the Data-Agent and the ingestion path expect, and the README does not document that contract. The other two usage modes are more immediately usable: the Flame Graph Assistant accepts uploaded Java or Python flame graphs, and DataExpert accepts uploaded metrics, logs, traces, or Excel files for conversational analysis. If you want to evaluate OpenDeRisk without a 26GB download, those two modes are the realistic entry point.
Where OpenDeRisk Is the Wrong Tool
If you need deterministic, low-latency alerting, this is not it. The pipeline is a language-model-driven multi-agent loop, and the README makes no latency or cost claims, which is itself informative: there is no documented SLA, no published token budget, and no statement about how long an RCA run takes on the reference dataset. A system where an agent writes code at analysis time is inherently variable in runtime. There is also the maturity question. The project is not archived and the last push is recent, but the release history is thin: v0.2.0 in October 2025, a v0.2.1 archive release in February 2026, and v0.3.0 in March 2026. The existence of a release explicitly labelled archive suggests packaging churn between versions, so pinning a version and reading its notes before upgrading is warranted. Finally, the README's own caveat about partial implementation means the feature list should not be treated as a delivery guarantee. If you need a tool whose every advertised capability is present and documented, verify each agent's implementation under derisk-ext.agent.agents before you plan around it.
How This Differs From a Conventional Observability Stack
The obvious alternative is not another AI SRE agent but the stack you already run: an APM or tracing backend with dashboards and alert rules, plus a log search system. The difference in approach is structural. A rules-based stack encodes what an engineer already suspected was worth watching; it fires when a threshold you wrote is crossed. OpenDeRisk inverts that by generating the analysis after the fact, with Code-Agent writing the query or computation that the situation calls for, and Vis-Agent rendering the reasoning path so a human can check it. That inversion is the whole value proposition and also the whole risk. A dashboard is reproducible: the same data yields the same panel. An agent that writes its own analysis code may take a different route on two runs over identical inputs, which is why the visualized evidence chain is presented as a first-class feature rather than a debugging aid. If your requirement is a stable, auditable number that a compliance reviewer can trace, a conventional stack wins. If your requirement is an explanation for a novel failure that no rule anticipated, the generative approach is the one with a chance of producing it. The two are complementary, and OpenDeRisk's README does not claim to replace the telemetry systems it reads from.
Licence, Maintenance, and What an Upgrade Actually Costs
The licence is MIT, stated in the README badge and in the repository metadata. That is permissive: you can use, modify, and redistribute the code, including in commercial settings, provided the copyright notice and permission notice are preserved. This is not legal advice, and if you embed the project in a product you should have counsel review the actual LICENSE file and any third-party dependency licences, particularly the model providers and the OpenRCA dataset, which carries its own terms from Microsoft and is not covered by OpenDeRisk's MIT grant. On maintenance cost, the honest read is that the dependency surface is wide. The uv sync command alone pulls in RAG, ChromaDB, OSS2, and an OpenAI-compatible proxy extra, and the agent layer sits on top of a model provider you configure. Upgrading means re-validating that combination, not just bumping a version number. The three releases to date span roughly five months, and one is labelled archive, so treat the release cadence as active but unsettled. Agent and tool development is documented by pointing at derisk-ext.agent.agents for agents and at Skills plus MCP for tools, with a separate derisk-skills repository linked. That is a thin but real extension story: if you want to add a capability, you are expected to write it as a skill or an MCP tool rather than patch the core.
Editorial conclusion
Adopt OpenDeRisk if you want to study or extend a multi-agent RCA pipeline and you are willing to pull the OpenRCA dataset (the README cites a 26GB decompressed size and gives gdown links for the Bank and Telecom subsets). Do not adopt it as a drop-in production incident tool: the README states the code currently implements the highlighted parts of the architecture, and the primary evaluation path runs against a downloaded research dataset rather than your own telemetry. Before committing, verify that the dataset download links still resolve, that the model provider configured in ~/.openderisk/configs/derisk-proxy-aliyun.toml is one you can actually use, and read derisk-ext.agent.agents to confirm the agent set you need is present.
Community notes