explainX 3.0: An LLM-Native Rewrite That Has Not Reached PyPI
Explain & debug any blackbox machine learning model with a single line of code.
At a glance
- What is it?
- explainX wraps SHAP, LIME, anchors, counterfactuals, fairness metrics and data-centric diagnostics behind one explain_model call, and returns typed JSON instead of a Plotly dashboard. The catch is that the 3.0 code exists on master and in a git install, while pip install explainx still pulls the legacy 2.x package.
- Who is it for?
- Adopt explainX 3.0 if you already train scikit-learn, XGBoost, LightGBM or CatBoost models and want structured, JSON-serializable explanations plus fairness and drift reports without assembling SHAP, LIME and a fairness library yourself. Do not adopt it if you need a stable PyPI artifact today, if your stack is neither sklearn-API nor covered by wrap_model, or if you need an explanation method that is not on the supported list.
- 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 64 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 explainX fills between raw SHAP output and a decision
Running SHAP gives you a matrix of signed contributions. It does not tell you whether the model rejects one demographic group regardless of profile, whether a feature alone predicts the target (leakage), or which rows are probably mislabeled. explainX positions itself as the layer that answers those questions from one entry point. The README frames the goal as bringing "state-of-the-art explainability research into one place," and the capability table backs that up: global and local importance, LIME surrogates, anchors, counterfactuals, PDP and ALE, fidelity for surrogate trees, faithfulness and stability for the explanations themselves, conformal prediction for uncertainty, and Friedman's H-statistic for interactions. The intended user is an engineer or data scientist who has a trained model and needs an audit trail, not a researcher implementing a new attribution method. A second audience is explicit in the README: LLM agents that call explainX as a tool over the Model Context Protocol while they build models. That framing explains the design shift from the 2.x line, which the README describes as a human-only Plotly dashboard on a 2020 dependency stack.
What explain_model actually returns and how the pieces connect
The public entry point is explain_model(model, X_test, y_test, sensitive_features=[...], n_local=3). It returns a report object whose .summary attribute is a natural-language string, and the README states the underlying results are typed objects that serialize to JSON. That distinction matters for integration: a JSON report can be posted to a tracking server, diffed between runs, or handed to an agent, which a rendered figure cannot. Method selection is automatic where possible. For global importance the README gives a fallback chain: SHAP when installed, then permutation, then intrinsic importance. Local explanations follow the same pattern, SHAP when available and model-agnostic ablation otherwise. LIME is described as implemented from scratch, which removes a dependency but also means the LIME implementation is explainX's own and not the reference package. Counterfactuals use a greedy model-agnostic search with immutable and monotonic constraints, so you can declare that a feature such as age cannot change and get recourse suggestions restricted to actionable columns. Bias mitigation is post-processing per-group thresholds, applied after detection rather than during training. The data-centric diagnostics are separate calls on the same object: ex.error_analysis(), ex.label_issues(), ex.leakage(), ex.calibration(), each returning its own report type with a recommendation attached.
Installing 3.0 from git, because pip install explainx is still 2.x
The README is unusually direct about this: pip install explainx does not give you 3.0 yet, and the rewrite has not been published to PyPI. The legacy 2.x package is what a plain pip install resolves to. The documented path for the current code is pip install "git+https://github.com/explainX/explainx.git", or with every optional extra, pip install "explainx[all] @ git+https://github.com/explainX/explainx.git". For development and for running the bundled examples and tests, the README gives git clone, cd explainx, pip install -e ".[all]", then pytest. Extras are separable: shap, mcp, drift, llm, dashboard, or all, and they can be combined as in pip install "explainx[shap,dashboard]". The core install without extras is described as core only, with SHAP and the rest optional. Two consequences follow. First, a requirements.txt pinned to explainx will silently install 2.x, which has a different API and a Plotly output path. Second, because the extras gate SHAP, drift and LLM narration, a minimal install changes which methods are available at runtime, and the README's own fallback chain (SHAP, then permutation, then intrinsic) means the same call can produce different explanations depending on what is installed in the environment.
wrap_model and the boundary of what runs without wrapping
explainX targets the scikit-learn predict and predict_proba convention. The README lists scikit-learn, XGBoost, LightGBM and CatBoost as working with no wrapping, specifically through their sklearn-API estimators. That qualifier is the constraint: native XGBoost or LightGBM Booster objects are not in the direct-call list and are routed through wrap_model instead. The same adapter covers Keras and TensorFlow, PyTorch, statsmodels, and arbitrary prediction functions. The README shows three signatures: explain_model(wrap_model(keras_or_torch_model, task="classification"), X, y) for framework models, and explain_model(wrap_model(predict_proba_fn=my_api_call, classes=[0, 1]), X, y) for a remote or custom callable. The second form is the interesting one, because it means the model does not have to be local. The cost is that every wrapped call goes through your function, so explanation methods that need many forward passes, such as permutation importance or greedy counterfactual search, inherit the latency of that callable. For a hosted endpoint, that is the practical limit on how large an X you can explain in one pass. The README also states that runnable examples exist in examples/, one file per framework, which is the fastest way to check whether your specific estimator shape is covered.
The 3.0 rewrite has no PyPI release and no versioned API contract
The release list tells the story: 2.407 from February 2021, v2.403 from October 2020, v2.40 from October 2020. The 3.0 LLM-native rewrite described in the README is not among them, and the README confirms it is unpublished. The last push to the repository is dated 2026-07-13, so the code is moving while the installable artifact is frozen at 2.x. For anyone evaluating this for production, that is the central fact. You cannot pin a version number for the 3.0 API, you cannot rely on a release changelog to tell you what changed between commits, and a git install resolves to whatever master holds at install time. The README also names a specific model for LLM narration, Claude (claude-opus-4-8), which ties that feature to a third-party model identifier that will age independently of the library. The honest read is that 3.0 is a development branch with a README that reads like a release. Treat it accordingly: vendor the commit hash you install, and expect the API surface to shift before 3.0.0 lands on PyPI.
Where explainX is the wrong tool, and what to use instead
explainX is a broad aggregator, not a specialist. If you need the reference SHAP implementation with its full set of explainers and its own plotting and serialization formats, install shap directly and skip the wrapper; the README's own fallback chain shows explainX treats SHAP as an optional dependency rather than a replacement. If your work is deep-learning-specific attribution, such as gradient-based saliency for image or sequence models, explainX's method list does not include it, and a library built around that family is the better fit. If you need causal inference rather than associational explanation, none of the listed methods (SHAP, LIME, anchors, PDP, ALE, H-statistic) identify causal effects, and ALE's advantage over PDP is only about feature correlation, not causation. The clearest wrong-tool case is scale: the greedy counterfactual search and the permutation fallback both make repeated model calls, and with a wrap_model adapter pointed at a remote endpoint, explaining a large test set becomes a latency problem rather than a compute problem. A second case is the fairness module specifically. It computes demographic parity, disparate impact against the 4/5 rule, and equal opportunity per sensitive attribute, and mitigates by post-processing per-group thresholds. If your compliance requirement is a different metric family, or mitigation must happen in-training, this module will not satisfy it, and a dedicated fairness library is the right call.
Maintenance cost, licence and what to verify before adopting
The licence is MIT, which permits commercial use and modification with the copyright notice retained; this is a factual note about the licence identifier, not legal advice, and you should have counsel review anything that ships to customers. The maintenance picture is mixed by the material available. The repository is not archived, the last push is 2026-07-13, and the README documents a substantial rewrite with a test suite invoked by pytest, which suggests active work. Against that, the newest tagged release is from February 2021, so the release cadence visible in the metadata is five years behind the code. Upgrade cost is therefore concentrated at the install boundary rather than inside the API: moving from the legacy 2.x package to 3.0 changes the entry point, the output type (Plotly dashboard versus typed JSON report), and the dependency set, and the README's warning about pip install explainx means an unpinned environment can silently straddle both versions. The extras model adds a second cost, since each of shap, mcp, drift, llm and dashboard pulls its own dependencies and can be installed independently, so two developers on the same team can end up with different explanation methods available at runtime. Verify the git install and pytest pass on your Python version, confirm which extras your pipeline needs, and check that the examples/ file for your framework matches your estimator shape before you write it into a training run.
Editorial conclusion
Adopt explainX 3.0 if you already train scikit-learn, XGBoost, LightGBM or CatBoost models and want structured, JSON-serializable explanations plus fairness and drift reports without assembling SHAP, LIME and a fairness library yourself. Do not adopt it if you need a stable PyPI artifact today, if your stack is neither sklearn-API nor covered by wrap_model, or if you need an explanation method that is not on the supported list. Before committing, install from git with pip install "explainx[all] @ git+https://github.com/explainX/explainx.git", run pytest, and confirm that the extras you need (shap, mcp, drift, llm, dashboard) install cleanly on your Python version, because the 3.0 rewrite has no PyPI release to fall back on.
Community notes