QuantEcon.jl is the Julia package for quantitative economic modelling

A Julia package for quantitative economic modelling

QuantEcon.jl is the Julia implementation of the QuantEcon routines, and the repository describes itself simply as code for quantitative economic modelling in Julia. The package is called QuantEcon, and it is distributed through the Julia package manager rather than as a vendored directory of scripts.

The library has its own site, quantecon.org/quantecon-jl/, and the README points at the QuantEcon lecture site, lectures.quantecon.org, as containing many examples of the library in action. That is the resource to read before deciding anything, because the lecture pages show the library being used in worked problems rather than described in the abstract, and the repository itself is deliberately light on prose.

The audience is quantitative economists and researchers who already know the modelling framework and want it in a Julia workflow. The value proposition is not new mathematics but the same routines in a language that fits an existing stack.

Installation is a single Pkg command

The install path is the shortest section in the README. You open the Julia package manager, Pkg, and add the package, which is the standard mechanism for pulling a registered Julia package into an environment:

	add QuantEcon

There is no separate build step, no vendored binary and no system dependency to satisfy before the package is usable, because the Julia package manager resolves the dependency graph and its compat bounds for you.

One thing to plan for is that this is a moving target at the minor version level. The recent releases are v0.20.0 on 2026-10-10, v0.19.0 on 2026-08-02 and v0.18.0 on 2026-07-13, so the package is being versioned deliberately and often. That is good news for reproducibility and it means an environment file in your project should record the version you validated against, rather than tracking whatever Pkg resolves on a fresh machine.

Two documentation tracks, stable and dev

The README links two documentation builds, one marked stable and one marked dev, hosted on GitHub pages for the package. The distinction is standard for a Julia package and it matters more here than usual, because the site the project itself promotes, quantecon.org/quantecon-jl/, is a separate destination from the API reference.

The stable documentation corresponds to a released version, so it is the one to read when you are pinning a version for a project. The dev documentation tracks the current state of the default branch, which is master, and can therefore describe functions that are not yet in a release, or signatures that are about to change. The repository root also holds a mkdocs.yml, so the site is generated from the docs directory in the tree, and a CHANGELOG.md sits alongside it, which is the file to consult when you move between versions.

For an academic user, the practical routine is simple: read the stable API docs, check the changelog between the version you use and the version you plan to move to, and consult the dev docs only if you are contributing or tracking unreleased work.

The repository layout tells you what is maintained where

The top-level entries describe a package under active engineering. There is a Project.toml for the package definition, a src directory for the implementation, a test directory, a benchmark directory, a docs directory, an ext directory, a data directory, an examples directory, an other directory, and mkdocs.yml for the site build. A todo.TODO file sits at the root, alongside AGENTS.md and CLAUDE.md, which are instruction files for automated coding assistants working in the repository rather than documentation for users.

Two of those directories are worth a second look because they say something about how the package is built. A separate ext directory is where Julia package extensions live, which is the mechanism for optional integrations that load only when their dependencies are present, so this package can carry integrations without forcing them on every user. A benchmark directory indicates that performance is measured as part of the development loop rather than left to users to guess.

The examples directory is small enough to name. It holds two files, finite_dp_og_example.jl and ifp_transient_shocks.jl, whose names point at a finite dynamic programming example and a model with transient shocks. Two example files is a thin sample, and the lecture site is where the wider set of worked examples lives.

Continuous integration and coverage are wired into the repository

The README shows a build status badge pointing at a CI workflow file, workflows/ci.yml, and a codecov badge for the master branch. Together they say that the package is tested automatically on changes and that coverage is tracked over time, which is the minimum you want from a library other people will depend on for research code.

The test directory in the repository is where that happens, and the presence of a benchmark directory alongside it suggests the two run for different reasons: tests to assert behaviour, benchmarks to catch performance regressions. The two example files under examples are separate from both, since they are there to be read and run by a person learning the library.

None of this tells you how large the test suite is or how the examples are validated, and the README does not describe a benchmark command you can run yourself. If you want to reproduce the performance picture before committing to the dependency, the CI workflow file and the benchmark directory are the places to look, not the README.

BSD-3-Clause, with three conditions you can read in the README

The licence is BSD-3-Clause, and the README reproduces the full text, which is unusual and helpful. Redistribution in source and binary form is permitted, with or without modification, subject to three conditions. Source redistributions must retain the copyright notice, the list of conditions and the disclaimer. Binary redistributions must reproduce the copyright notice, the list of conditions and the disclaimer in the documentation or in other accompanying files of the distribution. And neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from the software without prior written permission.

Read as a practical matter rather than as legal advice, the first two conditions are about attribution and the third is about endorsement, and none of them is copyleft. There is no requirement to open-source a project that uses the package, which is what makes this licence straightforward for commercial and closed work.

The licence file itself is LICENSE.txt at the root of the repository. If you ship the package inside a larger product, the second condition is the one to watch, since a binary distribution has to carry the notice.

The alternative is writing the routines into your own module

The realistic alternative to depending on this package is to implement the routines yourself, inside a module you own, which is a decision that comes down to who maintains the code and what you need from it.

The difference in approach is concrete. A packaged implementation gives you a versioned dependency resolved by Pkg, documentation in stable and dev builds, a changelog, tests and a benchmark suite, and upstream fixes when someone reports a bug. Rolling your own gives you the ability to change the algorithm, drop the parts you do not need, and match the code exactly to your model's conventions, at the cost of correctness, documentation and testing becoming your problem.

The middle option that this repository supports is to use the package as a dependency and wrap it. The ext directory shows the package already separates optional integrations, so a project can build on top of it without forking it, and the lecture site shows the routines being combined into larger analyses, which is the pattern to copy if you want the library's maintenance without its conventions.

Maintenance state: frequent releases, no archived notice

The repository is not archived, and the last push was on 2026-10-10, the same day as the v0.20.0 release. The release cadence is visible in the three most recent tags: v0.18.0 on 2026-07-13, v0.19.0 on 2026-08-02 and v0.20.0 on 2026-10-10, which is a pattern of small-version increments across a few months rather than infrequent large ones.

That kind of versioning is what you want in a research dependency, because a model that depends on a numerical routine has to be reproducible, and a patch-level change in a solver can in principle change numbers in a paper. The CHANGELOG.md at the root is the file to read when upgrading, and the stable documentation gives you the API that matches a released version rather than the head of the branch.

The open question for a project pinning this dependency is the one that applies to any zero-major package: the version numbers stay below 1.0, and the compatibility policy the package declares in its Project.toml is the contract you should read before you rely on an update arriving without a breaking change.

Editorial conclusion

QuantEcon.jl is the right dependency for a Julia project that needs the QuantEcon routines and wants them from the standard package manager, with documentation in both stable and dev flavours and a changelog to plan upgrades against. It is the wrong choice if you need an API this repository does not describe, since the README covers installation, documentation and licensing rather than function-level detail, and you will have to read the published API docs to know what is inside. Before you depend on it, check three things: that the routines you need are present in the version you will pin, that your Julia environment can take the dependency without dragging in a conflicting one, and that the version you record matches the v0.20.0 release from 2026-10-10 rather than the dev branch, since the dev documentation tracks unreleased code. The licence is BSD-3-Clause and the last push was on 2026-10-10.

Frequently asked questions

Official sources

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