SolverForge.ai’s cover photo
SolverForge.ai

SolverForge.ai

Software Development

Write constraints like your write code.

About us

SolverForge is a free AI Optimization Framework for Rust and Python. It allows you to solve any planning optimization problem (e.g. shift scheduling, vehicle routing, bin packing) and deliver a beautiful end-to-end application.

Website
https://www.solverforge.ai
Industry
Software Development
Company size
1 employee
Headquarters
Bergamo
Type
Self-Owned
Founded
2026
Specialties
Constraint Programming, Python, Rust, and Ruby

Locations

Updates

  • New round of X-Series (Uchoa et al.) benchmarks - this time with full results available on our Discord. Next week we will start publishing about enterprise use cases, such as multi-target optimization for heat treatment plants as already advertised on our official SolverForge.ai website. For the benchmarks, link in comments! 👇

    We've hit an important milestone with SolverForge v0.8.6. For a while, we had good CVRP benchmark numbers, but there was still an asterisk: those runs were going through manually wired internals in the benchmark harness, not the full public API surface. That is no longer true. The latest results are running through the same user-facing path an actual integration would use: - declarative model - solver.toml - retained runtime - stock list-variable pipeline  And the numbers are very strong through that public surface. On the CVRPLIB X dataset (2017, Uchoa et al.): - 100 instances - 1s / 10s / 60s budgets - 300 total SolverForge runs - 0 invalid solutions Average ratio to best-known cost: - 1.0555 @ 1s - 1.0532 @ 10s - 1.0515 @ 60s Other numbers that matter if you care about CVRP: - 288 / 300 runs finished within 10% of best-known - on the large instances (n >= 600), the 60s mean ratio was 1.0491 - on X-n1001-k43, SolverForge came in at 1.0628 @ 1s, 1.0628 @ 10s, 1.0624 @ 60s What is exciting here is not just the benchmark quality. It is that these numbers are now coming from the official API surface of a generic solver, not from hand-wired benchmark internals. This is literally doable with solverforge-cli in a couple of hours! To me, that is the real threshold: a solver is only truly product-ready when the public path preserves the performance of the core engine. That is the standard we are trying to hold in SolverForge: the best path should be the official path.

    • No alternative text description for this image
  • `solverforge-cli` v1.1.2 released! Links and release notes in the original post!

    🚀 We just shipped solverforge-cli v1.1.2 on crates.io — the default entry point for building constraint solver applications with SolverForge. When we onboard developers to optimization modeling, the first hurdle is always: "Where do I start?" This CLI removes that friction entirely. One command gives you a runnable, neutral app shell. From there, you grow your domain incrementally: add entities, facts, constraints and planning variables as your problem becomes clearer. What's new in 1.1.2: • Compound scaffolding — generate entity + constraint + paired twin in one shot • Demo data generation with configurable sizes (small/standard/large) • 5 constraint pattern generators (unary, pair, join, balance, reward) • Complete destroy commands for rapid iteration • Shell completions for bash, zsh, and fish The CLI targets SolverForge 0.8.4, solverforge-ui 0.4.3, and solverforge-maps 2.1.3 — version alignment is part of the product surface, not an implementation detail. If you're building scheduling, routing, or resource allocation apps in Rust, this is the fastest path from zero to a running solver. Links in comments! 👇 #rust #constraintsolving #optimization #operationsresearch #cli #solverforge

    • No alternative text description for this image
  • SolverForge 0.8.2 is out! Link to Release Notes in comments! 👇

    SolverForge 0.8.2 is out. 0.6.0 -> 0.8.x was about five weeks of work focused on one thing: making the CLI and runtime feel like one tool. What changed: - solverforge new scaffolds complete applications—domain model, constraints, solver config, web UI - solver.toml drives runtime behavior; per-solution overlays via #[planning_solution(config = "...")] - SolverManager owns the retained lifecycle with exact pause/resume semantics - Events stream job progress, snapshots, and telemetry for services and UIs - Analysis is always revision-bound against retained snapshots The idea: install the CLI, scaffold a project, and have a working solver in minutes. Extend with Rust when you need custom constraints or phases. Deploy with confidence in the checkpoint semantics. Link to release notes in comments. 👇

  • We are looking for OSS contributors in QA and Benchmarking!

    SolverForge is looking for contributors! In the area of QA, we're looking for people with: - Proven experience in Operations Research and AI - The ability to navigate a large codebase - At least some Rust experience - An interest in benchmarking system level applications against each other You get: - Office time on SolverForge and constraint programming - Support on your own projects - Preferential lane as soon as any partnership opportunity arises You'll find all appropriate channels in comments! 👇

  • We're happy to announce that, as of today, SOLVERFORGE.AI is an officially registered business! This is the cornerstone we've been building in public for months: a Rust-native constraint solving framework that treats optimization as production engineering, with vendor support from its creators and as the alternative to the lingering SaaS obsession. The thesis is simple: control beats dependency. When you build planning systems, scheduling, routing, resource allocation - you shouldn't have to outsource your core logic to opaque APIs you don't own. You should write constraints like you write code. Transparent. Auditable. Yours. SolverForge is the nucleus: oss-framework-first, Rust-powered, designed for teams who need solver behavior they can inspect, extend and ship on their own infrastructure. We're not selling optimization as a service. We're selling the ability to own it and make it yours. If you're building operational planning software and are tired of trading control for "convenience", let's talk. Company homepage in comments! 👇

  • We are looking for OSS contributors in UX!

    SolverForge is looking for OSS contributors! For the UX area, we're looking for people with: - An interest in designing, maintaining and showcasing UI components in the domain of AI scheduling - The Will to stick to Vanilla JS - An interest in Rust and Ruby Perks: - You get office time on SolverForge, planning optimization and agentic engineering - In time, you get to know our end-game and get a preferential lane to participate - When there's a real fit and we fully go to market, you'll be considered a Partner as soon as we deploy any UI Our preferred platforms for this are X and GitHub. The whole "build in public" aspect of SolverForge will mostly move there - but you can contact us on any of our official channels.

    • No alternative text description for this image
  • 🗞SolverForge v0.6.0 released!

    SolverForge v0.6.0 released! 😎 This release focuses on onboarding and developer ergonomics: - CLI scaffolding + code generation for new projects - Generated collection accessors (for example, factory.shifts()) to reduce extractor boilerplate - Constraint naming standardization with .named(...) SolverForge 0.6.0 makes it easier to go from a blank project to a working solver model while keeping constraint code concise and type-safe. Links in comments! 👇

    • No alternative text description for this image
  • Starting from SolverForge 0.6.0, `solverforge new` will automatically wire some basic UI components from our newly published library. You can still opt-out and just produce a REST API.

    We just open-sourced solverforge-ui - a lightweight frontend component library purpose-built for AI scheduling and constraint-optimization applications. No npm. No webpack. No React. Just vanilla JS and CSS that ships inside your Rust binary. One line to mount: let app = api::router(state)   .merge(solverforge_ui::routes()); Every asset -fonts, icons, CSS, JS- is compiled into the binary via include_dir!. The entire crate has two dependencies: axum and include_dir.  What's in the box: - SolverForge-emerald design system with 290 lines of tokens (colors, spacing, shadows, typography) - Score display that parses "0hard/-42soft" and color-codes in real time - Constraint dot indicators - green circles that pulse red when hard constraints are violated, amber for soft - Timeline rail - resource lanes with positioned task blocks, temperature/load gauges, heatmaps, changeover indicators - Interactive Gantt chart (Frappe Gantt) with split-pane grid, drag-to-reschedule, project-colored bars - SSE-powered solver lifecycle — start, stream updates, stop, analyze — with automatic status bar binding - Backend adapters for Axum, Tauri, and generic fetch (Rails, Django, whatever) - Self-hosted Space Grotesk + JetBrains Mono (variable weight WOFF2) - FontAwesome 6.5 Solid subset, Leaflet map module with polyline decoder Philosophy: starting from SolverForge 0.6.0 every backend element has a corresponding UI element. When you add a planning entity type to your solver, there's a widget ready to render it. Build flow is make - numbered source files concatenated with cat. The CSS and JS source files are kept under 300 lines each, with no transpilation, bundling or source maps. Just files you can read. Works with Axum (crate dep), Tauri (crate dep), or any HTTP server (copy the static/sf/ directory). When you scaffold a project with `solverforge new`, it's going to be already wired in. Apache-2.0. Go build something. Link in comments. 👇

    • No alternative text description for this image
    • No alternative text description for this image
  • Second episode of our Operating Room Scheduling Problem with SolverForge 0.6.0. Write constraints like you write code.

    In the last video we created the basic project scaffold for operating room scheduling with SolverForge. Today we are going to perform just one little step that starts showcasing our true killer feature: we model the problem dynamically and the system wires itself end-to-end. `solverforge generate solution or_schedule` -> BOOM! 🔥 ...the whole pipeline is re-wired. The basic project scaffold is deleted, the example constraint isn't there anymore, but we have a new domain definition and an empty planning solution for us to develop. Wait for when we will define the model and start adding/modifying constraints. The Forge never stops.

Similar pages