# OpenDDE: a preview co-folding engine for structure prediction and design

> OpenDDE is an Apache-2.0 all-atom biomolecular foundation model that packages co-folding into a CLI for structure prediction, design and optimization. It installs through uv or Docker, but the project labels itself a preview and warns against production pipelines.

**aurekaresearch/OpenDDE** — An Open-source Drug Discovery Engine

- Repository: https://github.com/aurekaresearch/OpenDDE
- Stars: 505 · Forks: 59
- Language: Python
- License: Apache-2.0
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/aurekaresearch-opendde

## What OpenDDE actually predicts, and for whom

OpenDDE is an all-atom biomolecular foundation model built around co-folding. The README describes it as turning co-folding into a scalable engine for structure prediction, design and optimization in drug discovery. The practical unit of work is a job: a named entry with a list of sequences, a set of model seeds, and a request for one or more sampled structures.

The intended reader is a computational chemist or structural biology group that already scripts its modelling work. The interface is a command line tool called opendde, the input is JSON, and the output goes to a directory. There is no hosted service and no homepage listed for the repository, so you run it yourself.

Two things shape expectations. First, this is a preview release, and the README says so in a callout: CLI flags, input and output JSON fields, and released checkpoints may change between versions, and predictions are not guaranteed to be reproducible across releases. Second, the packaging metadata classifies the project as Development Status 4 - Beta. Anyone treating the output as a fixed reference should read those two statements before anything else.

## The co-folding pipeline and where runtime data lives

The model does not read a single monolithic asset directory. It resolves checkpoints and runtime assets from an environment variable, OPENDDE_ROOT_DIR, which defaults to ~/.cache/opendde when unset. The README lays out the expected layout: checkpoint/opendde.pt, a common/ directory, and a search_database/ directory used for local template and RNA-MSA preprocessing.

That split matters because the search database is optional for some runs. A prediction that disables protein MSA, template search and RNA MSA does not need the large search_database/ files, and the source helper script accepts --skip-search-database for exactly that case. In other words, the expensive external data is only pulled in when you ask for the features that consume it.

Two released checkpoints are listed. opendde.pt is the general-purpose one, used with -n opendde_v1. opendde_abag.pt is tuned on antibody-antigen work and is passed explicitly through --load_checkpoint_path. The README is explicit that a checkpoint supplied this way is never replaced automatically, which is a sensible boundary: your pinned weights stay pinned.

Downloads are not left to chance. Python-managed checkpoint and common-asset downloads use a release-pinned revision, a published size and a SHA-256 check before atomic replacement. The source helper verifies released checkpoints independently. External search databases are prepared separately and are not covered by that verification path.

## Installing OpenDDE with uv and running a first prediction

OpenDDE supports CPython 3.11, 3.12 and 3.13, and the README recommends uv for the Python environment. Start by creating one, then install from PyPI. The CPU build is the shortest path:

```bash
uv venv --python 3.11
uv pip install --python .venv --torch-backend cpu opendde
```

On an NVIDIA GPU on Linux x86_64 with CUDA 12.6, install the GPU extra instead. The README notes that --torch-backend selects the PyTorch build while [gpu] adds the optional cuEquivariance kernels, so the two flags do different jobs:

```bash
uv pip install --python .venv --torch-backend cu126 "opendde[gpu]"
```

After either install, the README gives a doctor command to verify the environment. Expect a health report rather than a model run:

```bash
uv run --no-project --python .venv opendde doctor
```

If you prefer containers, the prebuilt image targets NVIDIA GPU inference and can be pulled directly. The Dockerfile sets OPENDDE_ROOT_DIR to /opendde_data and declares it as a volume, so runtime data is meant to be mounted rather than baked in:

```bash
docker pull aurekaresearch/opendde:v1
```

Now a real prediction. The README's minimal input is a JSON array with one job named tiny, a single seed, and a nine-residue protein chain. Save it as tiny.json:

```json
[
    {
        "name": "tiny",
        "modelSeeds": [101],
        "sequences": [
            {
                "proteinChain": {
                    "sequence": "ACDEFGHIK",
                    "count": 1
                }
            }
        ]
    }
]
```

Run it with the external feature searches turned off, which is what keeps the search_database/ files out of the picture. The README uses --sample 1, --step 200 and --cycle 10 for this compatibility run, and writes results to ./output:

```bash
opendde pred \
  -i tiny.json \
  -o ./output \
  -n opendde_v1 \
  --use_msa false \
  --use_template false \
  --use_rna_msa false \
  --sample 1 \
  --step 200 \
  --cycle 10
```

Defaults are applied automatically: inference runs in fp32, triangle kernels use auto dispatch, and seeds come from the job's modelSeeds unless --seeds is given. For the antibody-antigen checkpoint, keep the filename as opendde_abag.pt and pass it explicitly with --load_checkpoint_path pointing at $OPENDDE_ROOT_DIR/checkpoint/opendde_abag.pt.

## Platform gaps and the reproducibility caveat

The platform matrix is narrower than the Python version range suggests. Linux wheels require glibc 2.28 or newer. Apple Silicon runs on CPU or on the Metal (MPS) backend via --device mps. Intel macOS is unsupported, and Windows has not been validated. The GPU extra is conditional in pyproject.toml: the triton and cuequivariance packages are marked for Linux on x86_64 only, so an ARM Linux box gets the base install without those kernels.

Device selection is handled by --device auto, which prefers CUDA, then MPS, then CPU. That is convenient, but it also means a run can silently land on CPU if the CUDA path is misconfigured. Check the doctor output before blaming the model.

The harder limitation is stated by the project itself. Predictions are not guaranteed to be reproducible across releases. For a preview tool this is honest, but it has a direct consequence: a structure you generate today and a structure you generate after an upgrade are not the same artifact, even with identical input. If you need to compare runs over time, record the checkpoint revision and the package version alongside the output, because the software will not guarantee that for you.

The README also does not document rollback. There is no described procedure for reverting a checkpoint or a data layout after an upgrade, which is worth knowing before you let a pipeline pick up new versions automatically.

## Where OpenDDE sits next to AlphaFold-style tools

The pyproject.toml keyword list names alphafold3 directly, and that is the honest comparison point. AlphaFold-class releases from Google DeepMind ship as research code with their own weight downloads and their own input conventions; the practical difference here is packaging and interface. OpenDDE installs as a pip package named opendde with a single CLI entry point, exposes a JSON input schema, and ships a container image with a declared data volume. If your team already automates around command line tools, that is less glue code than adapting a research repository.

The second difference is scope. OpenDDE describes itself as a foundation model for structure prediction, design and optimization, and ships a checkpoint specifically tuned on antibody-antigen work. A general structure predictor does not usually carry a named specialization checkpoint in the same release. That said, the README does not publish accuracy comparisons against other tools, so the specialization claim is a packaging fact, not a benchmark result you can lean on.

The cost of the simpler packaging is the preview status. A mature research codebase may be slower to install but more stable in its interfaces. OpenDDE trades that stability for a clean install path and explicit version warnings. Which side of that trade you want depends on whether your work is exploratory or part of a fixed protocol.

## Licence terms and what an upgrade costs you

The project is licensed Apache-2.0, and pyproject.toml declares license = "Apache-2.0" with license-files = ["LICENSE"]. The Dockerfile carries the same identifier in its OCI label. For most internal research use that is a permissive arrangement, but the licence covers the code, not the model weights: the checkpoints are downloaded separately from Hugging Face, and the README does not state terms for them. Check the model card before any redistribution. This is a description of what the repository says, not legal advice.

Upgrade cost is the more practical question. The README's own warning covers CLI flags, I/O JSON fields and released checkpoints, so any of the three can move between versions. The release history shows three versions in roughly a month, which is a fast cadence for something you might pin in a pipeline.

The mitigation is built in. A checkpoint passed with --load_checkpoint_path is never replaced automatically, so pinning weights is a supported path. The runtime data helper script lives in the source tree and is not installed with the opendde Python package, which means a wheel install cannot run it; you either clone the repository or let opendde pred fetch the default checkpoint and common files when they are missing. Plan for the source checkout if you want the helper.

## Who should run this today

OpenDDE is a reasonable fit for a group that wants to script co-folding predictions, is comfortable with a JSON job format, and treats outputs as hypotheses to be checked by other means. The combination of a pip package, a single CLI, a container image with a data volume, and checksum-verified checkpoint downloads is a lower-friction starting point than adapting a research codebase.

It is the wrong tool if you need a frozen interface. The preview warning is not boilerplate: it names CLI flags, JSON fields and checkpoints as things that may change, and it explicitly excludes production pipelines. It is also the wrong choice on Intel macOS, which is unsupported, or on Windows, which the README says has not been validated.

Before you invest, verify three things against your own case. Confirm that your target runs under the flags you need, since disabling MSA, template search and RNA MSA changes which runtime data is required. Confirm the checkpoint you intend to use, general-purpose or antibody-antigen, and pass it explicitly so it is not swapped underneath you. Then record the package version and checkpoint revision next to every output, because the project does not promise that two releases will produce the same structure.

## Conclusion

Adopt OpenDDE if you are a computational chemist or structural biology group who wants a scriptable co-folding model and can tolerate preview-grade interfaces. Do not build a validated screening pipeline on it: the README states that CLI flags, I/O JSON fields and checkpoints may change between versions and that predictions are not guaranteed to be reproducible across releases. Before committing, verify that your target case runs under the flags you need, and pin the checkpoint revision you tested.

## FAQ

### Has protein folding been solved?

OpenDDE does not make that claim. Its README presents it as a preview release whose predictions are not guaranteed to be reproducible across releases, and it is not intended for production pipelines.

### Is Google AlphaFold free?

The README does not describe AlphaFold's terms, so no answer can be given from this project's documentation. OpenDDE itself is Apache-2.0, and its checkpoints are downloaded separately from Hugging Face.

### What is the best software for protein structure prediction?

The README does not rank OpenDDE against other predictors, so no comparison is available. What it does state is that OpenDDE installs as a pip package named opendde or as a Docker image, and exposes a single opendde CLI with a JSON input format.

### What is fold recognition and how does it work?

The README does not explain fold recognition as a concept. It does describe template search as one of the external feature searches that OpenDDE can run, and that a prediction disabling template search does not need the search_database/ files.

## Sources

- [aurekaresearch/OpenDDE on GitHub](https://github.com/aurekaresearch/OpenDDE)
- [Issues](https://github.com/aurekaresearch/OpenDDE/issues)
- [License: Apache-2.0](https://github.com/aurekaresearch/OpenDDE/blob/main/LICENSE)
- [README](https://github.com/aurekaresearch/OpenDDE/blob/main/README.md)
- [Releases](https://github.com/aurekaresearch/OpenDDE/releases)

---

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