GEMORNA ships three generators and two predictors behind one script, and its checkpoints arrive through git-lfs

One generate.py covers three modes and three checkpoints

The generation interface is a single script with a mode flag, and the mode decides which task and which weights you get. For a coding sequence the checkpoint is checkpoints/gemorna_cds.pt and the protein sequence is passed in with a protein_seq argument. For a 5 prime untranslated region it is checkpoints/gemorna_5utr.pt with a utr_length argument, and for a 3 prime untranslated region it is checkpoints/gemorna_3utr.pt with the same argument. So a full construct, coding sequence plus both UTRs, is three invocations rather than one, and nothing in the interface chains them together for you. That is worth knowing before you imagine a single command producing a complete transcript: the tools are separate by design, because the UTRs and the coding sequence are distinct design problems with distinct objectives inside the same package.

utr_length takes three words and nothing else

The one non-biological argument in the whole interface is utr_length, and its domain is tiny: short, medium or long, as the README states in a note of its own. Those three values are what stand in for a target length, so specifying a precise number of nucleotides means stepping outside what the documented interface offers. That is a deliberate-looking simplification rather than an oversight, since UTR design is usually framed as a length band rather than an exact figure, and the bands keep a single checkpoint serving the whole range. If your application needs a hard length constraint, you generate inside a band and filter afterwards, which is also why the statement that each run produces different variants matters: it gives you the sample density to filter with.

Prediction loads different checkpoints from generation

The two UTR predictors are separate scripts, and their checkpoint filenames do not match the ones the generators use. Generation of a 5 prime UTR goes through generate.py with checkpoints/gemorna_5utr.pt, while prediction goes through main_pred5UTR.py with checkpoints/5utr.pt. The same pattern holds on the 3 prime side, where generate.py reads checkpoints/gemorna_3utr.pt and main_pred3UTR.py reads checkpoints/3utr.pt. Both predictors take a sequence and print an assessment of it, so the pair is a round trip: generate candidates, then predict properties of sequences you already have, including ones from elsewhere. Anyone scripting around this should note that the four names are all distinct and that a path used for one task will not work for the other.

A plain clone leaves you without the weights

The install sequence starts with git-lfs, and it is the first step for a reason:

sudo apt-get install git-lfs
git lfs install
git clone https://github.com/RainaBio/GEMORNA.git
cd GEMORNA/
conda env create -f environment.yaml
conda activate gemorna

The checkpoints directory at the top of the repository is where the model weights live, and they are large enough to be stored with Git LFS, whose .gitattributes file is one of the repository's top-level entries. A clone performed without the lfs step gives you pointer files rather than weights, and the failure surfaces later as a missing or unreadable checkpoint argument. After that, the environment is created from the provided environment.yaml rather than from a hand-built list, which is the recommended route even though the dependency versions are also written out in the README. Linux is the recommended platform for running the software.

Nine pinned dependencies, and torchtext is the odd one out

The dependency list is fully pinned, which makes the supported environment unambiguous: Python 3.10, numpy 1.26.4, pandas 2.0.2, tqdm 4.66.5, torch 2.2.0, torchvision 0.17.0, torchaudio 2.2.0, torchtext 0.6.0 and biopython 1.72. Most of that is a coherent PyTorch 2.2 stack. torchtext at 0.6.0 is not: it sits at a version line an order of magnitude behind the torch release it sits next to, and it is the kind of pin that tells you the environment was assembled rather than resolved. If you plan to share an environment with other work, expect the conda file to be the constraint. biopython is the other one to note, since sequence handling in a bioinformatics tool is exactly what it is there for, and pandas and tqdm handle tabular output and progress reporting.

Each run returns different variants, and that is the feature

One sentence in the README settles how the tool is meant to be used: each run generates different sequence variants, providing users with diverse candidates. That reframes the interface from a converter into a sampler. You are not asking for the optimal coding sequence for a protein, you are drawing from a distribution the model has learned, and two invocations with the same protein_seq produce different output. It also means the workflow needs a selection step downstream, whatever that looks like in your setting, since nothing in the documented interface ranks the variants it returns. The examples make the point by running exactly the same commands a user would run themselves, with a full protein sequence and with the short and long UTR settings, rather than showing a curated result.

Zero-shot generation, and both linear and circular forms

Two scope statements define what the models are being asked to do. The generation is described as zero-shot, and the package supports both linear and circular mRNA design. Zero-shot here means no fine-tuning step is documented for your protein or your application, so the checkpoints are used as shipped, which is what makes the same command work for an arbitrary protein_seq. The circular option matters for anyone working on self-amplifying or circular constructs, since it changes the design problem rather than just the output formatting. What is not described is any mechanism for conditioning the model on additional constraints, no guidance on how to steer a run, and no evaluation code, so the repository is best read as the weights and the inference scripts rather than as a training framework.

The comparative claims belong to a 2025 Science paper

The repository describes itself as experimentally validated, verified in cell-based and animal studies across a broad range of therapeutic applications, with results that consistently show GEMORNA-derived sequences outperforming leading designs in expression, durability and potency. Those are the authors' claims about their own work, and the citation block at the end of the README says where to read them: an article in Science from 2025 titled Deep generative models design mRNA sequences with enhanced translational capacity and stability, first-authored by Zhang, He with a long author list. What this repository adds is software access, and it says so: it hosts the most up-to-date version and is recommended as the primary source for software access and future updates. Practically, the tree is small, README.md, LICENSE, src, checkpoints, vocab, environment.yaml and a .gitattributes.

Editorial conclusion

GEMORNA suits a team that needs candidate mRNA sequences with more than one option per run, since the design intent stated for the tool is diverse candidates rather than a single answer, and since coding sequences and both untranslated regions are handled by the same entry point. Three things to check before you build on it. The checkpoints are tracked with git-lfs, so a plain clone leaves you without weights and the install sequence has to include the lfs step. The Python stack is pinned hard at 3.10 with torch 2.2.0, and torchtext sits at 0.6.0, which is far behind the rest of that stack and worth testing against your own code early. And the comparative claims about expression, durability and potency come from a 2025 Science paper rather than from anything you can run here, so read the paper before you quote the numbers.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases