# OptiGuide: three research projects putting language models into optimisation > The OptiGuide repository holds three separate pieces of work rather than one library: a supply chain what-if analysis system, a project on foundation models for mixed integer linear programming, and OptiMind, which teaches language models to reason the way optimisation experts do. It is a research artefact with evaluation code and benchmark data, and its prohibitions section is unusually strict about what you may do with it. **microsoft/OptiGuide** — GenAI for Optimization and Decision Intelligence - Repository: https://github.com/microsoft/OptiGuide - Stars: 726 · Forks: 128 - Language: Python - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoft-optiguide ## Three papers, three folders, and one repository The OptiGuide repository holds several projects for decision making and optimization, and the request to the reader is to cite the paper if you use the code in your own work. The structure is one folder per paper, and that is the first thing to understand, because there is no unified library here. The what-if/ folder, milp-evolve/ and optimind/ each correspond to a specific publication, and each is described as including the files needed to open source the paper plus the associated code and data. The first is OptiGuide for Supply Chain Optimization with What-if Analysis, associated with the paper Large Language Models for Supply Chain Optimization by Li, Mellou, Zhang and Pathuri and Menache, published as an arXiv preprint. The second is Towards Foundation Models for Mixed Integer Linear Programming, with the milp-evolve/ folder holding the MILP-Evolve code and data. The citation is a conference paper, The Thirteenth International Conference on Learning Representations, 2025, with a different author list, Li, Kulkarni, Wu, Menache and Li. The third is OptiMind: Teaching LLMs to Think Like Optimization Experts, with the optimind/ folder holding the evaluation code and test data. That one is an arXiv preprint from 2025 with a long author list including Zhang, Chen, Zope, Barbalho, Mellou, Molinaro, Kulkarni, Menache and Li. The repository top level reflects the split: three project directories, a setup.py, a LICENSE, a README, a SECURITY.md and a SUPPORT.md, a CODE_OF_CONDUCT.md and a .pre-commit-config.yaml. The last one tells you the project runs pre-commit, and the presence of a pre-commit config in a research repository that also carries benchmark data is a good sign about how carefully the data is handled. The last push was on 2026-07-02, the repository is not archived, and there are no GitHub releases. ## The setup file tells you which parts are actually packaged The setup.py is short and it carries the most important structural fact about the repository: only one of the three projects is distributed as a package. The find_packages call includes only what-if/optiguide*, so the what-if project is the one that installs. The package data is the optiguide.default subpackage with the pattern for the JSON files, which are the prompt templates or scenario data the system uses. The version is read out of the what-if project's own version file rather than being written in setup.py, so the package version and the research code cannot drift apart. The dependency list is where the architecture shows. It is openai at 1.3 or newer, diskcache, termcolor, pyautogen at 0.2.0 or newer, eventlet, and gurobipy. gurobipy is the commercial Gurobi solver, and its presence tells you the what-if system is not doing its own optimisation. The language model proposes or reasons about a scenario, and the actual optimisation is done by a proper solver. That is the sane architecture for this kind of work, and it also means running the code needs a Gurobi licence. pyautogen is the multi-agent framework, and combined with eventlet as the async runtime, that tells you the what-if system is built as a set of cooperating agents. The OpenAI client is there because the agents talk to a language model. diskcache and termcolor are small: one is for caching expensive model calls, the other is for terminal output. The extras_require group is called test and it covers more than the test suite. It pulls in pytest, pre-commit, nbconvert, nbformat, ipykernel, pydantic pinned at 1.10.9, and sympy. The Jupyter pieces mean the evaluation runs as notebooks, and the pinned pydantic tells you the project targets the 1.x API. The classifiers say MIT, the Python floor is 3.8, and the author is Beibin Li with a Microsoft email address. ## The prohibitions, and why a benchmark repository restricts scraping The prohibitions section is the part of this README most likely to matter if you are planning to use the code, and it is unusual enough to quote closely. The reason is stated first. Due to the specialized nature of this repository, which includes both benchmark data and source code designed for evaluating data-oriented models and pipelines, the repository expressly prohibits two things. The first is scraping the content of the repository for the purpose of training machine learning models, deep learning architectures, data science algorithms, large language models, or any other data-driven computational models. The reason given is that utilizing the content for such purposes could introduce bias and invalidate the evaluation metrics of the trained models. You are, however, permitted to use the repository for the evaluation of models and pipelines. That is a coherent and quite strict position. A benchmark only measures what it measures if the models being measured have not seen the answers. If the benchmark prompts and the expected solutions were in a training corpus, the reported numbers would be measuring memorisation, and the whole point of shipping the data alongside the evaluation code would be lost. So the distinction is not a defensive posture, it is the mechanism that makes the numbers mean something. The second prohibition is violating the licensing terms in the repository. The responsible AI section adds the framing. The integration of GenAI into decision intelligence and optimization has provided human-like reasoning in complex problem-solving, and the project acknowledges that since it utilizes publicly available language models, its framework inherently inherits both the strengths and limitations of those models. Safeguard mechanisms have been implemented to ensure fairness, reliability and safety in decision-making, but issues such as model biases, adversarial vulnerabilities and unexpected behaviors can still arise. The closing note is directed at researchers and practitioners: critically assess and interpret these AI-driven solutions, maintaining a deep understanding of both the advantages and the limitations of LLMs. ## Contributing here means signing a Microsoft CLA The contributing section is short and the mechanism is specific. The project welcomes contributions and suggestions, and most contributions require you to agree to a Contributor License Agreement, a CLA declaring that you have the right to, and actually do, grant the rights to use your contribution. The details point at the Microsoft CLA site. When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the pull request appropriately, with a status check or a comment, and you only need to do this once across all repos using Microsoft's CLA. That last detail is the practical one for anyone contributing to more than one Microsoft open source project. The signing is a one-time action, but it is a legal act with a defined grant, and it is the kind of step that will stop somebody mid-task if they are not expecting it. The project has adopted the Microsoft Open Source Code of Conduct, with a link to the code of conduct FAQ and a contact address at opencode@microsoft.com for additional questions. The SECURITY.md and SUPPORT.md at the root are the routing files for reporting a problem and asking for help, which is a conventional and useful arrangement for a repository carrying benchmark data. The trademarks section is the last thing in the README and it is the one most research repositories skip. This project may contain trademarks or logos for projects, products or services, authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark and Brand Guidelines, and use of Microsoft trademarks or logos in modified versions must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third parties' policies. That last clause is the one that matters here. The three projects cite external datasets and benchmarks, and the repository is making the point that the trademark position on those follows the owners of the data, not Microsoft. ## How to actually use this, and what to expect from a research codebase There is no quickstart in this README, and that is worth reading as a signal rather than an omission. The three projects are research code released alongside papers, and the expectation is that you read the papers and then work with the evaluation code and data in the matching folder. The practical starting point is the setup file. Since only the what-if package is included in find_packages, an install from this repository gives you the OptiGuide package and its default JSON data, not the MILP-Evolve code or the OptiMind evaluation harness. The other two live as directories in the tree, and their README files are where their own usage instructions would be. The runtime requirements are the real barrier to trying this. Gurobi is a commercial solver with its own licensing, so the what-if system's optimisation step is not something you can run for free out of the box. pyautogen and eventlet imply a multi-agent loop that calls a language model API, so there is a per-token cost to running the thing, and diskcache suggests the design assumes the model calls are expensive enough to be worth caching. The OpenAI dependency means the default path is the OpenAI API. None of that makes the repository less useful. It makes it a research artefact rather than a product, and the right use is to reproduce a result or to build on the evaluation setup. The version extraction in setup.py is a small detail that tells you something about the project though. The version is pulled with a regular expression from the what-if/optiguide/version.py file rather than hardcoded, which means the installed package version tracks the research code version. For a repository where three projects move at different rates, that is the right arrangement, and it is the kind of consistency that is cheap to get right and annoying to retrofit. ## Conclusion Adopt this repository if you are doing research on how language models handle optimisation problems, because it ships the evaluation code and the benchmark data rather than just the descriptions, and the three projects are separable so you can work with one. Do not adopt it as a production component, since the setup file marks only the what-if package for distribution and the whole thing is research code with a benchmark-specific purpose. Before you use anything here, read the prohibitions section, because scraping the content for training is explicitly forbidden, and note that most contributions require signing a Microsoft Contributor License Agreement. ## FAQ ### What projects are in the OptiGuide repository? Three. The what-if/ folder holds OptiGuide for Supply Chain Optimization with What-if Analysis, the milp-evolve/ folder holds the MILP-Evolve code and data from Towards Foundation Models for Mixed Integer Linear Programming, and the optimind/ folder holds the evaluation code and test data for OptiMind: Teaching LLMs to Think Like Optimization Experts. ### Can I use the OptiGuide benchmark data to train a model? No. Scraping the content of the repository for training machine learning models, deep learning architectures, data science algorithms, large language models or any other data-driven computational models is expressly prohibited, because it could introduce bias and invalidate the evaluation metrics. You are permitted to use the repository for the evaluation of models and pipelines. ### What does running the OptiGuide what-if system require? The runtime dependencies include gurobipy for optimisation, pyautogen for the multi-agent setup, eventlet as the async runtime, an OpenAI client for model access, diskcache and termcolor. The test extras add Jupyter tooling, pytest, pre-commit, a pinned pydantic 1.10.9 and sympy. Python 3.8 or newer is required and the licence is MIT. ### Do I need to sign anything to contribute to OptiGuide? Most contributions require agreeing to a Microsoft Contributor License Agreement, which a bot checks automatically on the pull request and which you only need to complete once across all repositories using that CLA. The project has also adopted the Microsoft Open Source Code of Conduct. ## Sources - [Issues](https://github.com/microsoft/OptiGuide/issues) - [License: MIT](https://github.com/microsoft/OptiGuide/blob/main/LICENSE) - [microsoft/OptiGuide on GitHub](https://github.com/microsoft/OptiGuide) - [README](https://github.com/microsoft/OptiGuide/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-optiguide