DSGE.jl: the New York Fed model, and the code around it

The Fed's model and the code to fit any model

The description is precise about the two things the package does, and it matters that they are different things.

The package implements the New York Fed dynamic stochastic general equilibrium model, and it provides general code to estimate many user-specified DSGE models. So the specific model is a worked example, and the estimation framework is the product.

The provenance is clear. The package was introduced in a Liberty Street Economics blog post, and the Julia implementation mirrors the MATLAB code included in an earlier blog post on the Fed's model forecast. The readme adds that the model was previously referred to as the FRBNY DSGE Model, which is the sort of note that saves a search.

The current model version is 1002, and the readme points at a separate documentation file for it, a PDF describing the most recent model version, distinct from the code documentation. That separation is the right one, because the model is a scientific object with its own revision history and the code is a library, and they change at different rates and for different reasons.

For a user arriving from the model rather than from the code, the readme recommends reading the example scripts alongside the documentation, because the examples make the documentation easier to comprehend. The examples directory is substantial, with scripts for a default run, for a vectorised model, for a model with a different solution method, for forecasts and their decomposition, for regime switching, for imperfect awareness with a monetary policy rule, for an example of the system visualizer, and one for the sequential Monte Carlo sampler.

The wider New York Fed stack, in separate packages

The readme describes a family of packages, and it is worth seeing the whole family, because the pieces are separable in a way that lets you use one without the others.

StateSpaceRoutines.jl provides the filtering and smoothing algorithms. SMC.jl provides an implementation of sequential Monte Carlo sampling used for the estimation of the models. And ModelConstructors.jl defines the foundational abstract model type, from which the model type derives.

That last one is the design decision that makes the framework general. If the type your model derives from lives in its own package, then your model is a package that depends on it, and the estimation machinery is something you can extend without forking the main package.

The team is also extending the code to solve and estimate heterogeneous agent models, which is a substantial step up in difficulty from a representative agent model, and further extensions may be released at the discretion of the New York Fed. That phrasing is worth noticing, because it means the extension points are real but the roadmap is not promised.

The repository layout matches. There is a source directory, a test directory, a documentation directory, an examples directory, a benchmarks directory, a directory for saved output, a news file, a project manifest, a catalogue description file and a contributing guide.

Installing it, and the data key you will need

The installation is a registered package in the General registry, so it installs the ordinary way.

pkg> add DSGE

The detail that will cost you an hour if you do not know it is the data key. If you use any code that loads data, for example the default run script and the packet-building script, you need a key for the economic data service, obtained by following the instructions for the package that fetches it.

That is a real dependency in the practical sense even though it is not a package dependency, because the scripts that produce a forecast need series that come from an external service. It is the kind of thing that is obvious once you have read the readme and confusing when you hit it, since the error will be about authentication rather than about the model.

The package also ships two documentation builds, a stable one for the most recent release and a development one for the most recent updates, which is a thoughtful arrangement for a package where the code and the model move independently.

For anybody who wants to read the code rather than just run it, the readme points at a separate page explaining how to run the existing models, and at the example scripts as the recommended starting point.

The Windows caveats are stated plainly

The installation section has a paragraph about Windows that is worth quoting in substance, because it is more honest than most projects manage.

If you are on Windows and you hit an assertion error about the length of a list being one, the readme points at a known issue in the package manager. It also asks you not to run the plotting test on Windows, because the generated output violates the default filename length restriction there, and it explains how to enable long paths if you want to run it anyway.

And then the sentence that settles the question: the code is not tested in Windows, so it cannot be guaranteed to work properly there.

The reason this reads as a strength rather than a weakness is that the guidance is specific. It does not say Windows is unsupported and leave you there. It names the error, the cause, the workaround for the test, and the setting you can change, and then it tells you the truth about the level of testing. An evaluator can make a decision with that, which is not true of a project that simply omits the topic.

For a research package that runs on the machines of a research group, and where the plots are the output, that is a reasonable position. For a package that needs to run on a general audience's Windows laptop, it is not.

Versioning, and the move to a newer Julia

There are two version stories here, and they are separate.

The first is the package's own compatibility statement. It is currently compatible with the 1.x series of Julia, as of a particular patch release, and for older Julia lines the readme gives you the exact tag to check out, including the instruction for people who have already cloned the repository to check out the tag rather than fetch it.

The second is a note at the very top of the readme, dated July 23rd 2026, saying that the main branch has moved over to a newer Julia release, with a note that if bugs come up you should contact the named people at the Fed's domain, and that a version for an older Julia is available on a separate branch.

The release history is consistent with a package that versions its work in step with the ecosystem rather than in step with its own features. The newest tagged releases are version 1.2.0 and 1.2.1 on the same day in January 2021, and 1.3.0 in November of that year, with the last push on 2026-09-21 and the repository not archived.

So the source moves and the tags do not. For a user that means the documentation badge for the development version is the one to read, and for a user pinned to an older Julia the branch names are the thing to know about.

Precompilation is off on purpose

There is a section with a technical decision in it that looks like a workaround and is not.

The package is not precompiled by default, and the reason is given: when running code in parallel, the authors want to re-compile the copy of the package on each processor, to guarantee that the right version of the code is being used. If users do not anticipate using parallelism, they ought to change one line of the source file.

isdefined(Base, :__precompile__) && __precompile__(false)

which becomes:

isdefined(Base, :__precompile__) && __precompile__(true)

This is the kind of detail that separates a research package written by people who have been burned by a specific bug from one that has never been burned by it. The failure mode here is subtle: with several workers and a precompiled cache, a worker can pick up a cached version of the package that does not match the source tree it was launched from, and the resulting error looks like a numerical inconsistency rather than a stale artefact.

The cost of the decision is that every run recompiles the package, which is slow. The authors have therefore left the switch as a documented one-line change rather than a configuration option, which is a reasonable trade for a package whose whole job is to produce reproducible numerical results.

The licence is a good match for the use. It is BSD-3-Clause, and the disclaimer in the readme spells out what you may do: reproduce, use, modify, make derivative works of and distribute the code in whole or in part, provided you keep the notice in the documentation of any distributed work. The name of the Federal Reserve Bank of New York and the names of the authors may not be used to endorse or promote derived works without prior written permission, and third party portions remain subject to their own licences.

Editorial conclusion

DSGE.jl suits a researcher who wants the New York Fed's model and the surrounding estimation code, in a language that is fast enough to iterate on, and who is prepared to read the model documentation rather than take the defaults on trust. It is a poor fit if you need the current model version's data pipeline to run on Windows, which the readme explicitly does not test, and a poor fit if you need the package to precompile, since that is turned off on purpose. Before you start, read the model documentation for the version you are using, get a data key for the series your scripts load, and check the branch that matches your Julia version.

Frequently asked questions

Official sources

1. FRBNY-DSGE/DSGE.jl on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases