USolver
# USolver
**This project is no longer maintained.**
I've moved on to working at [OneChronos](https://www.onechronos.com), so I'm no longer developing or supporting USolver. The repository has been archived and will remain available read-only for anyone who finds it useful.
If this kind of work interests you (combinatorial optimization, SMT/convex solvers, formal methods, language-model tooling for mathematical problems), OneChronos is hiring. Take a look at the [careers page](https://www.onechronos.com/careers/).
TDQS
Scored across 7 tools
There is significant overlap and confusion between tool pairs: simple_cvxpy_solver vs solve_cvxpy_problem, simple_highs_solver vs solve_highs_problem, and solve_z3 vs solve_z3_simple. Each pair appears to solve the same type of problem with only interface differences, making it difficult for an agent to choose correctly without deep understanding of the subtle distinctions in input formats.
The naming is mixed with no clear pattern: some tools use 'simple_' prefix (simple_cvxpy_solver, simple_highs_solver, solve_z3_simple), others use 'solve_' prefix (solve_cvxpy_problem, solve_highs_problem, solve_ortools_problem, solve_z3), and there's inconsistency in suffix usage (_solver vs _problem). While readable, the conventions vary enough to cause confusion.
With 7 tools, the count is reasonable for an optimization solver server covering multiple backends (CVXPY, HiGHs, OR-Tools, Z3). However, the duplication within backends makes the count feel slightly inflated rather than each tool earning its distinct place.
The server covers multiple optimization domains (convex, linear/mixed-integer, constraint programming, SMT) with solve capabilities, which is appropriate for a solver-focused toolset. Minor gaps might include lack of model validation or result analysis tools, but core solving functionality is well-represented across supported backends.