# xtb: semiempirical tight-binding for large molecular systems

> xtb is the Grimme group's semiempirical extended tight-binding program package, written in Fortran and shipped as a command line program and a library. It trades quantum mechanical accuracy for speed across the GFN0, GFN1, GFN2 and GFN-FF parameter sets, and it builds with either Meson or CMake, from source, conda-forge, Homebrew or a prebuilt binary.

**grimme-lab/xtb** — Semiempirical Extended Tight-Binding Program Package

- Repository: https://github.com/grimme-lab/xtb
- Website: https://xtb-docs.readthedocs.io/
- Stars: 875 · Forks: 215
- Language: Fortran
- License: LGPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/grimme-lab-xtb

## What xtb is and who builds it

xtb is the official repository of the xtb program package developed by the Grimme group in Bonn. The name stands for extended tight binding, and the repository description calls it the Semiempirical Extended Tight-Binding Program Package.

The method is the interesting part. A semiempirical tight-binding calculation parameterises the electronic structure with a fitted Hamiltonian rather than solving the full electronic Schrödinger equation with a density functional. That approximation buys an enormous speed advantage, and it is the reason xtb exists as a tool rather than as a curiosity: you can optimise the geometry of a system with hundreds of atoms, or run a thousand single-point calculations to sample a potential energy surface, in a fraction of the time the accurate method would take.

The repository is written in Fortran, and the licence is LGPL-3.0, with the COPYING and COPYING.LESSER files at the root of the tree. The documentation is hosted on Read the Docs at xtb-docs.readthedocs.io, and there is a DOI badge pointing at the package's citable article.

The contributor list in the README explains the scale of the effort. The project states plainly that it is developing the program to make the group's research possible, and that many of the features it has today were added because there was a dire need for them and there were many contributors who made these features reality. The list runs to more than twenty named individuals including Stefan Grimme, the group's own members and collaborators.

The library form matters as much as the program. The package is described as a program package, so xtb is usable both as a command line tool and as a library linked into other codes, which is how it becomes part of a workflow rather than a standalone step.

## The parameter sets at the root of the tree

The top-level directory listing explains more about how xtb works than the README does, because the parameter files are the substance of a tight-binding method.

There is param_gfn0-xtb.txt, param_gfn1-xtb.txt, param_gfn1-si-xtb.txt, param_gfn2-xtb.txt and param_ipea-xtb.txt, plus a hidden.param_gfnff.xtb file. Each of these is a set of fitted parameters for one flavour of the method, and the naming makes the family structure clear.

GFN0, GFN1 and GFN2 are generations of the GFN family, with the numeral indicating increasing sophistication. GFN1 has a variant suffixed si, and GFN2 is the newest of the main line. GFN-FF is the force-field grade version, the cheapest and least accurate, which exists so that very large systems can still be handled at a useful speed.

IPEA-xTB is a separate member of the family, and the presence of.xtbrc at the root suggests a configuration file for the program.

The point about these files being in the repository rather than downloaded separately is that they are the method. A tight-binding parameterisation is a table of fitted numbers, one set per element and per element pair, and the difference between a fast approximate result and a slightly better fast approximate result is entirely in which table you point the program at. Shipping them in the tree means a version of the source tree carries a fixed set of parameters, which is what you want for reproducibility in a published calculation.

The directory listing also shows the supporting infrastructure: a src/ directory, include/ for the public headers, python/ for the Python interface, scripts/, man/ for manual pages, test/ for the test suite, symmetry/, subprojects/ for meson dependencies, cmake/ for the CMake build, meson.build with meson_options.txt at the root, and a.zenodo.json file for archiving.

## Two build systems, and what the README warns about

The project supports two build systems, Meson and CMake, and it links a short guide for each in the repository.

The Meson route needs a fairly new Meson, 0.62 or newer except for version 1.8.0, and ninja 1.7 or newer for the default backend. The build itself is three commands:

```bash
export FC=ifort CC=icc
meson setup build --buildtype release --optimization 2 -Dfortran_link_args="-qopenmp"
ninja -C build test
```

The README asks you to make sure the test suite runs without errors, and the install step is:

```bash
ninja -C build install
```

which puts the binaries in /usr/local and may require sudo.

The CMake route is the more conventional one. It needs make and CMake 3.9 or newer, and the chain is:

```bash
cmake -B build -DCMAKE_BUILD_TYPE=Release
make -C build
make -C build test
```

```bash
make -C build install
```

The compilers listed are, in order, ifort and icc at 2021.10.0 or earlier, then gfortran and gcc, then ifx and icx with a note that some versions may not work. The Intel compiler constraint at version 2021.10.0 is a little surprising for a project still actively maintained, and it suggests the code path has not been validated against newer Intel releases.

The macOS instructions are where the care goes. The README marks it as important that compilation with Meson on macOS differs slightly from the Linux protocol, and warns that different BLAS libraries can lead to deviating results in rare cases. The macOS path asks you to install gcc, gfortran and openblas through Homebrew, then to run a setup call with explicit library paths and a specific gfortran and gcc version:

```bash
brew install gcc gfortran openblas
```

```bash
LDFLAGS="-L/opt/homebrew/opt/openblas/lib" CPPFLAGS="-I/opt/homebrew/opt/openblas/include" FC=gfortran-14 CC=gcc-14 meson setup _build --buildtype release -Dlapack=openblas
```

That warning is not boilerplate. In a semiempirical method the energy is a sum of fitted pair terms, so a different BLAS can change the summation order, and the resulting differences show up as small deviations that propagate into geometry optimisations. Known issues are listed too, with GCC-13 on macOS on AArch64 named as a combination to avoid.

## Prebuilt binaries, conda and Homebrew

Most people should not build this from source, and the README is organised accordingly, with the prebuilt options listed before the build instructions.

Statically linked binaries built with the Intel Compiler are on the latest release page, with a Linux version built against Intel 18.0.2 and GLIBC 2.19, and a Windows version built with Intel 2022 and GNU-15. The old GLIBC floor on the Linux build is what makes that binary run on older distributions, which is useful in a cluster environment where you cannot easily install a newer toolchain.

The program and the library are packaged on conda-forge for Linux on x86_64, aarch64 and ppc64le, and for macOS on x86_64 and arm64. The conda route is three commands:

```bash
conda config --add channels conda-forge
```

```bash
conda install xtb
```

and to see what is available for your platform:

```bash
conda search xtb --channel conda-forge
```

For Homebrew users there is a custom tap at grimme-lab/homebrew-qc with prebuilt macOS x86_64 binaries, and for macOS arm64 the binaries are compiled on installation automatically.

There is also a bleeding edge channel, on the continuous release tag, providing releases for Linux and Windows built from the latest source in the repository. The tag is named bleed and it is dated 2020-12-30, which is odd on its face and worth understanding rather than dismissing: the date reflects when the tag was created, not the age of the artefact you would download from it, so check what you actually fetch. That is the trade for bleeding edge, since the tag moves and the version string does not tell you which commit you got.

The last push to the repository was on 2026-10-21, so the bleeding edge channel is genuinely current.

## Version numbering and what the release tags actually mean

The release list is short and its shape needs a word of explanation.

The named versions are v6.7.1 from 2024-07-23 and v6.7.0 from 2024-03-04, with the release titles naming the program, xtb version 6.7.1 and xtb version 6.7.0. Above them sits the bleed tag described earlier. Below them, nothing is listed, which means the version list is not a complete history in this view.

So the newest named release is more than two years old, while the source tree has been pushed to within a fortnight of the current date. That is a meaningful gap for a computational chemistry program, because a tight-binding implementation is sensitive to details that change quietly: a better parameter set, a fix to the convergence criteria, a correction to the handling of a specific element.

For a working installation, the practical advice is to use whatever the package manager gives you and record the version, since the version string is what appears in the output of a calculation and what you cite. For a published calculation, the bleeding edge channel is what you would use to get the parameter sets and code that produced your numbers, and the tag's date is not a reliable indicator of what is inside it.

The repository's own metadata is designed for archiving rather than for release notes. The .zenodo.json file and the DOI badge point at a Zenodo deposit, which is how a research code gets a citable archive identifier that does not change when the source moves on. For a scientific program that is the more durable citation anyway, since it pins a specific snapshot rather than a moving branch.

## Limits: the method, the parameter files and the platform coverage

The limits here are of two kinds, and both are worth being blunt about.

The first is the method. A semiempirical tight-binding Hamiltonian is a fitted approximation. It is good at geometry, at non-covalent interaction energies and at scanning large conformational spaces, and it is not a substitute for a density functional when the electronic structure itself is the question, when you are describing a bond-breaking event, or when you need a property the parameterisation does not cover. The GFN family exists precisely because one parameter set cannot cover all of chemistry well, so choosing GFN0, GFN1, GFN2 or GFN-FF is choosing which compromises you accept. The GFN-FF variant exists as the fastest and least accurate option, which is a reasonable way to think about the whole family.

The second is the operational detail that the README flags: the BLAS and LAPACK libraries affect the numbers. On macOS the warning is explicit that different BLAS libraries can lead to deviating results in rare cases. In a method that sums many fitted pair terms, a different summation order is a different last digit, and in an optimisation that can move a converged geometry.

A third limit is platform coverage. The conda-forge builds cover Linux on x86_64, aarch64 and ppc64le and macOS on x86_64 and arm64, and the Intel-linked binaries cover Linux and Windows. There is no mention of a Windows build for every architecture, and there is a known-issues list naming GCC-13 on macOS on AArch64 as a combination to avoid. Homebrew users on macOS arm64 get a compile at install time rather than a binary, which is a slow first install.

Finally, the Intel compiler ceiling at 2021.10.0 for ifort and icc means that a site standardised on a newer Intel toolchain may hit a wall, and the note that some ifx and icx versions may not work is not encouraging for the newest compilers.

## xtb against a density functional calculation and against a force field

Two comparisons put xtb in context.

The first is against a density functional calculation with a comparable basis set. The difference in approach is the treatment of the electronic structure. A DFT calculation solves the Kohn-Sham equations self-consistently for your specific molecule, so the quality of the answer depends on the functional and the basis you chose and on convergence. An xtb calculation evaluates a pre-fitted Hamiltonian, so the answer is determined by the parameter file and the geometry. The result is that DFT is right for reactivity and properties, and xtb is right for the regime where you have a good idea of the structure and need many calculations of it.

That regime is large. Conformer sampling for a drug-like molecule, a coarse scan of a binding pocket, a screening pass over thousands of candidate geometries, a molecular dynamics run for tens of nanoseconds. None of these is a place where you would run a DFT calculation, and all of them are places where xtb is used in practice. The honest framing is that xtb is the tool for the parts of a study that are about geometry, used to narrow the space before the expensive calculations run on what survives.

The second comparison is against a force field, GFN-FF being the example inside xtb itself. A classical force field has fitted parameters and no electrons, so it is faster still, and it is the right tool for long molecular dynamics on large systems. The difference is that GFN-FF keeps a quantum mechanical description of the bonding while xtb's force-field variant does not. The cost is speed; the benefit is that bond breaking and forming are handled at all, which a classical force field handles poorly or not at all.

So the progression within a single tool is instructive: GFN-FF for speed, GFN2 for accuracy, and a proper DFT calculation for the cases where the electronic structure is the point. xtb sits in the middle of that ladder, and its value is that it lets you move up and down it without changing your interface.

## Conclusion

Adopt xtb when you need geometry optimisation or conformer sampling on systems of hundreds or thousands of atoms, where a density functional calculation would be too slow, and you are willing to treat the results as approximate rather than definitive. Do not adopt it for reactions where the electronic structure changes qualitatively, or as a substitute for a benchmark calculation in a paper. Verify first which parameter set suits your system, since the GFN generations differ in scope, and that the BLAS and LAPACK libraries on your machine are the ones the build expects, because the README warns that different BLAS libraries can produce deviating results.

## FAQ

### What is xtb and which parameter sets does it provide?

xtb is the Grimme group's semiempirical extended tight-binding program package for large molecular systems, written in Fortran. The repository root carries the parameter files, including param_gfn0-xtb.txt, param_gfn1-xtb.txt, param_gfn1-si-xtb.txt, param_gfn2-xtb.txt, param_ipea-xtb.txt and the GFN-FF parameter set, with GFN-FF being the fastest and least accurate grade of the method.

### How do I install xtb?

The program and library are on conda-forge for Linux and macOS, so adding the conda-forge channel and running conda install xtb is the shortest route. Homebrew users can use the grimme-lab/homebrew-qc tap, and statically linked Intel-built binaries for Linux and Windows are on the latest release page. A bleeding edge channel on the continuous release tag carries builds from the latest source.

### How do I build xtb from source?

The project supports two build systems. Meson needs version 0.62 or newer except 1.8.0 plus ninja 1.7 or newer, and the CMake route needs make and CMake 3.9 or newer. Both end with an explicit test step, ninja -C build test or make -C build test, which the README asks you to run and check before installing.

## Sources

- [grimme-lab/xtb on GitHub](https://github.com/grimme-lab/xtb)
- [License: LGPL-3.0](https://github.com/grimme-lab/xtb/blob/main/LICENSE)
- [Project website](https://xtb-docs.readthedocs.io/)
- [README](https://github.com/grimme-lab/xtb/blob/main/README.md)
- [Releases](https://github.com/grimme-lab/xtb/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/grimme-lab-xtb