lambeq: a high level Python library for quantum natural language processing

The diagram is the layer everything else is built on

lambeq is described as a toolkit for quantum natural language processing, and the thing that makes it more than a parser wrapper is the intermediate representation.

The pipeline has three conceptual stages. Text becomes a diagram, a diagram becomes a circuit, and a circuit is what a quantum computer runs. The diagram is the pivot. A diagram is a compact graph of the sentence's syntactic structure, and it is the object you can write quantum algorithms against without worrying about the register layout or the gate sequence.

The public entry point in the README is a parser, which gives a sense of where the abstraction starts.

from lambeq import BobcatParser

parser = BobcatParser()
diagram = parser.sentence2diagram('This is a test sentence')
diagram.draw()

Three calls and you have a diagram, and draw() renders it. The significance is what comes after. Because the diagram is the stable interface, the parser can be swapped without rewriting the circuit construction, and several circuit construction strategies can sit on top of the same diagram.

The dependency list in pyproject.toml shows how wide that surface is. The mypy overrides name depccg, discopy, jax, pennylane, requests, sympy, tensorflow, tensornetwork and tqdm, plus a separate override for transformers. discopy is a categorical quantum computing library, and pennylane and jax sit next to it, which tells you the toolkit spans from symbolic diagram manipulation to differentiable circuit construction. tensorflow and tensornetwork point at a tensor network layer. A transformer model can be loaded for embeddings or as a parser dependency.

In other words, lambeq is not only a compiler from text to circuits. It is a set of interchangeable pieces, and the diagram is the contract between them.

Bobcat is bundled, DepCCG is on the way out

The parser story is where the project is candid about its own history, and it is the first thing to understand before you pick a version.

The default installation includes the Bobcat parser, described as a state of the art statistical parser and fully integrated with the toolkit, with a related paper cited in the readme. So the standard pip install gives you a working parser with no extra setup, and the mypy configuration reflects that integration with a dedicated override that turns off strict optional for lambeq.bobcat and lambeq.oncilla, which are the two parser modules named there.

DepCCG is the alternative, and the readme marks it as no longer actively supported in lambeq, saying it may not work as expected, and strongly recommending the default Bobcat parser instead. To enable DepCCG support you have to install the external parser separately, and the readme points at the DepCCG homepage for instructions.

The case for keeping DepCCG alive is given explicitly: if you plan to apply lambeq on Japanese, you might want it. After installing DepCCG, you download its model with a script from the contrib folder of the repository.

python contrib/download_depccg_model.py

That the repository still ships a contrib folder with a model downloader for a parser it no longer supports says something about the project's audience. It is a research toolkit maintained by people who care about not breaking existing pipelines, and the separate DepCCG install is a documented escape hatch rather than a supported path.

The trade-off for a new user is straightforward. If your text is English, the default is fine and the extra dependency is the right thing to skip. If you need Japanese, you are signing up for an external parser that the toolkit does not support, and you should verify it works with your version of lambeq before planning around it.

Two extras bundles, and what they pull in

Installation is deliberately plain. The prerequisite is Python 3.10 or newer, and the install command is a single line.

pip install lambeq

There are two optional dependency groups, and the distinction between them is the useful part. The extras group is for optional dependencies for extra features, and the experimental group is for optional dependencies for experimental features. The names are unusually honest about the difference in stability.

pip install lambeq[extras]
pip install lambeq[experimental]

Whether to install the experimental group is a decision about your own risk tolerance, and the readme does not enumerate what is in either group. Given the mypy overrides, the experimental set is likely to be where the heavier numerical stacks live, since tensorflow, tensornetwork, jax, pennylane and transformers all appear in the type checking configuration, but that is an inference from the configuration rather than a statement in the documentation.

The packaging is modern in the small ways. The build system requires setuptools of at least 42.0, wheel and setuptools_scm with the toml extra at 3.4 or newer, and the version is derived from the git tag through setuptools_scm with write_to pointing at lambeq/version.py. That means the installed version follows the repository's tags rather than a hardcoded string, which is good practice for a library that ships a version file.

The type checking setup is thorough, and worth reading if you work on the codebase itself. Mypy is configured with pretty output, error codes shown, and a set of warnings enabled that are not defaults: warn_redundant_casts, warn_return_any, warn_unreachable, warn_unused_configs and warn_unused_ignores, plus an enable_error_code of ignore-without-code so that a type ignore has to say what it is ignoring. The coverage configuration excludes pragma no cover lines, the __repr__ and __str__ methods, and TYPE_CHECKING blocks. The repository root also holds a setup.cfg, a tests directory and a .gitmodules entry.

Testing is pytest, and the docs live in a separate repository

The test command is the standard one, with one practical warning attached.

pytest

The note matters if you use a virtual environment: if you have installed lambeq in a virtual environment, remember to install pytest in the same environment using pip. That is a small detail, but it is the kind that produces a confusing failure when pytest is present in the global environment and lambeq is not.

The documentation is split in two, and this is worth knowing before you look for examples. The readme points to https://docs.quantinuum.com/lambeq/ for the documentation, and the examples live in a docs/examples directory in a separate repository, lambeq-docs, rather than in the code repository you have cloned. The specific notebook cited for the parser example is docs/examples/parser.ipynb in that repository. So the code you clone is the library, and the notebooks that demonstrate the tools are somewhere else.

That split is a reasonable way to keep a code repository free of large notebook files, and it is also a place to look if you are evaluating the project. The examples are the fastest way to see what a particular circuit construction strategy actually produces, and they are not in the tree you are about to clone.

Support and contribution routes are stated as well. User support goes to a lambeq-support email address, contributions follow a guide linked from the readme, and the mailing list is available by emailing the same address. There is also a published paper, arXiv 2110.04236, and the readme includes a BibTeX entry for citing it, so if you publish work using the library, the citation is already written down for you.

Where a research toolkit stops being production software

The honest limitations come from the nature of the project rather than from any bug.

The first is the parser situation, already described. A bundled statistical parser is a research artifact with its own model, its own accuracy characteristics and its own maintenance trajectory, and lambeq's own recommendation to avoid DepCCG tells you the toolkit itself has a preferred path. If the parser is the component you actually depend on, you are depending on a research dependency, and you should evaluate the parser's behaviour on your own domain rather than assuming the integration is the thing that matters.

The second is the version gap. The published releases are 0.5.0 from 2025-05-15, 0.4.3 from 2024-09-02 and 0.4.2 from 2024-08-09, while the last push to the repository was on 2026-09-01. So the code is being worked on, but the last published artefact on PyPI is more than a year older than the head of the branch. The 0.x version number also signals an API that is still moving, and this is a library rather than an application, which means a breaking change in a patch release is a real possibility rather than a theoretical one. Pin an exact version.

The third is the dependency surface. The type checking configuration names tensorflow, tensornetwork, jax, pennylane, discopy, sympy and transformers, and installing the extras or experimental group pulls some of those in. For a research group on a cluster that is manageable. For a production service, a dependency list spanning several numerical stacks and a machine learning framework is a large install and a large surface, and the readme does not describe a slim production install.

The fourth is scope. There is no hardware execution layer described here. The documentation covers building circuits, and the project is about producing them, not about running them on a device. If you need an end to end path from a sentence to a result on a quantum processor, lambeq is one half of it, and the other half is whatever backend you connect the circuits to.

The alternative to weigh against it is not another library so much as a different order of work. A classical NLP pipeline that ends at embeddings or at a dependency parse, combined with a separate circuit construction library such as discopy on its own, lets you build and test each half independently and keeps the natural language side free of a quantum abstraction. The difference in approach is that lambeq makes the diagram the centre of gravity, so a change of parser or a change of circuit construction is a drop-in swap, and the price is that the text processing lives inside a library whose centre of gravity is quantum computation.

Apache 2.0, and a project that answers its own support email

The licence is Apache 2.0, stated in the readme as distributed under the Apache 2.0 license with the LICENSE file holding the details, and there is a licence badge pointing at that same file.

Apache 2.0 is a permissive licence with an explicit patent grant, which is a good fit for a research library that you might incorporate into something commercial. Two obligations are worth remembering in practice: the licence and copyright notice travel with redistribution, and there is a patent termination clause. This is not legal advice, and if you are embedding the library in a product you should read the LICENSE file and take advice on your own situation.

The support model is unusual for an open source library and is worth weighing as part of the adoption decision. The readme lists a company support address, [email protected], and says that if you want to subscribe to the mailing list you should email the same address. Contributions are handled through a contributing guide hosted on the same documentation site as the manual.

What that tells you is that lambeq is maintained by a commercial quantum computing company, Quantinuum, and that the library is the open face of a larger stack that also includes documentation hosted under their domain. The library itself is permissively licensed and usable on its own, but the roadmap, the priority order and the shape of the API are shaped by a commercial interest in quantum computing hardware. If you are building on it, that alignment is generally a good thing, since the maintainers care about the library being useful. It is also a fact worth being explicit about rather than discovering later.

The repository topics are python and qnlp, and the primary language is Python, with the readme keeping the name in a lowercase form that reads like the Greek letter lambda.

Editorial conclusion

lambeq suits a researcher who wants a classical text pipeline that ends in a quantum circuit and who values the diagram as an intermediate representation, and it does not suit a team that only needs reliable constituency parsing, since the bundled Bobcat parser is a research dependency and the recommended replacement for other languages is no longer supported in the toolkit. Before you build on it, check the version you are pinning, because the last published release is 0.5.0 from 2025-05-15 while the last push was on 2026-09-01, and read the mypy configuration in pyproject.toml, since the strict optional settings for lambeq.bobcat and lambeq.oncilla tell you where the type guarantees stop.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. Quantinuum/lambeq on GitHub
4. README
5. Releases