orb-models: pretrained force fields for atomic and molecular simulation

A set of potentials, not a simulator

orb-models is a Python package of pretrained models for atomic simulations, described in the pyproject metadata as foundation models for computational chemistry. The distinction in that last phrase matters, because the package is not a molecular dynamics engine and it is not a DFT code. What it is is a set of trained force field potentials that you plug into the simulator you already use, so that the expensive electronic structure calculation is replaced by a learned approximation. The README is careful about where it sits in the stack. Installation is a single pip command, and the models are expected to work on macOS and Linux while Windows support is not guaranteed, and Docker is offered as an alternative route. The dependency list in the pyproject file gives the shape of the environment: ASE at 3.25.0 or newer below version 4, torch at 2.8.0 or newer below 3.0.0, scipy, cached-path, tqdm, dm-tree pinned exactly, and the ALCHEMI toolkit ops. The Python requirement is 3.12 or newer, with classifiers for 3.12, 3.13 and 3.14. So this is a package for people who already live in the ASE and torch ecosystems, and the value proposition is that you get the potential without the training cost.

Four generations of models, each with a different scope

The updates section is a timeline of model releases and it shows the direction of travel. In September 2024 the v1 models arrived with a claim of state of the art performance on the matbench discovery dataset. In October 2024 came the Orb-v2 set of potentials, and in April 2025 the Orb-v3 set. In August 2025 the release of the OrbMol potentials extended the approach from crystals to molecular systems, trained on the Open Molecules 2025 dataset, which is described as over 100 million high-accuracy DFT calculations at the omegaB97M-V/def2-TZVPD level of theory, covering metal complexes, biomolecules and electrolytes. Those OrbMol models are architecturally similar to the Orb-v3 models but accept explicit total charges and spin multiplicities as input, which is the difference between a potential for a periodic crystal and one for a charged molecule. The May 2026 update added OrbMol-v2, which brings a CoulombModule for long-range electrostatics on top of the OrbMol architecture, using direct Coulomb summation for non-periodic systems and Particle Mesh Ewald through nvalchemiops for periodic ones, and was trained on OMol25 and OPoly26. A MODELS.md file holds the full list with usage guidance, and the example in the README loads a model with pretrained.orbmol_v2(device="cuda").

Charges and long range electrostatics, and the numbers behind them

Two claims in the May 2026 entry are worth separating from the marketing framing. The first is that GSCDB138 Normalized Error Ratio drops from 6.05 to 1.62, which the README describes as 3.7 times lower and comparable to a good DFT functional. The second is that model.compile(...) now wraps the full regressor for all models, giving about 1.7 times speedup at ten thousand atoms on a single 80 GB GPU. The first is a benchmark result on a named dataset with a defined metric, which is the form in which a claim can be checked, and the second is a performance statement with the hardware and system size attached. Both come from the project, and neither is an independent measurement, so the sensible reading is that they indicate where the model stands relative to the reference functional rather than settling the question. The physics point behind them is the important one for users. Coulomb interactions do not cut off, and a model that only sees short range interactions will systematically misplace the charge distribution in a polar or ionic system, which is exactly the failure mode that kills a naive learned potential on electrolytes. The CoulombModule is the answer to that, with two implementations selected by whether the system is periodic.

The ASE calculator is the shortest path to a working potential

The recommended entry point for most users is the ASE calculator, because it means the potential drops into any code that already speaks ASE. The pattern is the same everywhere: load a pretrained model, wrap it in a calculator, attach the calculator to your atoms.

import ase
from ase.build import bulk

from orb_models.forcefield import pretrained
from orb_models.forcefield.inference.calculator import ORBCalculator

device="cpu" # or device="cuda"
# or choose another model using ORB_PRETRAINED_MODELS[model_name]()
orbff, atoms_adapter = pretrained.orb_v3_conservative_inf_omat(
  device=device,
  precision="float32-high",   # or "float32-highest" / "float64
)
calc = ORBCalculator(orbff, atoms_adapter=atoms_adapter, device=device)
atoms = bulk('Cu', 'fcc', a=3.58, cubic=True)

atoms.calc = calc
atoms.get_potential_energy()

The model returns two objects, a force field and an atoms adapter, and the adapter is the piece that handles the translation between ASE's Atoms objects and the internal graph representation. The calculator then presents that to ASE as a familiar calc attribute. From there the README shows a geometry optimisation with ASE's BFGS optimiser, which starts from a rattled configuration and relaxes to a force maximum of 0.01, and it also points at an examples directory containing a script, an input xyz file and a Colab notebook for molecular dynamics, with the advice to modify the input_file and cell_size parameters and to use constant volume simulations. The direct usage path is available too, where you build the graph yourself with atoms_adapter.from_ase_atoms and read results from orbff.predict.

Precision defaults changed, and that changes your numbers

One behavioural change is easy to miss and it will change results if you compare across versions. model.predict(...)["energy"] now returns fp64 by default, to preserve kJ/mol resolution against OMol-scale references, which are described as on the order of 1e4 to 1e5 eV, and you can opt out by passing fp64_energy=False. The reason for the change is resolution. At single precision, an energy of that magnitude has a representable step large enough to swamp the differences you are trying to measure, so the energy becomes noise and a force derived from it is worse. Returning fp64 by default fixes that at the cost of memory and bandwidth, and the opt-out exists for people who are doing large batches where the memory matters more than the resolution. The precision argument on model loading is a separate knob, with the example using float32-high and the comment listing float32-highest and float64 as alternatives. So there are two precision decisions in this API, one for the model and one for the returned energy, and the second one has a default that differs from what an older version of the package would have done.

Batching with TorchSim and the GPU graph construction path

The February 2026 update is about throughput. Graph construction is now GPU accelerated using the ALCHEMI Toolkit-Ops from NVIDIA, which the README describes as up to 12 times faster for large single systems, with sub-linear batch scaling delivering more than a 100 times graph construction speed-up for large batches of small systems. That second number is the interesting one for a lot of research work, because the common case is not one big system but hundreds of small ones, and in that regime the cost is dominated by building graphs one at a time on the CPU. The batching story is built on TorchSim, installed as an optional dependency with pip install torch-sim-atomistic, and the model wrapper is OrbTorchSimModel.

import ase
import torch
import torch_sim as ts
from ase.build import bulk

from orb_models.forcefield import pretrained
from orb_models.forcefield.inference.orb_torchsim import OrbTorchSimModel


device = "cpu"  # or device="cuda"
# or choose another model using ORB_PRETRAINED_MODELS[model_name]()
orbff, atoms_adapter = pretrained.orb_v3_conservative_inf_omat(
  device=device,
  precision="float32-high",   # or "float32-highest" / "float64
)

atoms1 = bulk('Cu', 'fcc', a=3.58, cubic=True)
atoms2 = bulk('Si', 'diamond', a=5.43, cubic=True)
atoms_list = [atoms1, atoms2]
ts_state = ts.io.atoms_to_state(atoms_list, device, dtype=torch.get_default_dtype())

ts_model = OrbTorchSimModel(orbff, atoms_adapter)
results = ts_model(ts_state)
results["energy"]

The path is to convert a list of ASE atoms into a single TorchSim state, run the model over that batch, and read results back. The same module is used for geometry optimisation and molecular dynamics. There is also an ALCHEMI-based D3 dispersion correction module, which handles the long range dispersion that most short range machine learning potentials omit, and the pyproject file packages a parameter file for it as package data. The dev dependency list also includes torch_dftd, which is a separate reference implementation of dispersion used in testing.

Finetuning, the reference energies file, and the limits of a learned potential

The repository contains more than the pretrained weights, and two of the extra pieces are worth knowing about. There is a FINETUNING_GUIDE.md and a finetune.py script at the top level, so the package expects that you may want to adapt a model to your own system rather than use it off the shelf. And there is an example_reference_energies.json file, which suggests the test suite compares against reference energies for example systems. That combination, a finetuning path and reference comparisons, is what separates a research artifact from a demo. The limits of the approach are worth stating as well, and they are the standard ones for machine learning potentials. A learned potential is accurate in the region of configuration space it was trained on and degrades outside it, quietly rather than loudly, which means an MD run that leaves the training distribution can produce plausible looking nonsense. The models here cover a wide range of chemistries, but wide is not the same as everything, and the presence of a specific orbital dataset for molecules suggests the earlier models were crystalline. The other limit is that the error metrics quoted in the README are against a reference functional, so a comparison against a different functional will not reproduce those numbers exactly, and the right workflow is to test the model on your own system against whatever reference you trust before generating a large dataset with it.

Licence, release cadence and where the limits are

The project is licensed Apache-2.0, which is a permissive licence and appropriate for a package that ships trained weights alongside code, since it lets you use the models in commercial and research settings without the copyleft obligations that would complicate a model artefact. The release history is regular, with v0.7.0 on 2026-05-26, v0.6.2 on 2026-03-18 and v0.6.1 on 2026-03-11, and the last push to the repository was on 2026-09-26 with the repository not archived, so work continues after the last tag. The version numbers under 1.0 signal that the API may still move, and the README says so in a way that is easy to miss, since the usage examples are designed to run on the main branch and a pip installed version may behave differently, with the advice to consult the README from the corresponding tag. The Dockerfile gives you a CUDA-enabled path, based on the pytorch runtime image with CUDA 12.6, installing the package with pip and a cuML build. Windows remains the practical limit, since the README says support is not guaranteed, and since the GPU paths lean on NVIDIA tooling that is not going to be there either. For a package whose value is speed on large batches, that constrains who can realistically adopt it.

Editorial conclusion

Adopt orb-models if you are running atomistic simulations and want a pretrained potential that covers metals, molecules and polymers without training one yourself, and if your workload is batched enough to benefit from the TorchSim path. Skip it if you need Windows support, which the README does not guarantee, or if you need exactly the energy conventions of a specific DFT code, since these are learned potentials with their own error characteristics. Verify first which model matches your system, that the precision setting fits your energy scale, and that the reported error metrics for the domain you care about are within your tolerance before you run a production study.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. orbital-materials/orb-models on GitHub
4. README
5. Releases