Early access · Cloud LP & MILP engine
Solvometry is building a cloud optimization engine that analyzes the structure of every model you submit, selects and configures the solving strategy for you, and turns the experience of past solves into better decisions on the next one.
Explore the technologyWhy optimization needs to evolve
Modern mathematical programming is extraordinarily powerful. But getting good performance out of it still depends on manual choices about which solver to use, how to configure it, and which computational strategy to apply. Those choices are made by people, under deadline, with limited evidence.
Performance variability in MILP is well documented: the best solver, and even the best setting of a single solver, changes from instance to instance. Choosing one engine and one configuration for every workload leaves performance on the table, systematically.
Hundreds of parameters, presolve choices, emphasis settings, cut strategies and heuristics. Tuning them is slow, specialist work that rarely transfers when the data changes, and it is usually done once and never revisited.
Most organizations solve structurally similar models every day. Yet each run starts cold: yesterday's incumbent, the configuration that worked, and the variables that never changed are rarely exploited in any systematic way.
Each column is a problem instance; each row a solving strategy. The highlighted cell marks the fastest strategy for that instance.
| Solver A · default | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Solver A · tuned | ||||||||||||||||||||||
| Solver B · default | ||||||||||||||||||||||
| Solver B · heuristics | ||||||||||||||||||||||
| Warm-started | ||||||||||||||||||||||
| LNS-first |
How Solvometry works
You describe the problem and the time you can spend. Solvometry decides how to solve it, and every permitted run makes the next decision better informed.
01 / SUBMIT
Send a model from Python, over REST, or as a standard MPS or LP file. Keep the modeling framework you already use. Declare only what matters to you: the problem, the time budget, and the outputs you need.
Python SDK
launch target
REST API
launch target
MPS / LP files
launch target
Pyomo
early integration
PuLP
early integration
JuMP
planned
MathOpt
planned
AMPL-compatible
exploring
The intelligence engine
Solvometry is designed as a set of complementary capabilities that compound: selection decides how to solve, learning improves those decisions with experience, and acceleration brings learned guidance into the solve itself.
Intelligent solver selection and configuration.
Instance-based algorithm selection: features of the submitted model are mapped to a ranked set of strategies, constrained by your time limit and the outputs you require.
Experience-driven adaptation across workloads.
Telemetry from permitted solves refines strategy selection globally, specializes it to your recurring model families, and links related instances so that knowledge is reused rather than rediscovered.
Learned methods inside the search itself.
Research-driven techniques that use learned models to guide the search, while the underlying algorithms keep their mathematical guarantees. These capabilities are on the roadmap and will be released only when they are validated.
Where Solvometry fits
Traditional solvers provide powerful algorithms. Modeling frameworks help you express problems. Neither decides, from evidence, which algorithm and configuration a particular instance should get. Solvometry is the missing layer between them: an execution engine that combines the strengths of different algorithms and improves with experience.
The initial portfolio is built on proven open-source engines. Over time, we intend to develop proprietary solving and acceleration methods of our own, behind the same interface.
Modeling frameworks
Pyomo · JuMP · PuLP · MathOpt · AMPL
Help you express the mathematical problem and communicate it to a solver.
Solvometry
Intelligent execution layer
Decides how each model should be solved, runs it, verifies the result, and learns from the outcome across your workloads.
Solving engines
HiGHS · SCIP · future proprietary methods
Provide the rigorous algorithms (simplex, interior point, branch-and-cut) that compute solutions and bounds.
Conceptual demonstration
Pick a problem family and step through how Solvometry is designed to analyze a model, weigh candidate strategies, and return a result. Everything here is illustrative: no solver runs in your browser and no values are measurements.
Model
plant_allocation_2026-10-31.mps
min Σ cost·x + Σ setup·y s.t. capacity, demand, x ≤ M·y, y ∈ {0,1}
Structural features
Candidate strategies
Safe baseline for any MILP.
Big-M setup links benefit from tightening.
Yesterday's plan is close to feasible; repair and improve it.
Result
awaiting run…
Built for developers
Describe the problem and the time you can afford. The public interface stays small and stable while the intelligence behind it keeps improving.
status
optimal, feasible, infeasible, unbounded, time_limit
objective · values
Objective value and primal variable assignments
best_bound · mip_gap
Certified dual bound and relative gap for MILP
run
Strategy, solver, version, parameters, seed for reproducibility
duals · reduced_costs · slacks
LP sensitivity data; MILP only via fixed-integer LP
iis
Irreducible infeasible subsystem for infeasible models
basis · mip_start · solution_pool
Warm-start inputs and alternative solutions where supported
Capabilities differ by problem class and engine. Requests are routed to strategies that support the outputs you ask for, and the response states exactly which engine produced them.
from solvometry import solve
# Pass a Pyomo or PuLP model, an MPS/LP file, or an SDK-built model.
result = solve("production.mps", time_limit=60)
print(result.status) # Status.OPTIMAL
print(result.objective) # 1284310.55
print(result.mip_gap) # 0.0
print(result.values["x[plant_3,sku_17]"])The interface shown is a design preview and may change before release. Early-access members will help shape it.
One engine. Many optimization problems.
Solvometry works at the level of mathematics: variables, constraints and objective. It needs no domain template, yet it learns the recurring structure of your models, which is where most practical performance lives.
Multi-echelon flows, sourcing and allocation across facilities and periods.
multi-period MILP
Lot sizing, replenishment and safety-stock positioning under capacity limits.
lot-sizing MILP
Sequencing, batching and machine assignment with setups and due dates.
time-indexed MILP
Load planning, fleet assignment and routing on time-expanded networks.
network flow + MILP
Rostering and shift design subject to coverage, labor rules and fairness.
set covering
Budgets, capacity and assets assigned under competing constraints.
LP / assignment
Unit commitment, dispatch and storage scheduling across horizons.
unit-commitment MILP
Facility location and capacity expansion with fixed-charge decisions.
fixed-charge MILP
Portfolio construction with cardinality, lot and turnover constraints.
mixed-integer LP
Any linear or mixed-integer linear model you can write down.
LP · MILP
Mathematical rigor meets machine learning
Machine learning in Solvometry is used to make computational decisions, not to replace the mathematics. A learned model can change how fast a good answer is found. It cannot change whether an answer is feasible or what the certified bound is.
Statistical models trained on solve telemetry
Exact algorithms with mathematical guarantees
A poor prediction costs time, not correctness. If a learned warm start is bad, the solver discards it. If a predicted configuration underperforms, the run still terminates with an exact status and a valid bound.
Solvometry does not ask an LLM to read your model and produce a solution. Its learning components are predictive models over numerical and structural features of mathematical programs, evaluated by measured solver outcomes.
Choosing what to run, for how long, and when to switch strategies under a fixed budget is a sequential decision problem. Treating it that way, rather than with static rules, is the research core of the platform.
Product roadmap
Each phase builds on the data and infrastructure of the previous one. Nothing below is generally available today; we will mark capabilities as released only when they are.
Cloud mathematical programming with a consistent API.
Automated algorithm selection and performance-based learning.
Learned heuristics and reuse of historical solutions.
Dynamic orchestration and new algorithmic capabilities.
Early access & design partners
Solvometry is in early development. We are looking for practitioners and organizations with real optimization workloads, especially recurring ones, to evaluate the technology with us and tell us where it matters most.
Waitlist
One field. We will notify you as access opens, in the order people joined.
Design partner program
A small number of teams will work closely with us through the Foundation and Intelligence phases.
What partners get
An ideal fit
Design-partner application
About three minutes. Everything beyond your name, work email and company is optional, but the more we know about how and how often you solve, the better we can judge where Solvometry can help first.
FAQ
If your question is not here, email us. Technical questions are especially welcome.
Solvometry is a cloud mathematical optimization engine under development. You submit an optimization model and a time budget through one API; Solvometry analyzes the model's structure, selects and configures a solving strategy, runs it, verifies the result, and uses permitted solve history to make better strategy decisions over time.
The initial focus is linear programming (LP) and mixed-integer linear programming (MILP), which cover the large majority of industrial planning, scheduling, allocation and network problems. We intend to expand to other problem classes only once we can support them with the same rigor; we do not claim nonlinear or stochastic optimization support for the first release.
Today it is best described as an intelligent execution layer: it decides how each model should be solved and orchestrates proven engines to do it. That is a starting point, not the ceiling. Our long-term plan includes proprietary solving and acceleration methods, delivered behind the same interface so that customers benefit without changing their code.
Not necessarily, and we make no claim to be faster than any commercial solver today. Solvometry addresses a different question: given a particular model, time budget and history, which strategy should run? Some teams may use it to reduce dependence on manual tuning or licensing; others may eventually want commercial engines inside the portfolio. Design partners will help us decide which matters most.
Solvometry computes numerical and structural features of each model (size, integrality, sparsity, coefficient ranges, recognizable constraint structure) and uses statistical and machine-learning models trained on solve outcomes to predict which strategies are likely to perform well. Later phases apply learning inside the search itself, for example learned warm starts and learning-guided neighborhood search. Throughout, exact optimization algorithms compute the solutions and bounds.
No. Solvometry does not ask a language model to read a model and produce an answer. The learning components are predictive models over mathematical features, and every reported solution, bound and status comes from a rigorous optimization algorithm and is verified against the submitted model.
At three levels. Globally, it learns general relationships between problem structure and strategy performance. At the model-family level, it specializes to your recurring formulations, such as a daily production plan. At the instance level, it exploits similarity between closely related runs, for example by reusing a repaired incumbent as a warm start. Learning is a long-term engineering and research goal; it will not improve every individual solve, and we will publish evidence before making performance claims.
Yes. Your models, data and solutions belong to you and are never shared with other organizations. Family- and instance-level learning stays within your organization's boundary. Any cross-customer learning is designed to use only aggregate, non-identifying structural statistics and solver-performance signals, and we intend to let customers opt out of it entirely. Detailed data-handling terms will be agreed in writing before any design partner shares a model.
That is a core design goal. The first release targets a Python SDK, a REST API, and standard MPS and LP files, which most frameworks can already export. Native integrations with Pyomo and PuLP are planned early, with JuMP, MathOpt and AMPL-compatible workflows to follow. Tell us what you use in the design-partner application; it directly affects priority.
Core results include status, objective value, primal values, best bound and MIP gap, plus a run manifest (strategy, solver, version, parameters, seed) for reproducibility. Planned additions include LP dual values, reduced costs, slacks, infeasibility analysis (IIS), basis information, MIP starts and solution pools where supported. Capabilities depend on the problem class: for example, LP shadow prices are not presented as generally valid MILP constraint duals.
Not yet. Solvometry is pre-launch and under active development. The API shown on this site is a design preview. Joining the waitlist is the best way to hear when access opens, and design partners will get hands-on access first.
Join the waitlist with your email for launch updates, or apply to be a design partner if you have real, ideally recurring, LP or MILP workloads. Design partners work directly with the founding team, gain early access, and influence the roadmap. Applying takes about three minutes and carries no obligation.
Every solve should make the next one smarter.
We are building that engine now. Join early, and help decide what it learns first.