NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
PyPI · #1324 most downloaded on PyPI
OSQP: The Operator Splitting QP Solver
Last release 3 months ago
12 Jun 2026
Release timing varies
gaps range from 8 days to 5 months
Some releases are documented
notes for 11 of 40 stable releases
1 version withdrawn
withdrawn after publishing
9 years old
47 releases · first in 2017
This release is identical to version v1.1.2 , but we have now included wheels for Python 3.14t on Windows along with the other platforms.
This release is identical to version v1.1.2, but we have now included wheels for Python 3.14t on Windows along with the other platforms.
This version adds binary wheels for free-threaded python 3.13t and 3.14t, for several platforms.
This version adds binary wheels for free-threaded python 3.13t and 3.14t, for several platforms.
One column per quarter.
This version fixes the license and license-files metadata, and adds binary wheels for Python 3.14 for several platforms.
This version fixes the license and license-files metadata, and adds binary wheels for Python 3.14 for several platforms.
Full Changelog: v1.1.0...v1.1.1
This version fixes 2 memory leaks with the osqp python wrapper. This memory leak would have shown up on accessing properties of a single solution prop
osqp python wrapper. This memory leak would have shown up on accessing properties of a single solution property repeatedly: for i in range(iterations):
_ = prob._solver.solution.x
_ = prob._solver.solution.y
Thanks to @XiDianZuoYun for pointing these out.
osqp settings and info fields were added in OSQP 1.0 but were missed from the python bindings.- check_dualgap
- dual_obj_val
- duality_gap
- run_time
- rel_kkt_error
Thanks to @imciner2 for adding these.
This version introduces wheels for the aarch64 platform. No functional changes have been introduced wrt v1.0.4.
This version introduces wheels for the aarch64 platform. No functional changes have been introduced wrt v1.0.4.
This version fixes a bug and adds a feature.
This version fixes a bug and adds a feature.
When using numpy>=2 along with <solver>.setup() without specifying either P or A (i.e. letting the solver infer values for P or A), users would have encountered an AttributeError in numpy. This is now fixed. (Issue 177)
Certificates of infeasibility prim_inf_cert and dual_inf_cert are now returned as additional attributes of the <solver>.solve() invocation (all previously returned attributes are preserved). This functionality existed in pre-1.0 versions of the osqp python wrappers. (Issue 174)
Thanks @stephane-caron
With this version, it will raise an osqp.OSQPException . This is a breaking change, but we believe that raising an exception is more explicit and usef…
This version introduces two useful enums that can be queried to see the status of several solver operations:
osqp.SolverStatus is useful in the case of <solver>.solve().
osqp.SolverError is useful in the case of <solver>.setup(), <solver>.update_settings() or <solver>.solve().
We also introduce a useful exception class, osqp.OSQPException, that can be "equated" to these enums to find its value:
e == osqp.SolverError.OSQP_NONCVX_ERROR
See the examples folder for usage.
There are a couple of behavior changes that users need to be aware of:
<solver>.update_settings() failed (due to incorrect values of parameters or otherwise), it would have failed silently. With this version, it will raise an osqp.OSQPException. This is a breaking change, but we believe that raising an exception is more explicit and useful than failing silently.raise_error parameter in <problem>.solve() still defaults to False, but this has the potential of hide problems if the solve failed, so we might change it to True in the future. For now we simply warn the users of this possible change. Users should always check res.info.status or res.info.status_val in any case..setup() (and .solve(raise_error=True)) invocations on <solver> would initially have raised ValueErrors. These now raise osqp.OSQPExceptions which are more introspectable.See Status values and errors for a comprehensive list of status values that you might want to watch out for.
introduced an osqp.SolverStatus enum
With this release, we're making available osqp cuda (12.x) and mkl wheels available on PyPI, as osqp-cu12 and osqp-mkl packages respectively, so there
With this release, we're making available osqp cuda (12.x) and mkl wheels available on PyPI, as osqp-cu12 and osqp-mkl packages respectively, so there is no need to download these specialized "backend algebra" wheels from GitHub.
Users do not need to explicitly pip install these packages, but can choose to install osqp with the correct extras (cu12 or mkl, or both).
pip install osqp[cu12]
pip install osqp[mkl]
More detailed instructions at https://osqp.org/docs/get_started/python.html
This version of osqp-python is built from tag 1.0.0 of osqp .
This version of osqp-python is built from tag 1.0.0 of osqp.
Source distributions and binary wheels for builtin algebra are available at PyPI. MKL, CUDA and Wasm32 wheels are available here on Github.
Some minor changes over 1.0.0beta4 include:
P/q/A/l/u matrices/vectors in the wrapper object, but passing them straight through to the underlying wrapped C code.update_settings that we don't recognize.polishing and warm_starting as setting parameters in wrapper, even tough the old polish and warm_start are also supported for now.examples/ folder.This is a the final beta release of osqp-python for the upcoming OSQP v1.0.
This is a the final beta release of osqp-python for the upcoming OSQP v1.0.
Source distributions and binary wheels for builtin algebra are available at PyPI. MKL, CUDA and Wasm32 wheels are available here on Github.
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
This version of OSQP does not insist that the version of scipy!=1.12.0 as a runtime dependency (which v0.6.7.post0 enforced).
This version of OSQP does not insist that the version of scipy!=1.12.0 as a runtime dependency (which v0.6.7.post0 enforced).
While scipy 1.12.0 does cause certain test results in development to fail (because of a transient behavior change in scipy), this is a developer-facing issue, and this dependency constraint is not enforced upon users of osqp-python.
Support NumPy 2.0 for Python 3.9+
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →