DiffEqFlux.jl: neural ODE layers that match Lux and Flux

Putting ODE solvers inside the layers of a network

DiffEqFlux.jl, also called DiffEq(For)Lux.jl, fuses differential equations with machine learning by helping users put diffeq solvers into neural networks. The package uses DifferentialEquations.jl and Lux.jl as its building blocks, and its stated purpose is to support research in scientific machine learning, specifically neural differential equations, so that physical information can be added into traditional machine learning. The package description is blunt about the scope: it is for implicit layer machine learning, and the architectures it provides match the interfaces of machine learning libraries such as Flux.jl and Lux.jl, so that continuous-time layers can be dropped into larger machine learning applications. The audience is a scientific computing team writing in Julia who needs the solver inside the model rather than bolted on around it.

The catalogue of layers and what each one models

The layer catalogue is the substance of the package. It includes Neural Ordinary Differential Equations, collocation-based Neural ODEs, multiple shooting Neural ODEs, Neural Stochastic Differential Equations, Neural Differential-Algebraic Equations, Neural Delay Differential Equations, Augmented Neural ODEs, Hamiltonian Neural Networks with specialised second order and symplectic integrators, and continuous normalizing flows including FFJORD. The repository topics mirror that list, naming neural ODEs, neural PDEs, neural SDEs, neural DDEs, neural jump diffusions and physics-informed learning. Two entries deserve special attention because they change the cost of a run. Collocation-based Neural ODEs solve the differential equation without a solver, which the README calls by far the fastest way, and multiple shooting trades a single trajectory for segments that are easier to train.

Four ways to fuse equations and networks

The README explicitly invites you to explore different integrations of the two methodologies rather than accept the current one. It lists four. Neural networks can be defined where the activations are nonlinear functions described by differential equations. Neural networks can be defined where some layers are ODE solves. ODEs can be defined where some terms are neural networks. And cost functions on ODEs can define neural networks. Each of those four placements puts the solver somewhere different in the training loop, which changes both the gradients you get and the way you debug a model. The package description also mentions high order, adaptive, implicit, GPU-accelerated and Newton-Krylov methods, so the solver configuration is a parameter of the layer rather than a fixed choice. For concrete examples the README points to the 2019 release blog post and to a separate write up on neural jump SDEs, jump diffusions and neural PDEs.

Collocation for speed, a solver when you need the trajectory

The choice between the collocation-based layer and the solver-based layer is the practical decision inside the package. The collocation variant does not use a solver at all, so there is no adaptive time stepping and no ODE solve in the training loop, and the README describes it as by far the fastest way to build a Neural ODE. The solver-based variants keep the full machinery of DifferentialEquations.jl, with high order, adaptive, implicit and GPU-accelerated methods, and that is what you need when you want the actual solution trajectory rather than a fitted representation of it. Continuous normalizing flows and FFJORD belong to the same family of reasoning: they need the solution, because the flow map is defined by integrating the differential equation. Multiple shooting sits in between, splitting the trajectory so that training is better conditioned.

v3 and v4 moved most of the API out of the package

The upgrade path is where this project will cost you time, and the README keeps a breaking changes section for it. In v3 the Flux dependency was dropped entirely. Flux is no longer re-exported, Lux is re-exported instead, and if a non Lux AbstractLuxLayer is passed the package tries to convert it automatically with FromFluxAdaptor()(model), which is also how the package maintains backwards compatibility with Flux.jl. In v4 the removals are larger: TensorLayer is gone in favour of Boltz.Layers.TensorProductLayer, the basis functions in DiffEqFlux moved to the Boltz.Basis module, SplineLayer moved to Boltz.Layers.SplineLayer, and both NeuralHamiltonianDE and HamiltonianNN moved, the latter to Layers.HamiltonianNN. Lux and Boltz were updated to v1 at the same time. The v3 notes also record that NeuralDAE now accepts an optional du0 as input and that many layer construction APIs changed.

The alternative is assembling the solver yourself

The realistic alternative to this package is not another library but writing the layer yourself. Because the package is built on DifferentialEquations.jl and Lux.jl, a team can define a custom Lux layer that calls a solver directly, and keep full control over the ODE solve, the loss and the training loop, without depending on the catalogue of layers here or on its breaking changes. What DiffEqFlux.jl buys you is the prebuilt pieces and the interface match: architectures such as continuous normalizing flows, FFJORD, Hamiltonian networks with specialised integrators, multiple shooting and augmented Neural ODEs are already written against the Lux and Flux interfaces, so they drop into an existing model. The trade is version coupling, since those layers are exactly what v3 and v4 moved or removed. For a one-off experiment the hand written layer is often less work; for a research codebase that swaps the architecture often, the catalogue is worth the dependency.

Documentation, packaging and the release line

The project publishes two documentation builds. The stable documentation at docs.sciml.ai/DiffEqFlux/stable is the version to follow for released code, and the in-development documentation at docs.sciml.ai/DiffEqFlux/dev carries the unreleased features, which is the place to look before the next release lands. The package is a Julia package in the usual layout, with Project.toml at the top level, sources under src/, extension packages under ext/, tests under test/, benchmarks under benchmark/ and documentation under docs/. CITATION.bib sits at the root, which matters if you intend to cite the package in a paper, and the licence field on the repository says MIT. On maintenance, the releases are frequent and on the v4 line: v4.10.2 on 2026-08-31, v4.11.0 on 2026-09-07 and v4.12.0 on 2026-09-29, with the last push to the master branch on 2026-10-18.

Editorial conclusion

Adopt DiffEqFlux.jl when your research question needs a differential equation inside the network rather than beside it, and when you already build models in Lux, since the layers are written to the Lux interface and Flux models can be wrapped with FromFluxAdaptor(). Do not adopt it if you want a stable long lived API without tracking major versions, because v3 dropped the Flux dependency, v4 moved TensorLayer, SplineLayer and HamiltonianNN into Boltz, and the README lists those removals as breaking changes. Verify first which major version your code targets, whether Boltz.jl and Lux.jl v1 are compatible with your environment, and whether the layer you need exists in the current release rather than in the version you remember.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. SciML/DiffEqFlux.jl on GitHub