Cbc: a branch-and-cut MILP solver you can also drive from Python

A MILP solver with a modelling language wrapped around it

Cbc, which stands for COIN-OR branch and cut, is an open-source mixed integer linear programming solver written in C++. It can be used as a callable library or using a stand-alone executable.

For most users the solver itself is not the interesting part, because the interesting part is the modelling layer that sits on top of it. The README lists the ways in, and the list is long. Stand-alone modelling languages and systems include AMPL natively, AIMMS through the AIMMSlinks project, GAMS through GAMSlinks, CMPL, Mathematica, Matlab through OPTI, MiniZinc, MPL through CoinMP, and R.

The Python-based route is the one most teams touch. The list names cbcpy, cvxpy, CyLP, Google's or-tools, PuLP and DiPPy, python-mip, and yaposib. Other languages have their own bridges, with JuMP for Julia and rust-lp-modeler and good_lp for Rust. Even spreadsheets are covered, through OpenSolver for Excel and OpenSolver for Google Sheets.

That reach is the practical argument for Cbc over writing your own branch-and-cut, and it is also the reason to read the README carefully rather than skim it. What you pick is not only a solver but a modelling convention, and the conventions differ: a JuMP model and a PuLP script do not compose with each other, so the modelling system you already use usually decides the solver.

Cbc was developed by John Forrest, now retired from IBM Research, and others, and is currently managed by John Forrest, Ted Ralphs, Stefan Vigerske, Haroldo Gambini Santos and the rest of the Cbc team, under the COIN-OR Foundation.

The README is generated, and the real project metadata lives in config.yml

The README carries a note that surprises people who come to it from a normal repository: it is auto-generated from config.yml using the generate_readme script, and to make changes you should edit config.yml or the generation scripts.

The config file lives in a .coin-or directory at the root, and the generation script sits alongside it. The coinbrew project has its own copy of the script, and the README links to it. So the same metadata drives the README, the release process and the dependency list, which is the COIN-OR way of keeping a family of solvers consistent.

The Dependencies section says as much. Cbc has a number of dependencies, which are detailed in config.yml, and dependencies on other COIN-OR projects are automatically downloaded when obtaining the source with coinbrew. For some of the remaining third-party dependencies, automatic download scripts and build wrappers are provided, while other libraries that are easy to obtain must be installed using an appropriate package manager, or may come with your operating system by default.

That split is the practical shape of building Cbc. The COIN-OR part of the dependency graph is handled for you, and the third-party part is partly handled and partly your problem. Anyone who has compiled an autotools based C++ project will recognise the rest of the tree: configure.ac, configure, Makefile.am, Makefile.in, ltmain.sh, install-sh, depcomp, missing, and the pkg-config templates cbc.pc.in and osi-cbc.pc.in for linking against the library from a build.

Installing is easy on Linux, macOS and conda, and less easy on Windows

The download section of the README is a quick start guide for obtaining or building Cbc on common platforms.

On Linux, the distribution packages are named differently per family. On Arch:

sudo pacman -S  coin-or-cbc

On Debian and Ubuntu:

sudo apt-get install  coinor-cbc coinor-libcbc-dev

On Fedora, Red Hat and CentOS:

sudo dnf install  coin-or-Cbc coin-or-Cbc-devel

On FreeBSD:

sudo pkg install math/cbc

On macOS the README says the easiest way is through Homebrew, which needs a tap first:

brew tap coin-or-tools/coinor
brew install coin-or-tools/coinor/cbc

Conda is the cross-platform route, and it is the shortest:

conda install coin-or-cbc

Windows is the outlier. The README says the easiest way to get Cbc on Windows is to download an archive attached to a GitHub release, and that older binaries are archived on the COIN-OR site. There is no Windows package manager recipe in the download list.

Building from source is the recommended path when you need the full feature set, and the README recommends the coinbrew script for that, since it fetches the project and all dependencies:

wget https://raw.githubusercontent.com/coin-or/coinbrew/master/coinbrew
chmod u+x coinbrew
./coinbrew fetch Cbc@master
./coinbrew build Cbc

The other route to the source is to download a snapshot of the latest release from the releases page, or to clone the repository from GitHub.

Pre-compiled binaries are missing functionality on purpose

The single most important sentence for anyone about to deploy Cbc sits at the end of the binaries section: due to license incompatibilities, pre-compiled binaries lack some functionality.

That is not a build failure and not a bug. It is a consequence of the licensing of the third-party libraries Cbc can use, and it means the binary you install from apt, conda or Homebrew may not be the binary you would get by compiling everything yourself. The README says that if binaries are not available for your platform for the latest version and you would like to request them to be built and posted, you can open a discussion on GitHub.

The practical consequence is that a packaging-based install is a starting point, not a guarantee. If a feature you need is missing, the answer is to build from source with coinbrew, which fetches the dependencies that the distribution packages left out. Anyone who evaluates Cbc only through a package manager may conclude that a capability does not exist when it does.

The same issue runs the other way, in a more awkward direction. A source build pulls in third-party libraries under their own licences, and the combination of those licences with the licence Cbc itself is released under is what makes some binaries impossible to publish. That constraint is also why the licence question below is not a formality for this particular project.

The examples directory is the map of the extension points

The repository carries an examples directory that reads as an index of what Cbc lets you do. It is more informative than the feature list, because the names are the API.

The branch-and-cut family is there: CbcBranchFollow2, CbcBranchLink and CbcBranchUser, the last of which is the user callback version, that is, a way to supply your own branching rule rather than using the built-in one. The comparison example, CbcCompareUser, is a second user-supplied strategy, which tells you the design allows more than one hook in the same place.

The solver drivers come in several shapes: CbcSolver2, CbcSolver3 and CbcSolverLongThin, each with a header, and there are older style drivers alongside them, clpdriver.cpp and cbc_driverC_sos.c, the latter handling a particular problem structure. There is a cut generator example in allCuts.cpp, a barrier method example in barrier.cpp, and a crew scheduling example in crew.cpp, which comes with its data file bell5.lot. A quadratic interface example, ClpQuadInterface, shows the solver talking to the underlying linear programming code.

That range is the real story about Cbc. It is not a black box you hand a model to, it is a solver with explicit seams, and the seams are in the public headers under src with the examples as the documentation. A team that wants to change how the search proceeds, or add its own cut, or understand why a model is slow, has the code and a worked example for each of those.

EPL-2.0, a volunteer project, and a release history measured in years

Cbc is written in C++ and is released as open source under the Eclipse Public License 2.0, and it is distributed under the auspices of the COIN-OR Foundation. Worth noting for anyone checking the repository rather than the README: GitHub's own licence classification for the repository comes out as a custom licence it could not map, with a pointer to the LICENSE file, so the EPL-2.0 statement in the README is the one to verify against the file itself.

EPL-2.0 is a weak copyleft licence. It is generally fine for linking into proprietary software, and it is common in the Java and COIN-OR worlds, but the details are worth reading rather than assuming, particularly given the licence incompatibility issue described above.

The maintenance picture comes from the release tags. There is a release named releases/2.10.13 from 2026-03-11, releases/2.10.12 from 2024-08-20, and releases/2.10.11 from 2023-10-25. The last push to the repository was on 2026-10-19.

So the code is being worked on, and the version numbering is a single 2.10 line that has been patched a handful of times over three years. The project states its own situation plainly at the top of the README: projects such as this one are maintained by a small group of volunteers under the auspices of the non-profit COIN-OR Foundation, and it asks for sponsorship or volunteering. That is an accurate description of what a COIN-OR project is, and it is the right expectation to set: a solver maintained by a handful of named people, with the academic pedigree that implies and the support commitments that a commercial solver would sell you.

Editorial conclusion

Cbc fits a team that needs a mixed integer solver they can call from a modelling language, wants to read the algorithm source, and is prepared to build from source when a platform binary is missing a feature. It does not fit a deployment that needs a single fully featured binary, because the README states that pre-compiled binaries lack some functionality due to licence incompatibilities, and it does not fit a user who wants a solver with commercial support. Before you commit, run the install command for your platform, check whether the resulting binary includes the features you need, and read the .coin-or/config.yml file, since that is where the dependency list and the project metadata actually live.

Frequently asked questions

Official sources

1. coin-or/Cbc on GitHub
2. Issues
3. README
4. Releases