RepoAnthropicAnthropicpublished Sep 17, 2026seen 3w

anthropics/uplifting-biomolecular-modeling

Python

Open original ↗

Captured source

source ↗

anthropics/uplifting-biomolecular-modeling

Language: Python

License: Apache-2.0

Stars: 128

Forks: 19

Open issues: 4

Created: 2026-09-17T06:37:30Z

Pushed: 2026-09-17T17:31:32Z

Default branch: main

Fork: no

Archived: no

README:

Inference optimization kits

36 drop-in optimization kits for the inference paths of open protein- and genomics-ML tools: structure prediction and cofolding, binder and sequence design, protein and genomic language models. One kit per upstream tool.

  • Each kit lives in its own directory, next to a copy of the upstream release at a pinned version ('stock'), carried as

released; the few declared exceptions are listed in NOTICE and the kit's STOCK.md.

  • A kit engages its optimizations under a named mode when the tool starts. How you call the upstream tool does not change.
  • In 34 kits this happens inside upstream's own Python environment. The two foundry kits (rfdiffusion3, rosettafold3)

instead install a small file overlay into a second interpreter and keep a pristine interpreter for off.

  • This page describes the common case. Where a kit differs — a declared bug-fix patch applied in every mode, no container

route, no shared core, an extra run.sh command — its own README.md and STOCK.md say so.

  • Run a kit from its own README.md. Every kit README has the same shape: title block with the At-a-glance line, then

Setup, Run, Modes, Notes.

Licence: LICENSE (Apache License 2.0, for the original code) and NOTICE at the top of this tree; each kit's own LICENSE sets stock/ (the upstream project, under its own licence) apart.

Status: not maintained and not accepting contributions. This is a reference release that accompanies the "How Claude is uplifting biomolecular modeling" blog post. The code is provided as-is at the upstream versions pinned in each kit's STOCK.md; Anthropic does not plan further updates and does not accept pull requests. Issues may be filed for the record but might not receive a response. Forks are welcome under the terms of LICENSE.

Modes

One vocabulary across all kits. Each kit ships the subset listed in the table below and in its README; any other mode name is an error.

  • off — stock: the pinned upstream release exactly as published, with nothing of the kit engaged. In the run.sh kits

this is a clean subprocess; in the library-style kits it is simply your own process with the kit's variable unset.

  • exact — outputs identical to off, faster.
  • fast — small, documented numeric differences (within the tool's own seed-to-seed variation), faster still. Usually the

default where a kit ships it.

  • big — lowest peak GPU memory, for inputs the other modes cannot hold. Where a kit ships it, --n_gpu P splits one

big prediction across P GPUs of one host.

Default mode (what runs when no --mode is given):

  • usually fast;
  • exact in the kits that ship no fast, and in evo2;
  • off in atlasfold;
  • none in proteinmpnn — every call names its mode;
  • none in the library-style kits (enformer, enformer_deepmind, esmc, gpnstar; flashzoi too when driven from your

own script): _OPT=exact, or an enable() call in your script, engages the kit; with the variable unset the process runs stock.

What every kit prints (the ACTIVE line):

  • A run in a kit mode prints one [-opt] ACTIVE mode=… line (on stderr in most kits) naming what is engaged.
  • A mode that cannot engage on this machine prints [-opt] NOT ACTIVE: and exits 3. A kit never falls back

to stock silently.

Layout

Each kit directory has the same layout:

| path | what it is | |---|---| | stock/ | the upstream release at its pinned version (wheel, source archive or commit; weights pinned by digest); carried as released, never edited in place (declared exceptions: NOTICE, STOCK.md) | | opt/ | the kit's own Python package | | environment/ | the pinned software stack: Dockerfile, apptainer.def, requirements.lock (most kits) | | configs/.env | per-GPU-card settings (most kits) | | run.sh | the entry point: install, check and the kit's run commands | | README.md | how to run the kit | | STOCK.md | exact upstream version and pins, the software stack, environment variables | | CHANGES.md | what each optimization changes, by mode | | upstream_issues/ | opt-in fixes for upstream defects, off by default (only where a kit has any) |

common/opt_core/ is the shared runtime nearly every kit imports: mode resolution and the ACTIVE line, determinism helpers, memory and multi-GPU machinery, and the shared GPU kernels (FlashPairformer and the triangle-attention / triangle-multiplication kernels the structure kits use). common/opt_core/README.md describes them.

Install and run — the pattern

1. Get the kit's pinned stack in ONE of up to three ways (each kit's Setup shows which it offers):

  • A — Docker: the kit's Docker image;
  • B — Apptainer: an Apptainer image (.sif) converted from it;
  • C — Python venv: your own environment at the pinned versions, following the 'Stack' section of the kit's STOCK.md.

2. From the kit directory: bash run.sh install (--weights /weights/ where the kit has weights to fetch). This installs the kit and the shared core (editable), checks the pins, and fetches the weights through upstream's own downloader, digest-checked. Then export the weights variable as the kit's Setup shows. 3. bash run.sh check — a dry run: it resolves the mode on this machine and prints what would engage. 4. bash run.sh --config --mode … in most kits; the upstream tool's own arguments pass through verbatim. In the library-style kits your own script runs unchanged: _OPT=exact python your_script.py (or the kit's enable() call).

Prebuilt images (planned)

Prebuilt Docker and Apptainer images, with each kit and its dependencies already installed, are planned within a week of this initial release. Until then, build from each kit's environment/Dockerfile or environment/apptainer.def, as described in its README. Model weights are downloaded separately either way.

How routes A, B and C differ

Under A and B, steps 2–4 run against the image; under C they run in your own environment.

A — Docker

  • docker build makes the image; docker run --rm -it --gpus all -v … -kit:dev bash opens a shell inside it.
  • Type steps 2–4 in that shell.

B — Apptainer

  • Build the .sif file once, on any machine that has Docker (the kit's...

Excerpt shown — open the source for the full document.