Clarabel.rs, an interior point conic solver that skips the epigraph trick

The problem class: one conic form for every convex model

Clarabel.rs is a Rust implementation of an interior point numerical solver for convex optimisation problems using a novel homogeneous embedding, and it is published alongside a Python interface and a Julia implementation.

The problem it solves is written out in the README as a conic programme. The objective minimises a quadratic form, one half x transpose P x plus q transpose x, subject to A x + s = b with s in a convex set K that is a composition of convex cones, where P is positive semidefinite and A, b and q carry the problem data.

That single form is what makes a conic solver worth having. Linear programs, quadratic programs, second-order cone programs and semidefinite programs are all instances of it once you choose the right cone, and the README lists the coverage explicitly: LPs, QPs, SOCPs and SDPs, plus problems with exponential, power cone and generalized power cone constraints.

The audience is therefore people writing optimisation or control or estimation libraries who need a solver that handles more than QPs, and who would like it to be callable from Rust without a C++ toolchain. The crate is published on crates.io as clarabel, with documentation on clarabel.org, and the version in the manifest is 0.11.1.

Quadratic objectives without the epigraph reformulation

The technical claim in the README that distinguishes Clarabel from other interior point solvers is about quadratic objectives.

Most interior point solvers are based on the standard homogeneous self-dual embedding, the HSDE. Clarabel.rs does not use that formulation, and the README says the consequence plainly: it handles quadratic objectives without requiring any epigraphical reformulation of the objective, and it can therefore be significantly faster than other HSDE-based solvers for problems with quadratic objective functions.

The epigraph trick is the standard workaround. A quadratic objective is turned into a linear objective over an epigraph variable constrained by a second-order cone, so the solver only ever sees a linear objective inside a cone constraint. It works, and it costs you an extra variable and a bigger cone, and the cone part is where the interior point method spends its effort.

By keeping the quadratic term in the objective and solving the conic form directly, Clarabel avoids that enlargement. If your workload is quadratic programs, which is most of scientific computing's use of a conic solver, that difference is the reason to look at this crate rather than a general solver.

Infeasibility detection is handled the same way, using a homogeneous embedding technique, so the solver can tell you a problem has no solution rather than iterating to failure.

Cargo and pip, with a Python binding built by maturin

Installation is ordinary for both language bindings, and the README points at separate documentation for source installs.

For a Cargo based project, you add the dependency to Cargo.toml:

[dependencies]
clarabel = "0"  

For the Python interface, it is a pip install:

pip install clarabel

The Python package is built with maturin, and the pyproject.toml shows the shape of it. The build system requires maturin 1.0 or newer but below 2.0, the project name is clarabel, it needs Python 3.9 or newer, and its runtime dependencies are numpy, scipy and cffi. The maturin configuration enables a feature called python, so the Rust side is compiled with the bindings switched on.

That dependency set is worth noting. The Python interface is not a thin re-export of prebuilt native code, it compiles the Rust solver, which is why numpy, scipy and cffi are needed and why a C-compatible toolchain has to be present when installing from source.

The crate itself has a light dependency list for a numerical solver: amd, cfg-if, itertools, derive_builder, enum_dispatch, lazy_static, num-traits and thiserror. There is no matrix library in the base dependencies, because the linear algebra is written in Rust rather than delegated.

Semidefinite programming needs you to choose a BLAS

The feature flags in the manifest are the most operationally interesting part of the configuration, because they show that SDP support is not free.

The default feature set is serde, which enables reading and writing problems from JSON files through serde, serde_json and serde_big_array. Separately, there is buildinfo for detailed build info reporting through vergen.

The sdp feature is where the choice appears. It enables blas, lapack and indexmap, and the README comment in the manifest is explicit: enable blas and lapack for SDP support, with the blas and lapack source unspecified. The manifest also notes that the sdp feature enables the packages required for chordal decomposition.

On top of that there are five explicit BLAS flavour features, one per vendor: sdp-accelerate for Apple with blas-src/accelerate and lapack-src/accelerate, sdp-netlib for the reference implementation, sdp-openblas, sdp-mkl for the Intel distribution, and sdp-r for the R build.

So if you want SDP support, you have to make an explicit platform decision, and getting it wrong means either a link failure or a build that takes far longer than it should. For a crate whose selling point is being a Rust solver, this is the part of the setup that will cost you an afternoon the first time.

One codebase, three language bindings, and a shared Julia path

The repository layout shows how the language bindings are organised. There is a src/ directory for the Rust solver, a python/ directory for the bindings, a pyproject.toml for the Python package, and an examples/ directory that holds examples in data/, python/ and rust/ subdirectories, so the same problem is demonstrated from both sides. The html/ directory suggests generated documentation output, and there is a build.rs for build-time configuration.

The julia feature in the manifest is revealing. It enables libc, num-derive, buildinfo, faer-sparse, serde and sdp, and the manifest comment says it builds as the Julia interface. The README points to the separate Clarabel.jl repository for the Julia implementation, so the Rust crate is the shared core rather than a one-off port.

The publishing discipline is visible too. There is a CHANGELOG.md, a CITATION.bib alongside the citation block in the README, a rustfmt.toml for consistent formatting, a .cargo/ directory for Cargo configuration, and a tests/ directory.

The citation is a BibTeX entry for the paper Clarabel: An interior-point solver for conic programs with quadratic objectives by Paul J. Goulart and Yuwen Chen, dated 2024, with the arXiv identifier 2405.12762. That paper is the reference for the method, and the README points to the documentation for more.

A slow release line with a 2026 push behind it

The release history is the last thing to check, and it has a shape worth understanding.

The listed versions are 0.10.0 on 2025-02-02, 0.11.0 on 2025-05-23 and 0.11.1 on 2025-06-11, and the last push to the main branch was on 2026-04-13. So the published crate is from mid-2025 while the repository has seen work in 2026, and the version numbering is a 0.x line, which in Rust convention means the API is not yet considered stable.

That combination matters for a solver. A conic solver's behaviour on edge cases, and its tolerances, are the kind of thing that changes between minor versions, and downstream code that depends on exact solver output will notice. Pinning a version and reading the CHANGELOG before upgrading is the sensible habit here, more so than for a typical utility crate.

The other two floors are easy to satisfy and worth stating. The Cargo manifest declares edition 2021 with rust-version 1.70.0, and the Python package requires Python 3.9 or newer. The licence is Apache 2.0, with the terms in LICENSE.md, and the README says the code is on GitHub and distributed under that licence.

One more implementation detail is worth flagging for anyone trying to reproduce a build: the manifest has the comment that this is required for openssl to work on GitHub Actions, and the resolver is set to 1 rather than 2. That is a deliberate choice for CI reproducibility, and it is the kind of thing that changes dependency resolution compared with the default.

Editorial conclusion

Adopt Clarabel.rs if you are writing numerical software in Rust that needs to solve conic programs and would rather not take a C++ solver as a dependency, since the crate covers LPs, QPs, SOCPs, SDPs and the exponential and power cones, and the quadratic objective handling is where it differs from solvers built on the standard embedding. Do not adopt it if you need semidefinite programming out of the box without picking a BLAS and LAPACK implementation, because the sdp feature demands an explicit choice. Before you commit, check the rust-version floor of 1.70.0 and the Python 3.9 requirement, read the sdp feature flags to pick the right BLAS flavour for your platform, and note the maintenance picture, with v0.11.1 released on 2025-06-11 and the last push on 2026-04-13.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. oxfordcontrol/Clarabel.rs on GitHub
4. README
5. Releases