OmniXAI: one interface for SHAP, LIME, counterfactuals and CAM methods

The problem OmniXAI targets: explanation code that does not transfer between models

Practitioners who explain models usually end up with a folder of scripts. One script calls SHAP for a gradient-boosted tabular model. Another calls LIME for a text classifier. A third implements Grad-CAM for a CNN. Each has its own input format, its own output object, and its own plotting code. OmniXAI's stated aim is to collapse that into a unified interface so that, per the README, users generate explanations "by only writing a few lines of codes." The intended audience is data scientists, ML researchers and practitioners who need explanations across several data types and model families rather than one. The README frames the scope as the whole ML pipeline, from exploratory data analysis through model training to explanation, which is a wider claim than most XAI libraries make. Whether that scope holds up depends on how much of the pipeline you actually need, and the method table suggests the centre of gravity is explanation rather than training.

How the library is organised: explainers, a unified interface, and a dashboard

The core abstraction visible in the README is the explainer. Each method in the table is an explainer class, and the table classifies every method along four axes: model type, explanation type (global or local), and the data modalities it accepts. That grid is the architecture in miniature. A feature-attribution method such as SHAP and a gradient method such as integrated gradient are separate explainers, but they are addressed through the same calling convention, which is why the README can claim a unified interface. Model type matters because it determines what the explainer can do internally. Black box explainers only call predict, so they work with scikit-learn estimators, PyTorch modules and TensorFlow models alike. Explainer classes marked Torch or TF need access to internals, which is why feature visualization, Grad-CAM, Score-CAM, Layer-CAM and guided backpropagation are restricted to those frameworks. The table's footnotes add a second layer of conditions: SHAP accepts black box models for tabular data, PyTorch or TensorFlow models for images, and transformer models for text, while counterfactual explanation accepts black boxes for tabular, text and time-series data and Torch or TF models for images. There is also a GUI dashboard for visualising results, and a hosted dashboard demo is linked from the README.

Getting it running: pip install and the explainer imports

Installation is a single command: pip install omnixai, with the README listing support for Python 3.7 through 3.10. The package is published on PyPI as omnixai. The README's Getting Started section points to the hosted documentation and tutorials rather than inlining a full example, so the exact constructor arguments for each explainer are not visible in the repository description. What can be confirmed from the README is the import surface: explainers are grouped by data type under omnixai.explainers, with submodules for tabular, vision, text and timeseries, mirroring the columns of the method table. That organisation means the modality you are working in determines the submodule, and the explainer class you pick determines the method. The GPT explainer is described as experimental and is built on top of SHAP and MACE output: it feeds those results into a prompt for ChatGPT and returns a natural-language explanation. The README is explicit that "the generated results may not be 100% accurate" and that the input prompts are still being improved. Treat that component as a preview, not as a supported explanation method you can audit.

Where the coverage is thin: text, time series and the GPT explainer

The method table is the most honest document in the project, because it shows the gaps. Time series appears in exactly four rows: prediction metrics, SHAP, counterfactual and nothing else. There is no time-series equivalent of partial dependence or permutation importance, and no gradient method for sequential data. Text is similarly narrow. LIME, SHAP, prediction metrics, counterfactual, integrated gradient and learning to explain are listed, but every one of them is local, and the text column has no global method at all. If your goal is to characterise a text classifier's overall behaviour rather than explain individual predictions, the table offers nothing. The GPT explainer is restricted to tabular classification and regression models, so it does not extend the text or image story. There is also a practical constraint hiding in the footnotes: methods that need model internals lock you to PyTorch or TensorFlow, so a model served behind an HTTP endpoint can only be explained by the black box methods, which for images means SHAP and counterfactual only.

The maintenance question: a 2024 release and a fast-moving dependency

The release history is worth reading before you build on this. The three most recent releases are v1.3.0 in May 2023, v1.3.1 in July 2023, and v1.3.2 in April 2024. The repository shows a push in June 2026, so the project is not archived, but the tagged release cadence is slow, roughly one release per year across that window. That matters for a library whose headline feature is a GPT-backed explainer, because the prompt construction depends on an external API whose behaviour changes on the provider's schedule, not the library's. The README itself concedes the prompts are still being improved. A second cost is dependency weight. Choosing OmniXAI to run SHAP pulls in the whole package, including the vision and text explainers and their framework dependencies, whereas installing shap alone gives you the same tabular attributions with a smaller surface. Licensing is BSD-3-Clause, which is permissive and permits commercial use and modification; the usual obligation is retaining the copyright notice and licence text, but read the LICENSE file in the repository and get your own legal review rather than relying on that summary.

The alternative worth comparing: the shap package on its own

The most direct alternative for tabular work is the shap package by itself. The difference is scope versus depth. OmniXAI wraps SHAP and gives it a common interface with LIME, counterfactuals, permutation importance, partial dependence and the CAM family, so switching methods does not mean switching APIs. The shap package does one thing, but it exposes the full range of SHAP variants and the underlying explanation objects directly, without an intermediate abstraction. That abstraction is the trade-off. If you need to inspect SHAP internals, customise a masker, or use a SHAP feature the wrapper does not surface, the wrapper is in your way. If you need to compare a SHAP attribution against a counterfactual for the same prediction, the wrapper saves you from writing the glue. A second alternative is the explanation tooling built into the framework you already use, such as PyTorch's captum for gradient-based image and text methods. That keeps dependencies inside one ecosystem, but it does not cover tabular feature attribution or counterfactual generation, so it solves a different slice of the problem.

Who should adopt OmniXAI, and what to verify before you do

Adopt OmniXAI when your work spans modalities and explanation types. A team explaining a tabular credit model, an image classifier and a text classifier can use one import pattern and one set of output objects instead of three unrelated libraries, and the method table tells you upfront which combinations are supported. Do not adopt it if your only need is SHAP on tabular data, or if you require a stable, versioned contract for the GPT explainer, which the README itself calls experimental and not fully accurate. Before committing, verify three things on your own data: install omnixai and confirm the Python version in your environment is within the 3.7 to 3.10 range the README lists; run one explainer from omnixai.explainers.tabular against your fitted model and check that the returned explanation object and its plotting output behave as the tutorials describe; and confirm that your model is reachable in the form the chosen explainer requires, since the Torch or TF methods need model internals and will not work against a black box served over HTTP. The library is a genuine convenience layer, but the release cadence means you should expect to pin a version rather than track main.

Editorial conclusion

Adopt OmniXAI if you need several explanation types across more than one data modality and want one API instead of four. Skip it if you only need SHAP on tabular data, since the shap package alone is a smaller dependency, or if you need a maintained, versioned spec for the GPT explainer. Before committing, install omnixai, run one Explainer from omnixai.explainers.tabular against your own fitted model, and check the returned Explanation object and its plot() output on your data.

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. Releases
5. salesforce/OmniXAI on GitHub