Why not just an LLM coding assistant?

You can build an optimization model by working through the objective, the constraints and the data yourself and steering a general LLM coding assistant to a finished implementation. That works — provided you already know how to frame the problem as decision variables, constraints and an objective, how to write tests that actually check a model rather than the code that produced it, and how to read an infeasibility. If you do, an assistant is a reasonable way to write the gurobipy.

Those are exactly the things that take years to learn, and they are what Modeler supplies. The comparison below is limited to the modeling work: how the problem gets framed, what grounds the modeling and coding decisions, what you review, what checks the answer, and what happens when the requirements change.

Note

This is not an either/or. Modeler runs standalone in the browser, and it also runs as an MCP server inside your own project, where your usual assistant calls it for the modeling step and keeps doing everything else. The left column below is an assistant working without access to it.

Getting to the model

LLM coding assistant
on its own Modeler
in the browser, or via MCP from your project
What you start from A problem you have already framed as an optimization model A business question in plain terms, underspecified
Framing it as an optimization problem
Biggest difference Yours to do. You have to know that decisions become variables with the right domain, restrictions become constraints, and the goal has to collapse to a single objective Driven by the agent. It settles the objective first, then the constraints one at a time, then the data entities and the expected output
Filling the gaps Asks clarifying questions if you prompt it to. Otherwise it guesses, and a guessed structural constraint is not visible in the output Asks one question at a time, in order of importance, each with ranked candidate answers drawn from comparable problems. Unresolved gaps are asked about, not filled in
What grounds the modeling choices General training data. Optimization modeling guidance is a thin slice of it, frozen at a training cutoff, and nothing in the answer says where it came from A Gurobi-curated knowledge base — expert articles, reference manuals, official Gurobi repositories, and modeling and performance best practices — re-indexed daily, with responses citing their sources
Writing the gurobipy Whatever API the model learned. Deprecated calls and outdated patterns are a common result, and they still run Written against a Gurobi-maintained coding guide, built from the pitfalls Gurobi's experts actually see in customer code and the patterns they recommend for clear, performant models
What you review The generated code — so reviewing it means reading gurobipy A specification in business language containing no mathematics. The person who owns the problem can confirm it is the right problem
Your data Can read files if you set that up Reads the data you upload and runs the model on it
Running it Nothing runs unless you run it. The code you are handed has not been executed, and you need a Gurobi installation and license to find out whether it works Executed inside the conversation against the current gurobipy, with no local installation or license of your own. Errors surface and get fixed before you see the result

Important

The runtime that executes the model is a small sandbox, not a production solve. Its bundled license is capped at 2000 variables and 2000 constraints, CPU and memory are tightly limited, and each command has a 60-second budget. That is sized for validating the model on small data, which is what the generated tests do. For a full-size instance, take the generated project and run it under your own Gurobi license. Raising these limits is on the roadmap.

Keeping it correct

A model that runs is not the same as a model that is right, and requirements do not hold still. This second table is about both.

LLM coding assistant
on its own Modeler
in the browser, or via MCP from your project
Checking the answer
Biggest difference Tests only if you ask for them, and a test written from the code only confirms what the code already does A pytest suite generated from the business scenarios in the specification — one test per scenario, written before the implementation exists, so it is an independent check
If a test fails You diagnose and fix, or ask the assistant to Corrects the implementation and re-runs until the suite passes. If the failure is a contradiction between specification, code and tests rather than a defect, it stops and asks which side is wrong
If the model is infeasible No access to the solver's own diagnostics — an assistant can only reason about the code Gurobi's own algorithms — IIS, feasibility relaxation, basis-derived sensitivity analysis — are available, run by Explainer on a model file you hand it
When the problem changes You re-explain and re-steer. Whatever description you wrote earlier now lags the code, and the tests lag both The change re-enters through the conversation, lands in the specification first, and propagates from there: specification, implementation, tests
The mathematics Produced if you ask, with nothing tying it to the code that was generated Derived on request from the current specification and implementation, so it describes the model as it actually stands

Important

Explainer is a separate agent today, not a step inside the Modeler conversation. Diagnosing an infeasible model means exporting it and starting an Explainer chat — see Diagnosed with Explainer, which does exactly that on an infeasible version of the facility model. Invoking the diagnosis from within the modeling loop is on the roadmap.

Reducing hallucination risk

We continuously work on what our agents can do, and on resolving issues as they come up, through testing and through real usage alike. A thumbs up or thumbs down on a response is one valuable input into that continuous improvement process — it’s a signal straight from real usage that testing alone would not surface.

One of the more common ways an LLM goes wrong is hallucination: when the context it has is limited, or there’s a gap in what it actually knows, it fills that gap with something that sounds right rather than admitting it doesn’t know. A general LLM coding assistant working on a Gurobi model has a real chance of doing exactly that — calling a method that doesn’t actually exist on the object being used:

env = gurobipy.Env()

env.getParamInfo("MIPGap")  # this method does not exist
value = env.get("TimeLimit")  # neither does this attribute

Both calls look entirely plausible, on a real Gurobi object, and the mistake only shows up once the code is actually run.

Our agents minimize this risk. Rather than relying on whatever the LLM happened to memorize, we ground it in Gurobi’s own knowledge — checked against the actual gurobipy reference and the coding guide — and that AI engineering work is what maximizes your experience:

env = gurobipy.Env()

env.setParam("MIPGap", 0.01)
value = env.Params.TimeLimit

When to use your assistant directly

Modeler covers the modeling step. Use your assistant on its own when that step is already behind you:

  • The model exists and you are changing a coefficient, renaming a variable or refactoring the code around it.

  • You know the formulation you want and you are typing it in, not deciding it.

  • The work is not modeling — plumbing the model into a service, building the data pipeline that feeds it, writing the report that consumes the solution.

What this page leaves out

Everything above is specific to modeling. The rest of what the Intelligence Hub adds over a general-purpose assistant — license-aware support that can escalate to a human, usage limits, and how your data is handled and deleted — is documented in the User Manual rather than repeated here. The FAQ is the short version.

For the right-hand column in full, see the methodology.