Modeling front-ends

There is no Quicopt-specific modeling language to learn. You author your model in a standard Python front-end — Pyomo or OR-Tools MathOpt — and pass it to client.solve() (or client.submit()) directly; the client handles the conversion internally:

pip install "quicopt[pyomo]"      # model in Pyomo
pip install "quicopt[mathopt]"    # model in OR-Tools MathOpt

Both extras can be installed side by side; solve() dispatches on the model type you pass in.

What each front-end can express

Which one to pick

• OR-Tools MathOpt for LP, QP, MILP, and QUBO models. Your variable names survive into result.solution, and the vectorised quadratic form (x @ Q @ x with numpy) is a natural fit for QUBOs.
• Pyomo when the model is genuinely non-linear — exp, log, trigonometry, powers beyond quadratic — including MINLP (binary decisions mixed into a non-linear model) and higher-order binary polynomials (PUBO/HUBO). Note that the Pyomo front-end currently returns generic x1, x2, … solution keys.

Whatever the front-end, the same Result comes back, and the status semantics are identical.

Problem classes

Today the service solves LP, QP, MILP, MINLP, QUBO, PUBO/HUBO, and NLP — see the runnable example for each class. One free-tier edge: in a non-linear model, integer variables beyond binary on/off decisions aren't accepted yet. Black-box objectives are coming soon; a model outside today's classes is declined with a readable message (a QuicoptError with reason: "unsupported_model"), never a wrong result.