Atomistic simulation requires three things: knowledge of the science, compute-efficient implementation of simulations, and accessible interfaces to the simulation stack.

The first remains the researcher’s domain, as no tool substitutes for knowing what to simulate or recognizing a physically meaningful result. NVIDIA ALCHEMI Toolkit, introduced earlier this year, has dramatically reduced the second barrier for Machine Learning Interatomic Potentials (MLIP) with composable, PyTorch-native building blocks for constructing GPU-accelerated simulation workflows with in-flight batching enabled.

The third barrier has persisted. Unlike classical force fields, the MLIP ecosystem is still nascent, and the accessible interfaces that exist for classical simulations are very limited. They run on a different software stack than the tools many computational chemists are accustomed to with new data structures, composition patterns, and dependencies.

AI coding agents offer a way through: They generate and execute code from natural-language descriptions written in the terms a researcher would use in daily technical discussions. But a general-purpose agent may not know the ALCHEMI Toolkit API, and can produce plausible-looking code that only appears to use it correctly.

ALCHEMI Toolkit agent skills and reference files provide the missing API patterns on demand, leaving the prompt to your science: the material, the conditions, and the constraints on the simulation protocol.

Building simulation workflows with a coding agent

This post follows an end-to-end ALCHEMI Toolkit workflow: what the researcher starts with, how they prompt the agent, what code and simulation pipeline it produces, and how the results are validated on NVIDIA H200 GPUs. It also distills lessons from 45 generated pipelines into practical guidance for building trustworthy GPU-accelerated simulation workflows with coding agents.

How to get started

System and package requirements

• Python ≥3.11, <3.14
• PyTorch ≥2.8
• CUDA 12 or CUDA 13, with a compatible NVIDIA driver (570+ recommended)
• Operating System: Linux (primary), macOS
• NVIDIA GPU (RTX 20xx or newer), CUDA Compute Capability ≥ 7.0
• Minimum 4 GB RAM (16GB recommended for large systems)

Installation

How you set up the agent’s environment meaningfully affects the reliability of generated code. We recommend installing the Toolkit in a runnable Python environment and letting the agent execute the scripts it generates. In the final 45-pipeline campaign, this setup produced no broken imports or references to nonexistent APIs.

Step 1: Create a Python environment and install ALCHEMI Toolkit with uv package manager:

# Installation through uv in a local folder
# Create local environment at .venv
uv venv --seed --python 3.12 
# Install ALCHEMI Toolkit  into .venv
uv pip install "nvalchemi-toolkit[mace,ase]==0.2.0" 

To run on an NVIDIA GPU, include the CUDA extra that matches your CUDA environment. For example, for CUDA 13, install nvalchemi-toolkit[mace,ase,cu13]==0.2.0.

Step 2: Download agent skills from the same release tag so they match the installed API:

# Download the nvalchemi-toolkit skills
npx degit NVIDIA/nvalchemi-toolkit/.claude/skills#v0.2.0 .claude/skills

Step 3: Install a coding agent. This benchmark used Claude Code:

# Install Claude Code through npm
npm install -g @anthropic-ai/claude-code
# Or natively through curl
curl -fsSL https://claude.ai/install.sh | bash
# Start a claude session in the local folder
claude 

Open the agent in your project directory, allow it to execute code, and start describing simulations; the agent loads the relevant skills on demand. Letting the agent run what it writes removes almost all mechanical errors before you see the script. From there, the quality is decided mostly by your prompt.

Without a runnable shell, a source git-checkout is a fallback: In earlier tests, reading the source eliminated broken imports across 617 import statements. A pip install with neither shell nor source was the weakest configuration.

Any agent supporting the open Agent Skills standard works, including Cursor and OpenCode (see the Agent Skills user guide for configuration).

Best practices for writing a good prompt

The following principles are synthesized from measurable differences in the benchmark’s output quality, not from general coding-agent advice. The five prompt levels, from least to most specified, are shown in Figure 1, below.

Name the system, method, and scale always; add a CLI contract only for unattended operation. Prompts naming the material, method, and scale scored best. Full CLI contracts achieved complete reusability, but cost about 4× more tokens and produced 2.3× more code than Sketch prompts. Spec prompts were most fragile, accounting for three of seven screening failures. Specify the science and deliverables; let the skills supply API patterns.

Name the material, phase, and reference convention explicitly. Under-specifying the system caused the clearest physics failures in earlier tests: “a transport property of a Li material” produced an argon demo, and two Cu scripts used different adsorption references, materially affecting the outcomes. The final prompts eliminate those failures by naming the material, phase, and reference convention. Protocol matters too: Scripts without a thermostat instruction used Langevin production dynamics that damped diffusion by 3-5×; requesting NVE changed every script to the appropriate measurement ensemble.

Specify the constraint, not the implementation. Describe what the script must accomplish rather than internal API classes. In a controlled comparison, naming a pipeline construct changed none of 12 implementations. The API pattern comes from the examples and skills, not the prompt. Naming internals without a complete interface contract is where fragility concentrates.

Ask explicitly for self-assessment and premise-checking. Agents did not question whether any requested property was physically well-posed. Ask explicitly for premise checks, validation, and uncertainty estimates, and require recovery of an independent known result; the agent won’t add these on its own.

Three workflows, from prompt to GPU execution

The following workflows illustrate what ALCHEMI Toolkit and a coding agent can handle end-to-end from a natural-language prompt. To ground these recommendations in measured results, we ran a systematic benchmark of 45 simulation pipelines across three workflows, five prompt levels, and three samples per level.

1. Silicon equation of state (EOS)
2. Oxygen adsorption on Cu(111)
3. Li self-diffusion molecular dynamics (MD)

Scripts were assessed two ways. Firstly, deterministic code-feature checks: property coverage (right quantity, right formula), API-pattern coverage (use of the toolkit’s batched API surface), and reusability (a parameterized, re-runnable interface). Secondly, execution on identical NVIDIA H200 GPUs as ground truth.

All 45 scripts used batched GPU execution. L2-L5 prompts required batching; L1 adopted it from the Toolkit skills and examples. We screened all scripts at demonstration scale and ran one representative per workflow and level at production settings.

Bulk silicon equation of state

The task: The equation of state of diamond-cubic silicon

The energy-volume curve whose minimum gives the lattice constant a0 and whose curvature gives the bulk modulus B0. At every prompt level the agent built the same pipeline: 50-60 strained volumes relaxed concurrently as one GPU batch, then a Birch-Murnaghan fit. All five production representatives agree to the last digit, a0 = 5.4661 Å and B0 = 88.15 GPa, inside the established all-electron PBE reference window. The lattice constant differs from the NIST experimental value, while the bulk-modulus comparison comes from McSkimin’s experimental measurements. These offsets are consistent with reported PBE behavior.  The takeaway mirrors the benchmark-wide pattern: prompt specificity changed the code’s structure and cost, never the physics.

Oxygen adsorption on Cu(111)

The task: Rank the adsorption sites for atomic oxygen on Cu(111)

The pipelines freeze the slab’s bottom layers, relax 24+ candidates across the four high-symmetry sites as one GPU batch, and compute Eads = Eslab+ads − Eclean slab − EO. Every production representative finds the fcc hollow most stable, Eads(fcc) = −4.799 ± 0.004 eV across the five levels, with the ordering fcc ≥ bridge > hcp >> top. Reported reference values are −4.31 eV at 0.25 monolayer. Copper microcalorimetry studies by Giamello et al. and Naumann d’Alnoncourt et al. reported values from −4.46 to −4.60 eV. Coverage differences and model error may contribute to the stronger binding. Millielectronvolt agreement across independent scripts is what a stated reference convention buys.

Lithium self-diffusion via molecular dynamics

The task: Estimate the self-diffusion coefficient D of liquid lithium.

The pipelines build a bcc lithium supercell, melt and equilibrate it above lithium’s 454 K melting point, propagate three temperatures times three seeds (nine replicas) as a single batched system on the GPU, and extract D from the mean-squared displacement, MSD — the average squared distance that atoms travel — whose slope over time gives D through the Einstein relation.

Technical specifications

The following configuration was used to produce the workflow examples in this post:

• Coding agent: Claude (claude-opus-4-8)
• Effort level: High
• MLIP checkpoint: MACE-MPA-0 (medium-mpa-0)
• Toolkit version pin (0.2.0)

Benchmark insights

The benchmark produced three practical findings by systematically varying prompt level, tool access, and execution capability.

Prompt specificity buys code structure. Property coverage was 1.00 at every level, so the science is right from the first prompt. What specificity brought was structure: API-pattern coverage doubles at L4-Spec (0.52 to 0.96) and full interface reusability arrives only with the L5-Contract (0.67 to 1.00) (Figure 7, below).

Agents defaulted to familiar algorithms: 38 of 45 scripts used FIRE and none used FIRE2, despite FIRE2 being documented beside it as an improved variant. What the examples and skills showcase, the agent uses; what they do not, it fills from pretraining.

Execution exposed failures that CPU self-tests could not. The runnable shell eliminated broken imports, but seven scripts still failed on GPU-specific paths. More elaborate prompts exercised more of these paths and failed more often. Self-testing improves code generation, but does not replace validation on target hardware. A generation sandbox with GPU access may close this gap, but our methodology accounts for what a typical user would do in practice: Use “Claude autorun” in the Claude app on their laptop and then submit to a GPU cluster after.

Limitations

Scientific judgment remains essential. Across every tested condition, zero configurations pushed back on a physically ill-posed task. In an earlier probe, every agent complied with a request for Li-ion diffusion in pristine crystalline LiF, a property not measurable at the simulated timescale. However, it is possible a web-equipped agent would run this check; the generation sandbox had no web access, so the agent could not have looked up whether the property was plausible. Agents also chose plausible timesteps and thermostats without assessing their suitability for the material or timescale. Agents accelerate translation from scientific intent to code, but cannot determine whether the intended simulation is physically meaningful.

MLIP foundation models are not universally accurate. The benchmark used MACE-MPA-0 (medium-mpa-0), whose accuracy varies outside its training distribution. Our silicon, copper, and liquid-lithium results are reasonable against their references, but every new chemistry should be validated against DFT or experiment. This is a model and sometimes reference DFT limitation, not an ALCHEMI Toolkit or agent limitation.

Always compare numerical results with an independent reference. The Langevin-production lithium scripts reported diffusion coefficients that were statistically impeccable yet damped 3-5× by the thermostat; only comparison against the temperature-matched experimental anchor exposes it. The check must also be independent: one script validated its unit conversion by generating synthetic data with the same wrong constant, so its self-test passed. Statistically reliable and physically meaningful can be orthogonal.

Ecosystem adoption

Several companies have been exploring the approaches we discuss in this blog. In May 2026, Matlantis, an AI-powered simulation platform used by over 150 companies and an ALCHEMI ecosystem partner, released a public Skills library on GitHub and announced a Claude Code integration for its universal simulator. BIOVIA is also leveraging NVIDIA ALCHEMI NIM in Dassault Systèmes’s AI-powered virtual companion, MARIE, to democratize access to advanced simulation capabilities and enable convenient execution of molecular simulations, empowering more scientists to develop and validate Virtual Twins of materials.

Get started building simulation workflows with ALCHEMI Toolkit and coding agents

Visit the NVIDIA/nvalchemi-toolkit GitHub repo and NVIDIA ALCHEMI Toolkit documentation.

The repository includes agent skills and more than 30 workflows across basic, intermediate, advanced, and distributed use cases.

Acknowledgments
We would like to thank Nikita Fedik, Susumu Ohno from Matlantis Corporation, and James Wescott from Dassault Systèmes – BIOVIA for their contributions to this post.