PyOD 3: 61 Detectors, an Orchestration Layer, and an Agent Skill
A Python library for anomaly detection across tabular, time series, graph, text, image, and audio data. 60+ detectors, benchmark-backed ADEngine orchestration, and an agentic workflow for AI agents.
At a glance
- What is it?
- PyOD 3 keeps the classic fit/predict API but adds ADEngine orchestration, an od-expert skill for Claude Code and Codex, and an MCP server. The interesting question is not whether it detects anomalies, but whether the agent layer earns its place in your stack.
- Who is it for?
- Adopt PyOD if you want a single Python dependency covering tabular, time series, graph, text, image, and audio detectors, and you are willing to let ADEngine pick and compare models rather than hand-selecting one. Do not adopt it if your anomaly detection is a streaming, latency-bound problem, or if you need a maintained labelled dataset to validate a supervised classifier; PyOD's centre of gravity is unsupervised detection.
- Can I use it commercially?
- Yes. BSD-2-Clause 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 8 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 Problem PyOD Solves: One API Across Six Data Modalities
Most anomaly detection work starts with a detector choice made under uncertainty. You have a numeric table, or a sensor stream, or a graph of transactions, and you need to know which algorithm will flag the right rows. The usual answer is to read papers, reimplement two or three candidates, and build your own comparison harness. PyOD's answer is to ship the candidates. The README describes 61 detectors spanning tabular, time series, graph, text, image, and audio data behind what it calls one API. The five-line example is the contract: instantiate IForest, call fit on X_train, read decision_scores_ for training scores, and call decision_function on X_test for test scores. That shape repeats across detectors, which is the actual value. You are not learning a new interface per modality. The audience is engineers and data scientists who need a working baseline quickly and who would rather compare implemented detectors than write them. It is not aimed at researchers who need to modify an algorithm's internals, and it is not a streaming system.
ADEngine: Routing, Comparison, and Assessment Instead of Manual Selection
The README splits usage into three layers. Layer 1 is the classic API, for when you already know which detector you want. Layer 2 is ADEngine, described as the case where you want PyOD to choose, compare, and assess automatically. Layer 3 is agentic investigation, where a natural-language request drives the same engine. Layers 2 and 3 are both powered by ADEngine, which the README calls the lifecycle orchestration core. The routing is described as benchmark-backed, citing ADBench, TSB-AD, BOND, and NLP-ADBench. That is the mechanism worth understanding: ADEngine is not a new detector, it is a decision layer over the existing ones, and its recommendations are tied to published benchmark results rather than to heuristics invented for the library. The README also lists the MCP server's ten stateless tools, which include knowledge queries (list_detectors, explain_detector, compare_detectors, get_benchmarks) and planning functions (profile_data, plan_detection, and a build_detector entry that the truncated README cuts off). Those tool names are a fair summary of what the orchestration layer does: profile the data, plan a detection strategy, build the detector, and explain the choice. What the supplied material does not give is the scoring logic inside plan_detection, so treat the routing as a starting recommendation to inspect, not an oracle.
Installation Paths and the pyod info Diagnostic
The core install is a single command: pip install pyod. Everything else is an activation path layered on top. For Claude Code and Codex, the command is pyod install skill, with a --project flag for Codex because, as the README states, Codex has no user-global directory; the default writes to ~/.claude/skills/ while --project writes to ./skills/. For any MCP-compatible LLM, you install the optional extra with pip install pyod[mcp] and then run pyod mcp serve, which the README notes is an alias for python -m pyod.mcp_server. The pure-Python path needs no extra step at all: from pyod.utils.ad_engine import ADEngine. The diagnostic command is pyod info, which reports version, detector counts, and the install state of each activation path. It also detects whether ~/.claude/ or ~/.codex/ exists and recommends the matching install command. That detection is a small thing, but it removes the most common failure mode in agent tooling, which is installing a skill into a directory your agent never reads. One compatibility note from the README: the legacy pyod-install-skill command from v3.0.0 still works as an alias for pyod install skill. If you are upgrading an existing setup, that alias is why your old scripts have not broken.
Where PyOD 3 Is the Wrong Tool
The library's centre of gravity is unsupervised detection, and the README's framing supports that: outlier detection, novelty detection, out-of-distribution detection, and unsupervised learning are the listed topics. If your problem is supervised, with labelled fraud cases you trust, PyOD is not the natural home for that classifier, and the benchmark-backed routing will not help you because the benchmarks are about unsupervised settings. The second boundary is operational. Nothing in the supplied material describes incremental fitting, online scoring, or a streaming interface. The classic contract is fit on X_train, then decision_function on X_test. That is a batch shape. If you need per-event scoring with a latency budget, you are looking at the wrong layer, and the agentic path is worse for that use case, not better, because it adds a planning step in front of detection. The third boundary is the agent layer itself. It requires Claude Code, Codex, or an MCP-compatible client, plus the mcp extra for the MCP path. If your environment has none of those, Layers 2 and 3 collapse to the pure-Python ADEngine import, and the od-expert skill is dead weight you installed and never call. That is a configuration decision, not a defect, but it should be made before you write the install into a Dockerfile.
How PyOD Differs from scikit-learn's Novelty and Outlier Detectors
scikit-learn ships several of the same classical algorithms, and its estimator API is the model PyOD's classic layer follows. The difference is scope and the layer above it. scikit-learn's outlier detection is a handful of estimators inside a general-purpose machine learning library; it does not attempt cross-modality coverage, and it does not ship an orchestration layer that profiles your data and recommends a detector. PyOD's 61 detectors across six modalities, plus ADEngine and the benchmark-backed routing, is the part scikit-learn does not try to be. The trade-off runs the other way too. scikit-learn's estimators compose with its pipelines, cross-validation, and preprocessing machinery, which is a large ecosystem PyOD does not replicate. If your anomaly detection is one step in a broader scikit-learn pipeline, pulling in PyOD for a single detector adds a dependency for little gain. PyOD earns its place when you need the breadth, or when you specifically want the routing and comparison behaviour that scikit-learn has no equivalent for.
Licence, Release Cadence, and Upgrade Cost
PyOD is BSD-2-Clause, a permissive licence that imposes few obligations on redistribution compared with copyleft alternatives. This is not legal advice; read the LICENSE file in the repository and get your own review if you are shipping it inside a product. The release history shows a steady cadence: v3.6.3 on 2026-08-01, v3.6.4 on 2026-08-02, and v3.6.5 on 2026-08-17, with the repository last pushed 2026-09-08. Patch releases at that frequency are a mixed signal for upgrade cost. They suggest active maintenance, and they also mean a floating version pin will pick up changes you did not review. For a library whose core contract is fit and decision_function, patch churn is unlikely to break your code, but the agent-facing surface (skill install paths, MCP tool names, the pyod CLI subcommands) is newer and more likely to shift. The README already documents one such shift, the pyod-install-skill to pyod install skill rename, with the old name kept as an alias. Pin pyod to an exact version in production, and treat the agent activation paths as the part most likely to need attention on upgrade.
Verifying PyOD Before You Commit
The README makes several claims that are easy to check and worth checking. The detector count is stated as 61 in one place and the description says 60+, so run pyod info and read the number it reports for your installed version rather than trusting either figure. The od-expert skill's install target depends on your agent stack, so after pyod install skill, confirm the files landed where your agent actually looks; pyod info will tell you which stack it detected. The five-line IForest example is the fastest way to confirm the API contract end to end, and running it on your own data will surface shape and dtype problems that a synthetic example hides. Finally, if you plan to rely on ADEngine's routing, inspect what plan_detection returns for a dataset you already understand. The benchmarks behind the routing are published, but your data is not in them, and the only way to know whether the recommendation is sensible is to compare it against a detector you would have chosen yourself.
Editorial conclusion
Adopt PyOD if you want a single Python dependency covering tabular, time series, graph, text, image, and audio detectors, and you are willing to let ADEngine pick and compare models rather than hand-selecting one. Do not adopt it if your anomaly detection is a streaming, latency-bound problem, or if you need a maintained labelled dataset to validate a supervised classifier; PyOD's centre of gravity is unsupervised detection. Before committing, run pyod info on your target machine to see the version, detector counts, and which activation paths are actually installed, then run the five-line IForest example on your own data to confirm the fit and decision_function contract matches what your pipeline expects. The agent layer is optional and separable: everything above the classic API is additive, so you can pin pyod, ignore od-expert and the MCP server entirely, and still get the full detector set.
Community notes