MM-Agent: an LLM pipeline for mathematical modeling contests, and what its GPL/CC split means for you

The problem MM-Agent targets is the modeling contest, not general math

Mathematical modeling competitions give teams a messy written prompt plus a data file and a few days. The work is not solving an equation. It is deciding which model class fits, writing the assumptions down, producing code that runs, and then writing a paper that a judge can follow. MM-Agent is built around that sequence. The README describes four stages: problem analysis, mathematical modeling, computational solving, and solution reporting. It also lists project management as a capability, which suggests the intended user runs several problems side by side rather than one.

The audience is narrow and the README is explicit about it. One news entry states that MM-Agent assisted two undergraduate teams in winning the Finalist Award in MCM/ICM 2025, and calls the system a modeling copilot. Another entry frames an upcoming release around preparing for the MCM/ICM contest. So the target user is a student team with a deadline, not a research group reproducing a paper and not an engineer automating a production forecasting job. If your problem already has a known model form, MM-Agent is doing work you have already done.

Four stages, an LLM at each one, and code as the intermediate artifact

The architecture visible in the README is a staged pipeline rather than a single prompt. Stage one reads the unstructured problem description and extracts background, objectives and constraints. Stage two formulates a mathematical model and, per the feature list, selects the model class automatically and records assumptions. Stage three implements algorithms and optimization techniques as code. Stage four turns the result into a structured report.

The interesting part is where the code sits. The README describes intelligent code generation that auto-generates and then iteratively improves code, and separately describes interactive data analysis with visualizations. That implies the analysis step is executed rather than described, and that execution output feeds back into the next iteration. The exact loop is not spelled out in the README, so how many refinement rounds occur, and what triggers another round, cannot be confirmed from the supplied material.

The demo announcement names the stack for the upgraded platform: a Next.js frontend, a FastAPI backend, BYOK configuration, and E2B sandbox support. That is the only concrete architecture detail available. E2B is a hosted execution sandbox, so generated analysis code is intended to run off your machine. For a contest team that is convenient. For anyone handling restricted data it is a decision point, because the data file you upload is what the generated code operates on.

Getting it running means reading demo/README.md, not the top-level README

The top-level README does not contain a pip install line, a conda environment file, a requirements.txt reference, or a Docker command. It links to assets/demo.mp4 for a walkthrough and to demo/README.md for usage. The only environment facts stated are the badges: Python 3.10+, PyTorch 2.0+, and an OpenAI GPT-4o badge, plus a BYOK configuration mentioned in the demo announcement.

So the honest instruction is: clone the repository, then open demo/README.md and follow it, because that is the document the project points at for the Next.js frontend and FastAPI backend. The BYOK label means you supply your own model API key rather than using a shared service account, which is consistent with the earlier news item about issuing service accounts from a Star list when server capacity was limited. The E2B sandbox support means you will also need whatever credentials that service requires, and the README does not say whether the sandbox is optional or mandatory for the analysis stage.

One practical consequence of the missing top-level setup section: you cannot estimate install time from the README alone. There is no lockfile reference and no pinned dependency list in the material provided, and the repository has no releases, so there is no tagged version to pin against.

The licence signal contradicts itself, and that is the first thing to resolve

The repository metadata supplied for this article lists the licence as GPL-3.0. The README's own licence badge links to a LICENSE file and displays CC-BY-NC-4.0. Those are not compatible descriptions of the same grant. GPL-3.0 is a copyleft software licence that permits commercial use provided derivative works keep the same terms. CC-BY-NC-4.0 is a content licence that forbids commercial use outright and is a poor fit for source code precisely because of that restriction.

This is not a hypothetical. If you fork MM-Agent, modify the agent stages, and ship it inside a paid product, the answer to whether you may depends entirely on which file governs. The repository has a LICENSE file, so the text is present and readable; the README badge is what disagrees with the metadata. Anyone intending to reuse the code should read that file directly rather than trusting either summary. This article is not legal advice, and a contradiction like this is exactly the kind of thing to put in front of whoever handles licensing at your organisation before you build on it.

There is a second implication. The non-commercial reading would also sit awkwardly with the academic framing: a paper accepted at NeurIPS 2025 and an ICML 2025 workshop, with a public demo, is normally released for research use, and CC-BY-NC-4.0 matches that intent while GPL-3.0 does not.

Where the agent workflow breaks down

The first limitation is that every stage is an LLM call, and the README gives no accuracy figures, no failure analysis, and no statement about what happens when the model choice is wrong. The four-stage decomposition makes errors compound: a misread constraint in stage one propagates into the model in stage two, into the code in stage three, and into the report in stage four. A single-prompt assistant fails visibly. A pipeline can fail plausibly, producing a well-formatted report built on a model that does not fit the problem. The README's own framing as a copilot, rather than an autonomous solver, is the right reading.

Second, the contest evidence is a news item, not a controlled result. Two teams reaching Finalist with the tool does not tell you the base rate, and the README does not report how many teams used it or how they used it. Treat that entry as a signal that the workflow is usable under deadline, not as a performance claim.

Third, the hosting history is unstable. A previous demo URL is struck through in the README with the note that the link is no longer available due to server expiration, and an earlier announcement tied service account issuance to a Star list because of limited server capacity. For a tool you might depend on during a fixed contest window, that pattern matters. The open-source demo exists so you can run it locally, which is the version to plan around.

How it differs from asking a general coding assistant

The nearest alternative is a general-purpose coding assistant such as a chat interface over GPT-4o, which the README already lists as the model it targets. The difference is not the underlying model. It is that MM-Agent imposes the four-stage decomposition and keeps the intermediate artifacts: a stated model with assumptions, generated analysis code, and a report. With a general assistant you supply that structure yourself, prompt by prompt, and you are the one who remembers the assumptions from three turns ago.

A second alternative is a notebook environment where you write the model and the analysis by hand, using an assistant only for code completion. That gives you full control over every assumption and no external sandbox. The trade-off is time, which is the resource a contest team is short of.

The comparison that matters is therefore about structure and execution, not model quality. MM-Agent runs the generated code and feeds results forward, and it produces the paper draft as a first-class output. A chat assistant will write you a model description and a code block, but it will not track a project or hand you a report stage. Whether that structure is worth the E2B dependency and the licence ambiguity is the adoption question.

Maintenance cost and what the release history tells you

There are no tagged releases in the material provided, so there is no version to pin and no changelog to diff against. The repository is not archived and the last push date is recent, and the news section shows active development through 2026: an open-source demo, a discontinued hosted demo, a related project called dslighting announced as an end-to-end data science assistant, and an upgraded platform. Development is ongoing, which cuts both ways. You get fixes; you also get a moving target with no release boundary.

Upgrade cost is concentrated in the demo stack rather than the agent logic. A Next.js frontend and a FastAPI backend are two dependency trees, and the E2B sandbox adds a third external service whose API can change independently of this repository. Because the top-level README does not pin Python or PyTorch beyond minimum badges (3.10+ and 2.0+), you should expect to resolve dependency versions yourself on first install.

The related dslighting repository is worth knowing about if your work drifts from contest modeling toward general data science, since the announcement describes it as covering a complete data science workflow with optimization for mathematical modeling scenarios. The README does not state whether the two share code, so treat them as separate projects until you check.

Editorial conclusion

Adopt MM-Agent if you are preparing for MCM/ICM-style contests and want a copilot that produces a model formulation, runnable analysis code and a draft report you will rewrite yourself. Do not adopt it for commercial modeling work: the repository metadata says GPL-3.0 while the README badge points at CC-BY-NC-4.0, and non-commercial terms would rule out client deliverables. Before committing, verify which licence actually governs the code you clone, and confirm that demo/README.md documents a working local path without the E2B sandbox, because the README does not give a bare pip install or a requirements file.

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. usail-hkust/LLM-MM-Agent on GitHub