Flye assembles noisy long reads on a repeat graph

Reads in, polished contigs out

Flye is a de novo assembler for single-molecule sequencing reads, such as those produced by PacBio and Oxford Nanopore Technologies, and it is designed for a wide range of datasets from small bacterial projects to large mammalian-scale assemblies. The package represents a complete pipeline, taking raw PacBio or ONT reads as input and outputting polished contigs, so a user does not assemble with Flye and then have to find a separate polisher. There is also a special mode for metagenome assembly. The installation route is a BioConda package, and the manuals are split into an installation document, a usage document and a frequently asked questions document, which is the arrangement you would expect from a tool whose users are running it on data that takes a hundred hours to assemble and cannot easily experiment.

Why a repeat graph and not a de Bruijn graph

The README explains the core data structure directly. Flye uses a repeat graph as the core data structure, and compared to de Bruijn graphs, which require exact k-mer matches, repeat graphs are built using approximate sequence matches and can tolerate the higher noise of SMS reads. The edges of a repeat graph represent the genomic sequence and the nodes define the junctions, and each edge is classified as unique or repetitive. The genome traverses the graph in an unknown way, so each unique edge appears exactly once in that traversal, and the repeat graphs reveal the repeat structure of the genome, which helps to reconstruct an optimal assembly. The worked example in the documentation is a bacterial assembly with two unresolved repeats, one with a multiplicity of two and a length of 35k and a repeat cluster of multiplicity three and a length of 34k to 36k, and the note that because the repeats remained unresolved there are no reads covering them in full, and five unique edges correspond to five contigs in the final assembly. One more detail matters for anyone reading the graphs, since each edge is represented in two copies, forward and reverse complement, because the orientation of the input reads is unknown.

Haplotypes are collapsed, and the tools around it

There is a limit on what Flye gives you, and the README states it in the first person. Currently, Flye will produce collapsed assemblies of diploid genomes, represented by a single mosaic haplotype, and to recover two phased haplotypes you should apply HapDup after the assembly. For heterozygous bacterial genomes or metagenomes, the suggestion is to use strainy to call and quantify heterozygosity and reveal collapsed strains. So the sensible workflow for a diploid project is a two step one, with Flye doing the assembly and a separate tool resolving the haplotypes afterwards, and the same applies to metagenomic work where a mixed population is collapsed into a single set of contigs.

The release history is a story of parameters

The change log in the README reads like a parameter tuning diary, which is what you would expect from an assembler whose accuracy depends on the error profile of the reads. The 2.9.6 release in May 2025 was a minor fix release where most assemblies should not change, and it fixed a rare race condition in the polishing stage and made the R10 ONT parameters with a three percent error the default for the nano-hq mode. The 2.9.5 release added Python 3.12 support and dropped Python 2. The 2.9.3 release sped up the disjointig step for nano-hq and improved the keep-haplotypes mode so it preserves more heterozygous structural variants. The 2.9 release is the big one, with better assembly of very short sequences such as plasmids and viruses that had often been missed, the new nano-hq mode for ONT Guppy5+ and Q20 reads, tightened HiFi parameters, and a series of behavioural changes, including that scaffolding is no longer performed by default, the plasmid option was discontinued because short sequence assembly had improved, and the trestle and subassemblies modes were deprecated.

The build compiles the tools it needs

The Makefile shows that Flye does not assume a toolchain is present, it builds what it needs. Include paths are exported for the bundled libcuckoo, interval_tree and lemon libraries, and for minimap2 and samtools-1.9 under the lib directory, and the link flags pull in zlib and minimap2. On arm64 machines the build sets arm_neon and aarch64, which is the NEON path for the vectorised code. The two external tools are built as separate targets, and the result is copied into the bin directory under the names flye-minimap2 and flye-samtools, so the assembler always calls its own version rather than whatever is on the path. The all target builds both and then the release build of the source tree, with profile and debug variants alongside it. The Python setup.py wraps that make invocation, and it checks for the presence of make before it starts, exiting with a clear message if it is missing. The Python requirements list is a single line, setuptools, because the Python side is a thin layer over the C++ binaries.

The benchmark table is really a cost model

The benchmark table is the most decision-relevant part of the README, because it gives you three numbers per genome: assembly size, NG50, and the CPU time and RAM the run took. The range is enormous. E. coli at 50x PacBio takes 2 hours and 2 GB of RAM. C. elegans at 40x takes 100 hours and 31 GB. Arabidopsis takes 100 hours and 59 GB. A human reference at 30x PacBio HiFi takes 780 hours and 141 GB, while the ONT versions of the same genome run to 3100 and 4000 hours. The metagenome rows are lighter, with a 255 GB HiFi sheep gut microbiome at 3500 hours and 662 GB of RAM, which is the largest memory figure in the table. Read as a cost model, the table says the difference between a laptop and a cluster is the difference between a bacterial project and a mammalian one.

Documentation, licence and the current state

The repository is laid out as a mixed language project, with src/ holding the C++ implementation, flye/ the Python package, lib/ the bundled dependencies, bin/ the built tools, docs/ the manuals, and a Makefile and setup.py at the root. The docs directory holds the installation, usage and FAQ documents the README links. The version in the README is 2.9.6, released on 2 May 2025, with the previous releases 2.9.5 in August 2024 and 2.9.4 in May 2024, and the last push to the repository on 2026-04-03, on a branch named flye. The setup file header records the package as released under the BSD license and the project listing records a custom licence that GitHub cannot classify, so the LICENSE file is the one to read before redistributing a build. The README also points at two companion tools by other authors, AGB and Bandage, for visualising the repeat graphs that Flye produces.

Editorial conclusion

Flye fits a sequencing team assembling a bacterial genome on a laptop or a metagenome on a cluster, and the repeat graph is the reason it works on noisy reads without a separate error correction step. It does not fit someone who needs phased haplotypes from a diploid, because the assembly is collapsed into a single mosaic haplotype and a second tool is needed. It does not fit a group without the CPU budget the benchmark table implies, since a human genome is measured in thousands of CPU hours. Before you plan a run, read the benchmark table for your genome and depth, check the assembly mode you need, and note the release state, where 2.9.6 was published on 2025-05-02 and the last push was on 2026-04-03.

Frequently asked questions

Official sources

1. Issues
2. mikolmogorov/Flye on GitHub
3. README
4. Releases