LIT: A Browser UI for Inspecting Model Behavior, With a Python Backend You Have to Wire Up Yourself
The Learning Interpretability Tool: Interactively analyze ML models to understand their behavior in an extensible and framework agnostic interface.
At a glance
- What is it?
- PAIR-code's Learning Interpretability Tool puts salience maps, slicing, counterfactuals and side-by-side model comparison behind a browser interface, and asks you to write two Python classes before it will show you anything about your own model.
- Who is it for?
- Adopt LIT if you already have a model you can wrap in the Model API and a labelled dataset you can expose through the Dataset API, and if the questions you are asking are about individual examples (which inputs drive a prediction, how a paraphrase changes it, where two checkpoints disagree). Do not adopt it if you need training-time curves, a hosted dashboard with no code, or a tool that works without a Python process holding your model in memory.
- Can I use it commercially?
- Yes. Apache-2.0 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 6 days ago.
- What is it written in?
- Mainly TypeScript, 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 debugging question LIT is built around
Most model evaluation stops at a number. Accuracy on a held-out split tells you that something is wrong somewhere in the distribution, not which examples are wrong or why. LIT is aimed at that gap. The README frames the tool around three questions: what kind of examples does the model perform poorly on, why did it make a particular prediction (including whether the cause looks like adversarial behavior or an undesirable prior in the training data), and whether behavior stays consistent when you change style, verb tense or pronoun gender. Those are per-example and per-slice questions, and they are the ones a confusion matrix cannot answer. The intended user is an engineer or researcher who has a trained model sitting in a Python process and wants to poke at it interactively rather than write a one-off plotting script for each hypothesis. LIT supports classification, regression, span labeling, seq2seq and language modeling, and the README notes multi-head models and multiple input features are handled out of the box. Text, image and tabular data are all in scope, which is unusual: most interpretability tooling picks one modality and stays there.
Two Python classes are the real integration surface
The architecture is a Python server that owns your model and data, plus a TypeScript frontend served in the browser. The README states the repo does not include a distributable version of the LIT app and that you must build it from source, so the frontend is not a hosted artifact you point at an endpoint. Data flows through two interfaces. A data loader implements the Dataset API and yields examples. A model wrapper implements the Model API and returns predictions plus whatever interpretability outputs you can produce, such as salience maps. Both, along with any additional interpretation components, are passed to the LIT server class. That is the whole contract: LIT does not introspect your model. If your wrapper cannot produce salience, the salience views have nothing to draw. This is the design decision that determines whether LIT is worth an afternoon. Frameworks that require you to export a model to a fixed format are more restrictive but give you more for free; LIT inverts that, and the cost lands on you. The payoff is that TensorFlow, PyTorch and anything else callable from Python are equally acceptable, since LIT never sees the framework, only the wrapper's return values.
Running the GLUE demo and the source build
The fastest path is pip. The README gives pip install lit-nlp for the Python API, built-in interpretability components and the web application, with extras for the shipped examples: pip install 'lit-nlp[examples-discriminative-ai]' for GLUE and Penguin, pip install 'lit-nlp[examples-generative-ai]' for prompt debugging, and pip install 'lit-nlp[test]' for everything plus the test suite. The quickstart command is python -m lit_nlp.examples.glue.demo --port=5432 --quickstart, after which you open http://localhost:5432. The default view is a small BERT-based model fine-tuned on the Stanford Sentiment Treebank, and the README says you can switch to STS-B or MultiNLI from the toolbar or the gear icon. Other examples follow the same shape: python -m lit_nlp.examples.<example_name>.demo --port=5432 with optional arguments. Installing from source is a different sequence. Clone the repo, confirm Python 3.9 or newer, create a virtual environment, then run python -m pip install -e '.[test]'. The frontend is a separate build step: (cd lit_nlp; yarn && yarn build). The README links a known yarn issue on Ubuntu and Debian and points at the correct version to install. Notebook use is supported through the Colab and Jupyter path, with examples under lit_nlp/examples/notebooks and a Colab demo for a sentiment classifier. Note that the quickstart downloads a model; nothing in the material describes offline operation.
Where the wrapper abstraction bites back
The framework-agnostic claim is real but it is not free. Because LIT only knows what your Model API implementation returns, every view you want has to be fed. Salience maps need per-token or per-pixel attributions that your wrapper computes. Counterfactual generation via generator plug-ins needs a generator you supply; the README describes manual edits and generator plug-ins as the two routes, so the manual route is the one that works with no extra code. Aggregate analysis with custom metrics, slicing and binning, and embedding space visualization all depend on fields your dataset and model expose. A second limitation is environmental: the server holds your model in a Python process, so this is not a tool you hand to a product manager as a URL unless you host the process and the built frontend yourself. The README mentions container images and a containerization guide, plus pre-built images that take advantage of accelerators for generative AI and LLM cases, which addresses deployment but adds a dependency on that path. The third constraint is version currency. The most recent release listed is v1.3.1 from December 2024, following v1.3 in October 2024 and v1.2 in June 2024. If you are working with a model architecture or tokenizer that postdates the built-in components, expect to write the glue yourself.
Against Captum and SHAP: attribution library versus inspection environment
The natural comparison is an attribution library such as Captum or SHAP. Those produce numbers. You call them, get an array of feature importances back, and then decide how to plot it, how to slice the dataset, and how to compare two checkpoints. LIT is the layer above that: it assumes attributions exist and asks what you want to do with them across a dataset, in a UI, with side-by-side mode for comparing two or more models or one model on a pair of examples. The difference in approach matters at the boundary. If your question is a single attribution on a single input inside a training script, a library is the shorter path and LIT adds a server, a frontend build and two interface implementations for nothing. If your question is which slice of the validation set the model fails on, and you want to edit an example in the browser and re-run the model on it immediately, LIT is doing work a library leaves to you. There is also a notebook story: LIT runs inside Colab, Jupyter and Vertex AI notebooks, so the same UI can appear next to the code that produced the model. That is a genuine difference from a static plotting library, and it is the reason the two coexist rather than compete.
Maintenance, licensing and what a version bump costs
LIT is Apache-2.0, which permits commercial and internal use and modification, and the repository is not archived, with a last push in September 2026 and a release cadence through 2024 that shows roughly two to three tagged versions a year. Apache-2.0 also means if you fork and modify the frontend, you carry the build yourself; the README already tells you the repo ships no distributable app, so a fork inherits that problem permanently. This is not legal advice, and if you redistribute LIT inside a product you should read the licence text rather than this paragraph. On upgrade cost, the practical question is which of your custom pieces sit on unstable ground. Your Dataset and Model implementations are your code, so a LIT upgrade cannot break them directly, but it can change what the UI expects to receive, which is why the release notes are worth reading before bumping. The frontend build means an upgrade is not just a pip install: if you installed from source, you rebuild with yarn after pulling. If you installed from PyPI, the wheel carries the app and the upgrade is a single command, which is a real argument for staying on the packaged path unless you need to change LIT's own code.
Who should wire it up, and what to check first
LIT earns its setup cost when the model already exists and the open questions are about examples rather than about training. A team comparing two fine-tuned checkpoints on the same inputs will use side-by-side mode immediately. A team investigating whether a classifier is keying on a spurious cue will use salience plus manual counterfactual edits, and neither requires a generator plug-in. A team whose model only exists as a hosted API endpoint will find the Model API wrapper awkward, because LIT wants to call the model in-process and the README's examples all assume a local Python model. Before writing the wrapper, read the API documentation for the Dataset and Model interfaces and check that your model can return whatever the views you care about need; the README's own walkthrough is at the adding models and data page. Then confirm Python 3.9 or newer and decide between the pip path and the source path, since that choice determines whether every upgrade includes a yarn build. If those checks pass, the GLUE quickstart is a reasonable first run to see the UI before any of your own code exists.
Editorial conclusion
Adopt LIT if you already have a model you can wrap in the Model API and a labelled dataset you can expose through the Dataset API, and if the questions you are asking are about individual examples (which inputs drive a prediction, how a paraphrase changes it, where two checkpoints disagree). Do not adopt it if you need training-time curves, a hosted dashboard with no code, or a tool that works without a Python process holding your model in memory. Before committing, verify three things against the v1.3.1 release: that your Python is 3.9 or newer, that your model wrapper returns prediction and salience fields in the shape the UI components expect, and that you are willing to run yarn build inside lit_nlp after every frontend change, because the repo ships no prebuilt app.
Community notes