# HiGHS solves LP, QP and MIP, with MIT and Apache binary packages

> HiGHS is an MIT-licensed C++ solver for large scale sparse linear optimization, covering linear, convex quadratic and mixed integer programs through a single interface, with pybind11 wrappers published as highspy. It fits teams that want a modern open solver without a commercial licence, and the packaging detail worth knowing is that the MIT and Apache binary releases do not contain the same code.

**ERGO-Code/HiGHS** — Linear optimization software

- Repository: https://github.com/ERGO-Code/HiGHS
- Stars: 1,912 · Forks: 381
- Language: C++
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/ergo-code-highs

## One formulation covers LP, convex QP and MIP

HiGHS solves problems of the form stated in the README: minimising a quadratic objective subject to row bounds and variable bounds, with the objective written as one half x transpose Q x plus c transpose x.

The constraint that `Q` must be positive semi-definite is what determines the problem class. With `Q` zero you have a linear program. With a positive semi-definite `Q` you have a convex quadratic program. With `Q` zero and a requirement that some variables take integer values, you have a mixed integer program.

That is a genuinely useful unification. One model format, one set of row and column bound arrays, one solver call, and the class of problem is determined by which fields you populate. A modelling layer that speaks to one solver can then send it LP, QP or MIP work without branching.

The cost of the unification is the same constraint read from the other side: non-convex quadratic objectives are out of scope, because the convexity requirement is structural rather than a setting.

The solver description in the README names the components behind it: primal and dual revised simplex solvers originally written by Qi Huangfu and further developed by Julian Hall, an LP interior point solver by Lukas Schork, a QP active set solver by Michael Feldmeier, and a MIP solver by Leona Gottwald.

## Building with CMake 3.15, then checking it with ctest

The primary supported build is CMake, and the version floor is stated: at least 3.15. Two commands produce the binary and the library:

```shell
cmake -S . -B build
cmake --build build
```

That installs the executable `bin/highs` and the library `lib/highs`. To confirm the build actually works, change into the build directory and run the test suite:

```shell
ctest
```

Running ctest after a build is worth the minute it costs. A solver that compiles but has a broken simplex iteration will still link, and you would rather find that here than on a model in production.

The project states it has been developed and tested on various Linux, MacOS and Windows installations, and the CI matrix has separate workflows for a fast build, Linux, macOS and Windows, plus a Bazel configuration in the repository with BUILD.bazel and WORKSPACE.

Two alternative builds are documented with explicit disclaimers. The Meson interface is described as community-provided and not officially supported:

```shell
meson setup bbdir -Dwith_tests=True
meson test -C bbdir
```

The nix flake provides the `highs` binary and the Python package, and can run without installing anything:

```shell
nix run .
nix run github:ERGO-Code/HiGHS
```

Both carry the same not-officially-supported caveat, and the README asks that problems with them be reported upstream rather than worked around locally.

## Solving your first model from the command line

The binary reads MPS files and CPLEX LP files. Solving a model named `ml.mps` is one command:

```shell
highs ml.mps
```

Options are split between the command line and a file. The usage block in the README shows the shape:

```shell
$ bin/highs --help
usage:
      ./bin/highs [options] [file]

options:
      --model_file file          File of model to solve.
      --options_file file        File containing HiGHS options.
      --read_solution_file file  File of solution to read.
      --read_basis_file text     File of initial basis to read.
      --write_model_file text    File for writing out model.
      --solution_file text       File for writing out solution.
      --write_basis_file text    File for writing out final basis.
      --presolve text            Set presolve option to:
```

Two of those are worth pausing on for anyone doing repeated solves. `--read_basis_file` accepts an initial basis, so a model solved slightly differently can be warm started from a previous solution instead of from scratch. `--write_basis_file` writes the final basis out, which closes the loop for that workflow. Together they turn a sequence of related models into a sequence of warm starts.

The README notes that some fundamental option values may be given on the command line and many more through `--options_file`, which is where solver tuning belongs rather than in shell history.

## highspy: Python bindings that are a thin wrapper, and Python 3.9 is the floor

The Python package is highspy, version 1.15.1, described in pyproject.toml as "A thin set of pybind11 wrappers to HiGHS".

Thin is the important word. It builds through scikit-build-core with pybind11 and numpy in the build requirements, and it ships type information: the sdist explicitly includes `pyproject.typed`, the `__init__.pyi` and `_core/*.pyi` stubs, and the classifiers include `Typing :: Typed`. So the Python API is typed even though the implementation is a binding layer.

Requirements are modest: `requires-python = ">=3.9"`, with classifiers for Python 3.9 through 3.14, and a single runtime dependency on numpy plus typing_extensions when running below 3.10. Optional extras are pytest and numpy for tests, and an extras group pinned to `highspy-extras==1.15.1`.

Because the pins match the C++ version exactly, that extras pin is a hint about how tightly the Python and native layers move together. Upgrading one without the other is not a supported combination.

The repository's examples directory shows the range of what people actually solve with it: chip.py and chip0.py for cutting stock, knapsack.py, nqueens.py, network_flow.py, distillation.py, multi_objective.py and multiple_objective.py, plus branch-and-price.py for a decomposition approach, and separate files showing the call from C, C++, C#, Fortran and Python.

## The two binary packages are not the same code

This is the detail most likely to surprise someone integrating HiGHS into a product, and the README is unusually direct about it.

Precompiled static binaries are published on the releases page, plus one package of shared libraries for Windows x64. Those binaries come in two flavours. The `*-mit` binary packages contain HiGHS and are MIT licensed. The `*-apache` binary packages contain HiGHS together with HiPO and are Apache licensed, because of the licensing of HiPO's dependencies.

So the Apache package is not a superset you get for free. It carries a different licence because it includes HiPO and the licensing of HiPO's dependencies dictates the terms, and THIRD_PARTY_NOTICES.md in the repository root is the file that documents those terms.

Which one you take depends on whether you need HiPO and whether your distribution obligations work for you. The core claim in the README is that HiGHS itself is freely available under the MIT licence and requires no third-party dependencies, so the HiPO route is an addition, not a prerequisite.

This is a licensing note, not legal advice. Read THIRD_PARTY_NOTICES.md yourself before shipping either build.

## Where HiGHS is the wrong choice

The convexity requirement is the first boundary. A non-convex quadratic term makes your model a non-convex QP, which the stated formulation does not cover. If that is what you have, HiGHS is the wrong tool and no option will change it.

The second is the interface set. The README names C, C#, FORTRAN, Julia and Python as the maintained interfaces, managed by Ivet Galabova. There is no Java binding and no JavaScript binding in that list. A team whose service is in one of those languages is calling HiGHS through a subprocess or through a wrapper you write and maintain yourself.

The third is scale and structure. HiGHS is described as being for large scale sparse linear optimization, and sparse is the operative word. A model that is dense, or one with far more variables than rows, or one whose structure makes the simplex basis the wrong representation, may be better served by a solver tuned for that shape. The repository has no published performance guidance in the README, so this is something you establish with your own models.

The fourth is the support model. The README invites users to email highsopt@gmail.com with their experience and offers advice, which is generous rather than contractual. For an open solver this is normal, but it is worth naming before you build a commercial product on it.

## Against a commercial or a different open solver

The comparison usually comes down to three things: licence terms, feature coverage and how much of the problem class each solver covers.

Against a commercial solver, HiGHS's position is straightforward. There is no purchase, no runtime fee and no licence key, and the MIT licence lets you ship it inside a proprietary product. What you give up is a contractual support commitment and the wider feature set a commercial product typically carries. If your model needs features outside LP, convex QP and MIP, that is the whole conversation.

Against the other open solvers, the differences are narrower and depend on what you optimise for. Some open solvers expose a richer modelling layer, a maintained Python modelling front end, or a cut generation framework. HiGHS is a solver with bindings, not a modelling environment, and the examples directory confirms that: the Python files build models directly rather than through a declarative layer.

HiPO is included in the Apache binary packages but not in the MIT packages.

The practical way to choose is to run your own model set through each candidate and compare solution quality and time. That is the only comparison the repository supports you in making, since it publishes no benchmark table.

## Conclusion

Adopt HiGHS when you need an open solver for LP, convex QP or MIP and you want a single API across them, with Python, C, C++ and Fortran bindings and no third-party dependencies. Do not adopt it if your model requires HiPO or a non-convex quadratic objective, since Q must be positive semi-definite and the prebuilt packages differ in licence. Verify first which binary you want, because the README states the *-mit packages are MIT and the *-apache packages include HiPO under Apache terms, and that choice changes what you may ship.

## FAQ

### What kinds of optimization problems can HiGHS solve?

HiGHS solves linear programs, convex quadratic programs and mixed integer programs. The README states that Q must be positive semi-definite, so a non-convex quadratic objective is outside what it handles.

### How do I build HiGHS from source?

HiGHS uses CMake and requires at least version 3.15. Run cmake -S . -B build followed by cmake --build build, which installs the executable bin/highs and the library lib/highs. Run ctest from the build directory to check the compilation succeeded.

### How do I use HiGHS from Python?

The Python package is highspy, described as a thin set of pybind11 wrappers to HiGHS, published on PyPI. It requires Python 3.9 or later and depends on numpy, and it ships type stubs so the API is typed.

### What is the difference between the MIT and Apache HiGHS binaries?

The README states that the *-mit binary packages contain HiGHS and are MIT licensed, while the *-apache packages contain HiGHS with HiPO and are Apache licensed due to the licensing of HiPO's dependencies. See THIRD_PARTY_NOTICES.md for details.

### Can HiGHS warm start from a previous solution?

Yes. The command line interface has a --read_basis_file option that takes an initial basis to read, and a --write_basis_file option that writes out the final basis, so a related model can be solved starting from the previous solution.

### Which programming interfaces does HiGHS support?

The README names C, C#, FORTRAN, Julia and Python as the interfaces, managed alongside the core development. There is no Java or JavaScript binding listed.

## Sources

- [ERGO-Code/HiGHS on GitHub](https://github.com/ERGO-Code/HiGHS)
- [Issues](https://github.com/ERGO-Code/HiGHS/issues)
- [License: MIT](https://github.com/ERGO-Code/HiGHS/blob/master/LICENSE)
- [README](https://github.com/ERGO-Code/HiGHS/blob/master/README.md)
- [Releases](https://github.com/ERGO-Code/HiGHS/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ergo-code-highs