CVXPY: model the math, let the solvers solve

The math reads naturally, the standard form disappears

CVXPY's pitch is about notation. It is a Python-embedded modeling language for convex optimization, which lets you express a problem in a natural way that follows the math, rather than in the restrictive standard form solvers demand. That translation layer is the entire product: converting high-level modeling problems into disciplined convex programs, helping choose solvers, tune constraints and validate numeric results. The repository's primary language being C++, not Python, is the visible reminder that the conversion engine underneath is native code, rebuilt through a dedicated rebuild_cvxcore.sh script. The project began as Stanford University research and is now developed by a named team, Steven Diamond, Akshay Agrawal, Riley Murray, Philipp Schiele, Bartolomeo Stellato and Parth Nobel, with Stephen Boyd among the people who shaped it early. Governance lives in a separate cvxpy organization repository, and the documentation site at cvxpy.org carries the tutorial, the example library and the API reference that everything else points to.

A bounded least-squares problem in ten statements

The README's opening example is a least-squares fit where the variable is boxed between zero and one:

import cvxpy as cp
import numpy

# Problem data.
m = 30
n = 20
numpy.random.seed(1)
A = numpy.random.randn(m, n)
b = numpy.random.randn(m)

# Construct the problem.
x = cp.Variable(n)
objective = cp.Minimize(cp.sum_squares(A @ x - b))
constraints = [0 <= x, x <= 1]
prob = cp.Problem(objective, constraints)

Solving and inspecting the answer are separate, explicit steps:

# The optimal objective is returned by prob.solve().
result = prob.solve()
# The optimal value for x is stored in x.value.
print(x.value)
# The optimal Lagrange multiplier for a constraint
# is stored in constraint.dual_value.
print(constraints[0].dual_value)

The constraint list reads like the mathematics it is, 0 <= x, x <= 1, and the solution carries both the primal answer in x.value and the dual multipliers in dual_value, so sensitivity information arrives with the optimum rather than through a second solve.

Not a solver: four bundled, more on request

The README states it bluntly: CVXPY is not a solver. It relies on the open source solvers Clarabel, SCS, OSQP and HiGHS, which arrive as dependencies with pinned floors, Clarabel >= 0.5.0, OSQP >= 1.0.0, SCS >= 3.2.4.post1 and highspy >= 1.11.0. Additional solvers are available but must be installed separately, and the documentation carries a choosing-a-solver guide for the decision. The test configuration shows how seriously solver interactions are taken: pytest markers segregate tests that load native solver runtimes, with a marker for KNITRO noting it must run in a separate process from other native solvers. Neighboring modeling languages exist, Pyomo across many Python problem classes and JuMP in Julia, but CVXPY's niche is disciplined convex programming with solver choice treated as a documented, changeable decision.

Past convex: integers, geometric programs and NLPs

The problem classes reach beyond the convex core. The documented list covers convex optimization, mixed-integer convex optimization, geometric programs, quasiconvex programs and nonlinear programs, and the dependency list reflects the frontier: sparsediffpy >= 0.2.2, sparse derivatives being exactly what nonlinear programs need for their gradients. Mixed-integer support is what pulls HiGHS into the default solver set, since that solver covers integer problems. The practical meaning for a modeler is that one notation spans portfolio-style quadratic problems, posynomial geometric design trade-offs and general nonlinear fits, with the same Problem, solve, inspect loop in each case. The boundary is still real: discipline is enforced, and a problem outside the accepted grammar fails at modeling time rather than silently solving the wrong thing. The five-class list is also a check on expectations, since a problem that is none of those kinds belongs to a general nonlinear optimizer rather than to this layer.

pip, conda, and the Python 3.11 floor

Two install paths are documented, one word apart:

pip install cvxpy

conda install -c conda-forge cvxpy

The requirements are a step up from typical scientific Python: Python >= 3.11, NumPy >= 2.0.0 and SciPy >= 1.13.0, which places CVXPY firmly on the current NumPy 2 generation. The ruff configuration in pyproject.toml targets py311 and enforces a NumPy-2 migration rule through the NPY201 lint selection, so the codebase itself is held to the same floor it asks of users. For teams on older interpreters or pinned pre-2.0 NumPy stacks, that floor is the first compatibility question to answer, before any solver choice, because the modeling layer will refuse to install otherwise. A detailed installation guide, including building from source, is linked from the README at cvxpy.org/install.

A C++ core built with SciPy's old tricks

The build machinery is candidly old school. setup.py sets a builtins global, __CVXPY_SETUP__, so the package can detect it is being built before its components exist, a hack the comment credits to adapted SciPy code, and a custom build_ext injects NumPy headers while unsetting NumPy's own setup flag. macOS builds manage MACOSX_DEPLOYMENT_TARGET explicitly, motivated by Apple dropping libstdc++. The type-checking configuration carries an unusual artifact: a pyright section listing suppressed violation categories with error counts as of 2026-05-22, 307 attribute-access issues, 213 argument-type issues and so on, an explicit ledger of technical debt to be fixed incrementally rather than an invisible blanket ignore. AGENTS.md, CLAUDE.md and PROCEDURES.md at the root document process for humans and coding agents alike.

Discord, Discussions, and the DCP question on StackOverflow

Community plumbing is deliberately split by question type. Bugs and feature requests go to GitHub Issues, long-form discussion to GitHub Discussions, and basic usage questions, with the canonical example being "Why isn't my problem DCP?", to StackOverflow under the cvxpy tag, an honest acknowledgment that grammar questions are the most common kind. Real-time chat runs on Discord, and a code of conduct governs all of it. A benchmarks site at cvxpy.github.io/benchmarks tracks solver performance, contributions are welcomed from non-experts with concrete entry points like the example library and benchmark suite, academic users are pointed at the citation list, and industry users are invited to introduce themselves. Releases are steady: v1.9.1 in May 2026, v1.9.2 in August, v1.9.3 on 2026-09-19, with the last push on 2026-09-25, under Apache-2.0.

Editorial conclusion

Use CVXPY when your problem is convex, mixed-integer convex, geometric or quasiconvex and you want to write it in mathematical notation inside Python instead of a solver's standard form. Use Pyomo when your modeling spans many problem classes beyond convex, or JuMP if your work lives in Julia. Verify first that your interpreter is Python 3.11 or newer, that NumPy 2 compatibility holds for your stack, and that the solver you intend to use, among the four bundled or the separately installable others, actually covers your problem class before you invest in the model.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes