Diet¶

Problem Statement¶

Builds and solves the classic diet problem: choosing food portions to minimize cost while meeting daily nutrition targets.

What an optimal solution looks like

Daily cost

$5.37

Foods used

3 of 9

Total portions

Portions bought per food (cap: 3 per item).

Salad

2 · $1.98

Chicken

1 · $1.89

Hot dog

1 · $1.50

Not purchased: Hamburger Fries Macaroni Pizza Milk Ice cream

How close each nutrient sits to its limit.

Red marks the tightest constraints — the ones actually driving the solution.

Calories (floor 1,600)1,620 of 1,600–2,800

Protein (floor 91g)114g · 23g to spare

Fat (ceiling 100g)66g · 66% of max

Sodium (ceiling 2,600mg)2,450mg · 94% of max

Built with Modeler¶

The problem above is stated as a single shot: you hand over the whole problem and get a model back. Modeler takes the other route — you start with the business question you actually have, and it works with you until the problem is pinned down, the data is in, the code runs, and the answer holds up when the problem changes.

The tabs below walk the same diet problem through that route, one Modeler capability at a time.

Instead of writing the whole prompt up front, you start with the business question you actually have. Modeler searches the knowledge base, asks one clarifying question at a time — always the most important one first — and tells you which parts of the model are still missing. The options it offers come from examples in the knowledge base and from how similar problems are usually modeled, so you can answer with a number instead of prose.

I want to eat healthier without blowing my grocery budget. Can you help me figure out what to buy?

The user wants to minimize food spending subject to nutrition targets — this is a classic diet-optimization problem. Let me search the knowledge base for relevant examples and ask clarifying questions one at a time. First, let me search the knowledge base, and then ask the first clarifying question.

Querying the knowledge base.

Good, I found relevant diet-optimization examples. “Eat healthier” isn’t a number yet, so let me ask what nutrition targets the user actually wants to track before anything else.

This is a classic diet-optimization problem — minimizing food cost while meeting nutrition targets. I have found relevant examples in the knowledge base to guide the modelling. Let me ask you a few questions to build a complete specification.

Question 1: What nutrition targets do you want the plan to satisfy?

A calorie range only (a target window, e.g. 1800–2200 calories)
Calories plus a minimum protein target
Calories plus upper limits on fat and/or sodium
All of the above — calories, a protein minimum, and caps on fat and sodium

Learn More:
• Diet Optimization Examples ★★☆
• Nutritional Diet Model ★★☆

I want to eat between 1800 and 2200 calories a day, get at least 91 grams of protein, and stay under 65 grams of fat and 1779 mg of sodium.

That is option 4, with all four numeric targets supplied at once. Recording the objective and the constraint values in the specification. Still open: what foods are actually available to choose from, and whether partial portions are allowed. Asking about portion divisibility next, since it changes the variable type rather than just the data.

Recorded — calories between 1800 and 2200, at least 91g protein, at most 65g fat, at most 1779mg sodium. Two things are still missing before I can implement anything:

• Data — the foods you are choosing between, with a price and a nutrition profile per portion. A file works best here.

• Constraint — whether portions can be fractional (half a burger, say) or must be whole numbers.

Question 2: Should portions be whole numbers, or can they be fractional?

Whole portions only — no half portions
Fractional portions allowed — e.g. 1.5 servings

Learn More:
• Modeling Integer vs. Continuous Decisions ★★★
• Diet Optimization Examples ★★☆

Whole portions only. And I’d like to see the full nutrition breakdown of whatever you recommend, not just the cost. One more thing — please cap any single food at 3 portions a day. I don’t want a plan that’s basically just one item.

Thinking…

Modeler updates the specification after every answer, even while it is still incomplete — so you can always see what it has understood and what it is still waiting on.

Modeler asked for the food options as a file rather than as nine rows of numbers typed into the chat. Attach diet.csv to the conversation and it reads the real shape of your data instead of guessing at it — entity names, column headers, units and all.

diet.csv:

food,price,calories,protein,fat,sodium
hamburger,3.49,410,24,26,730
chicken,1.89,420,32,10,190
hot dog,1.50,560,20,32,1800
fries,1.89,380,4,19,270
macaroni,1.49,320,12,10,430
pizza,1.99,320,15,12,820
salad,0.99,320,31,12,230
milk,0.89,100,8,2.5,125
ice cream,1.59,330,8,10,180

diet.csv attached

Here are the foods I’m choosing between. Price is per portion.

Reading the attachment. One row per food, one column per attribute — nine foods, each with a price and a nutrition profile per portion. Calories, protein and fat and sodium columns already match the units named in the specification (kcal, grams, grams, mg), so nothing needs converting. Adding a “Food” entity to the Input section with these six fields.

Got it — nine foods, priced per portion, with calories, protein, fat and sodium already in the units from the specification. Nothing needs rescaling. I have added a Food entity to the specification’s Input section with these fields.

That was the last open item. Shall I proceed to Step 2: Model Implementation using Python with gurobipy?

Where your files live

Everything in the conversation — the file you attached and every artifact Modeler generates from it — lands in the conversation workspace as an attachment. Each one opens in a side panel next to the chat, so you can read the specification while you keep answering questions, or scroll the code while you ask for a change. From that panel you can copy the contents or download the file.

By the end of this conversation the workspace holds six items:

Attachment	What it is
`diet.csv`	The food data you attached.
`diet_spec.md`	The specification, rewritten after every answer.
`diet_modeler.py`	The `gurobipy` implementation.
`test_diet_modeler.py`	The `pytest` suite, one test per scenario.
`execution.log`	Output of the test runs, including the solver logs.
`diet_formulation.md`	The mathematical formulation, generated on request.

Starting from files you already have

The same upload path runs in reverse. Attach the files of an existing optimization project — a specification, a model script, a test file, or any subset — and ask Modeler to check the project. It completes the specification where it is thin (asking clarifying questions, as above), fills in a missing implementation or test suite, reconciles code that has drifted from the specification, and runs the tests. Point it at a model written for another solver or another language and it recovers a specification from that file, asks you to confirm it, then reimplements the model in gurobipy.

The specification is the artifact the questions are building toward, and the one everything else is generated from. Modeler rewrites it after every answer — even while it is still incomplete — so it doubles as the running record of what has been agreed and what is still open. It follows a fixed seven-section structure and is written entirely in business terms: no mathematics, so the person who owns the problem can read it and say whether it is right.

1. Overview

A shopper wants a daily food plan that meets a fixed set of nutrition targets at the lowest possible cost, choosing from a menu of nine foods. The model decides how many whole portions of each food to buy.

2. Objective

Minimize total daily food cost.

3. Constraints

C1 — Calories fall within a daily target window. Between 1800 and 2200 calories a day — enough to avoid underfeeding, not so much that the plan overshoots a calorie goal.

C2 — Protein meets a daily minimum. At least 91 grams a day, since the shopper wants enough protein regardless of what else is on the plan.

C3 — Fat stays under a daily cap. At most 65 grams a day.

C4 — Sodium stays under a daily cap. At most 1779 milligrams a day.

C5 — No single food may exceed 3 portions a day. The shopper does not want a plan that leans on one item to an unrealistic degree.

4. Input

Entity	Fields	Values
Food	name, price, calories, protein (g), fat (g), sodium (mg), all per portion	9 foods, supplied in `diet.csv`

Chicken is the standout on this menu: 32 grams of protein for $1.89, and only 190mg of sodium, versus 1800mg for a similarly priced hot dog. That combination of high protein and low sodium per dollar is why chicken and salad dominate the optimal plan below.

5. Output

The number of portions of each food to buy.
Total daily cost.
The full nutrition breakdown of the plan: calories, protein, fat and sodium delivered.

6. Test scenarios

ID	Scenario	Acceptance criteria
T1	Baseline — the data above.	Buy 2 portions of chicken and 3 of salad. Cost $6.75 (1800 kcal, 157g protein, 56g fat, 1070mg sodium).
T2	The price of salad rises from $0.99 to $1.99 a portion.	The recommendation changes: 2 chicken and 3 macaroni. Total cost $8.25.
T3	The minimum protein target rises from 91g to 150g.	Plan and cost are unchanged from T1 — the baseline plan already delivers 157g.
T4	The minimum protein target rises to 183g.	Reported as infeasible — 182g is the most protein any combination of the nine foods can deliver within the fat, sodium and 3-portion caps.
T5	The sodium cap is tightened to 1000mg (a more sodium-conscious target).	The recommendation changes to 2 chicken, 1 salad and 2 ice cream. Cost rises to $7.95.
T6	Compare against a naive pick of 2 chicken, 1 macaroni and 2 salad (a “protein plus a starch” guess).	The naive pick is feasible at $7.25. The optimized plan saves $0.50 a day — about $180 a year.

7. Out of scope

Multiple days or a weekly meal plan; the model is a single-day snapshot.
Taste, or food-group balance beyond the 3-portion cap — the model is otherwise indifferent to a plan built from just two items.
A minimum number of distinct foods, or a minimum amount from any particular food group (protein, starch, vegetable, dairy).
Brand-name substitutions or store availability.
Personalized targets based on age, weight, or activity level; the four nutrition targets are fixed inputs.
Meal timing or a breakfast/lunch/dinner structure.

With the specification settled, Modeler writes the gurobipy implementation. This is the version that came out of the run-and-fix loop in the Cloud solve tab, after Modeler ran the tests and fixed what it found.

"""Diet plan: how many portions of each food to buy to minimize cost while
meeting daily nutrition targets.

Implements the specification in diet_modeler_spec.rst.
"""

import pandas as pd
import gurobipy as gp
from gurobipy import GRB

# Nutrition targets from the specification.
MIN_CALORIES = 1800
MAX_CALORIES = 2200
MIN_PROTEIN = 91
MAX_FAT = 65
MAX_SODIUM = 1779
MAX_PORTIONS_PER_FOOD = 3


def read_food_data(path):
    """Read diet.csv into {food: {price, calories, protein, fat, sodium}}."""
    frame = pd.read_csv(path).set_index("food")
    return frame.to_dict(orient="index")


def solve_diet(
    foods,
    cal_lo=MIN_CALORIES,
    cal_hi=MAX_CALORIES,
    min_protein=MIN_PROTEIN,
    max_fat=MAX_FAT,
    max_sodium=MAX_SODIUM,
    max_portions_per_food=MAX_PORTIONS_PER_FOOD,
    time_limit=None,
):
    """Solve the diet model.

    Args:
        foods: {food: {price, calories, protein, fat, sodium}} per portion.
        cal_lo, cal_hi: allowed daily calorie range.
        min_protein: minimum daily protein in grams.
        max_fat: maximum daily fat in grams.
        max_sodium: maximum daily sodium in mg.
        max_portions_per_food: maximum daily portions of any single food.
        time_limit: optional solver time limit in seconds.

    Returns:
        A dict with the number of portions of each food and the resulting
        cost and nutrition totals, or ``{"status": "infeasible"}`` when no
        combination of portions meets the targets.
    """
    names = list(foods)

    with gp.Env() as env, gp.Model("diet", env=env) as model:
        if time_limit is not None:
            model.Params.TimeLimit = time_limit

        # x[f]: whole portions of food f to buy. C5: capped at
        # max_portions_per_food, enforced as a variable bound.
        x = model.addVars(
            names, vtype=GRB.INTEGER, ub=max_portions_per_food, name="x"
        )

        model.setObjective(
            gp.quicksum(foods[f]["price"] * x[f] for f in names), GRB.MINIMIZE
        )

        # C1: calories fall within the target window.
        total_calories = gp.quicksum(foods[f]["calories"] * x[f] for f in names)
        model.addConstr(total_calories >= cal_lo, "min_calories")
        model.addConstr(total_calories <= cal_hi, "max_calories")
        # C2: at least the minimum protein.
        model.addConstr(
            gp.quicksum(foods[f]["protein"] * x[f] for f in names) >= min_protein,
            "min_protein",
        )
        # C3: at most the maximum fat.
        model.addConstr(
            gp.quicksum(foods[f]["fat"] * x[f] for f in names) <= max_fat,
            "max_fat",
        )
        # C4: at most the maximum sodium.
        model.addConstr(
            gp.quicksum(foods[f]["sodium"] * x[f] for f in names) <= max_sodium,
            "max_sodium",
        )

        model.optimize()

        if model.Status == GRB.INFEASIBLE:
            return {"status": "infeasible"}
        if model.SolCount == 0:
            return {"status": "no_solution", "gurobi_status": model.Status}

        x_values = model.getAttr("X", x)
        portions = {f: x_values[f] for f in names if x_values[f] > 1e-6}

        return {
            "status": "optimal",
            "portions": portions,
            "cost": sum(foods[f]["price"] * x_values[f] for f in names),
            "calories": sum(foods[f]["calories"] * x_values[f] for f in names),
            "protein": sum(foods[f]["protein"] * x_values[f] for f in names),
            "fat": sum(foods[f]["fat"] * x_values[f] for f in names),
            "sodium": sum(foods[f]["sodium"] * x_values[f] for f in names),
        }


def main():
    foods = read_food_data("diet.csv")
    result = solve_diet(foods)

    if result["status"] != "optimal":
        print(f"No feasible diet found: {result['status']}")
        return

    print("Buy:")
    for food, portions in sorted(result["portions"].items()):
        print(f"  {food}: {portions:.0f} portion(s)")
    print(
        f"\nCost:     {result['cost']:>8,.2f}"
        f"\nCalories: {result['calories']:>8,.0f}"
        f"\nProtein:  {result['protein']:>8,.0f} g"
        f"\nFat:      {result['fat']:>8,.1f} g"
        f"\nSodium:   {result['sodium']:>8,.0f} mg"
    )


if __name__ == "__main__":
    main()

Alongside the implementation, Modeler writes a pytest suite with one test per scenario in the specification. Each test references its scenario identifier, and uses the small hard-coded food data and a short solver time limit so the suite runs in well under a second.

"""One test per test scenario in diet_modeler_spec.rst.

Each test uses the small hard-coded food data from the specification and a
short solver time limit, so the whole suite runs in well under a second.
"""

import pytest

from diet_modeler import solve_diet

# Price and nutrition per portion, keyed by food. Same values as diet.csv,
# inlined to keep the tests self-contained.
FOODS = {
    "hamburger": dict(price=3.49, calories=410, protein=24, fat=26, sodium=730),
    "chicken": dict(price=1.89, calories=420, protein=32, fat=10, sodium=190),
    "hot dog": dict(price=1.50, calories=560, protein=20, fat=32, sodium=1800),
    "fries": dict(price=1.89, calories=380, protein=4, fat=19, sodium=270),
    "macaroni": dict(price=1.49, calories=320, protein=12, fat=10, sodium=430),
    "pizza": dict(price=1.99, calories=320, protein=15, fat=12, sodium=820),
    "salad": dict(price=0.99, calories=320, protein=31, fat=12, sodium=230),
    "milk": dict(price=0.89, calories=100, protein=8, fat=2.5, sodium=125),
    "ice cream": dict(price=1.59, calories=330, protein=8, fat=10, sodium=180),
}

TIME_LIMIT = 10


def run(foods=None, **targets):
    return solve_diet(foods or FOODS, time_limit=TIME_LIMIT, **targets)


def cost_of(portions, foods=FOODS):
    return sum(foods[f]["price"] * n for f, n in portions.items())


def test_t1_baseline_buys_chicken_and_salad():
    """T1: with the published data, 2 chicken + 3 salad is optimal at $6.75."""
    result = run()

    assert result["status"] == "optimal"
    assert result["portions"] == {"chicken": 2, "salad": 3}
    assert result["cost"] == pytest.approx(6.75)
    assert result["calories"] == pytest.approx(1800)
    assert result["protein"] == pytest.approx(157)
    assert result["fat"] == pytest.approx(56)
    assert result["sodium"] == pytest.approx(1070)


def test_t2_salad_price_shock_shifts_the_plan_to_macaroni():
    """T2: salad rising to $1.99 shifts the plan to 2 chicken + 3 macaroni."""
    foods = {**FOODS, "salad": {**FOODS["salad"], "price": 1.99}}
    result = run(foods=foods)

    assert result["status"] == "optimal"
    assert result["portions"] == {"chicken": 2, "macaroni": 3}
    assert result["cost"] == pytest.approx(8.25)


def test_t3_raising_protein_target_to_150_leaves_plan_unchanged():
    """T3: the baseline plan already delivers 157g, so 150g changes nothing."""
    result = run(min_protein=150)

    assert result["status"] == "optimal"
    assert result["portions"] == {"chicken": 2, "salad": 3}
    assert result["cost"] == pytest.approx(6.75)


def test_t4_raising_protein_target_to_183_is_infeasible():
    """T4: 182g is the most protein achievable within the fat, sodium and
    3-portion caps, so 183g has no feasible plan."""
    result = run(min_protein=183)

    assert result["status"] == "infeasible"


def test_t5_tightening_sodium_cap_changes_the_plan():
    """T5: a 1000mg sodium cap drops salad and macaroni in favor of ice
    cream, raising cost to $7.95."""
    result = run(max_sodium=1000)

    assert result["status"] == "optimal"
    assert result["portions"] == {"chicken": 2, "salad": 1, "ice cream": 2}
    assert result["cost"] == pytest.approx(7.95)


def test_t6_optimized_plan_beats_a_naive_pick():
    """T6: a naive pick of 2 chicken + 1 macaroni + 2 salad is feasible but
    costs $0.50 a day more than the optimized plan."""
    naive_portions = {"chicken": 2, "macaroni": 1, "salad": 2}
    naive_calories = sum(FOODS[f]["calories"] * n for f, n in naive_portions.items())
    naive_protein = sum(FOODS[f]["protein"] * n for f, n in naive_portions.items())
    naive_fat = sum(FOODS[f]["fat"] * n for f, n in naive_portions.items())
    naive_sodium = sum(FOODS[f]["sodium"] * n for f, n in naive_portions.items())
    naive_cost = cost_of(naive_portions)

    assert 1800 <= naive_calories <= 2200
    assert naive_protein >= 91
    assert naive_fat <= 65
    assert naive_sodium <= 1779
    assert all(n <= 3 for n in naive_portions.values())
    assert naive_cost == pytest.approx(7.25)

    baseline = run()
    assert naive_cost - baseline["cost"] == pytest.approx(0.50)

Generating code and tests is the easy half. Modeler also runs the suite in an isolated environment created fresh for this conversation, solving against Gurobi in the cloud — you do not need Gurobi installed locally, and you do not need a license of your own to see the model solve. It reads the output and fixes what it finds, so what you get back is a model that has been executed, not one that merely looks plausible.

The specification is now complete. One last question before moving to implementation: should the model be implemented as a Python class (e.g., DietOptimizer) with a solve() method, or as a standalone script that reads the CSV, solves, and prints the result directly?

The first option works for me. Go ahead and implement and run the model.

The user wants me to implement the model as a Python class with a solve() method. Let me start by searching the knowledge base for best practices and examples, and also ask the coding advisor for Python best practices simultaneously.

Querying the knowledge base.

Getting best practices for Python.

Now let me also read the current specification to make sure I have all details, and then implement the model.

Reading file diet_optimization_spec.md

Bear with me for just a bit longer; I’m gathering the information you need.

Now I have everything I need to implement the model. Let me write the complete implementation following all best practices.

Create the full DietOptimizer implementation following all coding best practices.

Now let me run the model to see if it works.

Execute the model against diet.csv to verify correctness and see the solution output.

I appreciate your understanding as I work through this. One moment please!

The model runs successfully. Now let me implement the unit tests.

Create pytest unit tests covering all four specification scenarios T1-T4.

Now let me run the tests one by one.

Run T1 test individually to check basic optimization.

Let me run the remaining tests.

Run T2 infeasibility test.

Let me run the remaining tests.

Run T3 and T4 tests.

The run, and the loop

The first run here failed on the infeasible scenario:

$ pytest test_diet_modeler.py -q
...F..
================================= FAILURES =================================
________________ test_t4_raising_protein_target_to_183_is_infeasible ________________

    def test_t4_raising_protein_target_to_183_is_infeasible():
        result = run(min_protein=183)

>       assert result["status"] == "infeasible"
E       KeyError: 'status'

1 failed, 5 passed in 0.64s

T4 fails with a KeyError rather than a wrong number, so this is not a modeling error: the solver correctly proved infeasibility, but solve_diet reads solution values unconditionally and never returns a status. Scenario T4 says “reported as infeasible”, so the specification and the test agree and the implementation is the side to fix. Adding a status check on model.Status before reading any attribute, then re-running.

One failure, and it was in the code rather than in the model: the implementation read solution values without first checking the solve status, so scenario T4 raised instead of reporting infeasibility. I added the status check and re-ran — all six scenarios pass.

$ pytest test_diet_modeler.py -q
......
6 passed in 0.61s

Gurobi Optimizer version 12.x (linux64)
Optimize a model with 5 rows, 9 columns and 45 nonzeros
Variable types: 0 continuous, 9 integer (0 binary)
...
Explored 1 nodes in 0.00 seconds (0.00 work units)
Best objective 6.750000000000e+00, best bound 6.750000000000e+00, gap 0.0000%

All six tests pass. Here is a full summary of everything that was built:

Results

Optimal solution

The shopper should buy the following portions at a total daily cost of $6.75:

Food	Portions	Unit price
Chicken	2	$1.89
Salad	3	$0.99

Nutritional totals achieved:

Nutrient	Achieved	Requirement
Calories	1800 kcal	1800–2200 kcal
Protein	157 g	>= 91 g
Fat	56 g	<= 65 g
Sodium	1070 mg	<= 1779 mg

Files created

File	Description
`diet_spec.md`	Complete problem specification
`diet.csv`	Input food dataset
`diet_modeler.py`	Gurobipy implementation (`solve_diet`)
`test_diet_modeler.py`	Pytest suite covering scenarios T1–T6

Test results

Test	Scenario	Result
T1	Baseline optimization (9 foods, 3-portion cap)	PASSED
T2	Salad price shock shifts the plan to macaroni	PASSED
T3	Raising the protein target to 150g leaves the plan unchanged	PASSED
T4	Raising the protein target to 183g is infeasible	PASSED
T5	Tightening the sodium cap changes the plan	PASSED
T6	Optimized plan beats a naive pick	PASSED

Let me know if you would like any changes, such as adjusting nutritional bounds, adding new constraints, or generating the mathematical formulation.

Learn More:
• Diet Optimization Examples ★★☆
• Nutritional Diet Model ★★☆

That log lands in the workspace as execution.log alongside the code, so the solve is auditable rather than asserted.

The loop ends one of two ways. Either every test passes, as here — or Modeler concludes a failure reflects a genuine contradiction between the specification, the implementation and the tests. In that case it stops instead of guessing, tells you what it found, and asks which side is the one to correct.

What the cloud environment gives you, and what it does not

The environment is built for validating a model, not for running production workloads. Python 3 is available with gurobipy, gurobipy-pandas, numpy, pandas, scipy and pytest pre-installed. Within that:

Solves use a Gurobi trial license, capped at 2,000 variables and 2,000 constraints. This model, at 9 columns and 5 rows, is nowhere near the cap — but a full-scale version of it, with hundreds of foods and per-nutrient constraints, could be.
Execution is limited to 60 seconds per command, with tight CPU and memory limits. This is why the generated tests use small hard-coded data and a short solver time limit.
Additional packages cannot be installed, there is no internet access, and Compute Server and Instant Cloud cannot be used.

So treat a passing suite as evidence that the model is right, not as a performance measurement. Download the implementation and run it against your own license and your own full data set for that. See Solving limits for the details.

Business problems do not hold still. The specification above puts a minimum amount of any particular food group out of scope — a reasonable simplification, until the shopper looks at the baseline plan (2 chicken, 3 salad) and worries it is too light on meat. Ask for the change in plain language and Modeler updates the specification first, then propagates it to the implementation and the tests, in that order.

This plan barely has any meat in it. Can you require at least 3 portions of meat a day?

This is a scope change, not a data correction: a minimum-from-a-food-group requirement is currently listed under “Out of scope”. There are three meat items on this menu — hamburger, hot dog and chicken — and “at least 3 portions of meat” could mean 3 combined portions from any mix of the three, or at least 1 portion of each of the three. Both are reasonable readings of the same sentence, and I cannot tell which the user meant from the request alone. I will implement the more literal reading — a combined total — since that is the plainer meaning of “3 portions,” but I should flag the alternative before the user assumes variety is guaranteed.

That moves a minimum-per-food-group requirement from out of scope into the model. I have updated the specification:

• Out of scope — removed the “minimum amount from any particular food group” bullet.
• Constraints — added C6: at least 3 combined portions of hamburger, hot dog and chicken a day.
• Test scenarios — re-derived the expected plan for T1, which the new constraint changes, and added T7 to check the alternative reading.

One thing to flag: I read “3 portions of meat” as a combined total, which the model can satisfy with 3 portions of chicken alone. If you actually wanted at least one portion of each meat item — hamburger, hot dog and chicken — that is a different, stricter constraint. I’ll implement the combined-total reading for now; let me know if you meant the other one.

Combined total is fine. Go ahead.

Specification, then code, then tests

The specification changes first. Section 3 gains a new constraint:

C6 -- At least 3 combined portions of hamburger, hot dog and chicken a day,
so the plan is not entirely meat-free.

The implementation follows the specification, not the other way around:

 def solve_diet(
     foods,
     cal_lo=MIN_CALORIES,
     cal_hi=MAX_CALORIES,
     min_protein=MIN_PROTEIN,
     max_fat=MAX_FAT,
     max_sodium=MAX_SODIUM,
     max_portions_per_food=MAX_PORTIONS_PER_FOOD,
+    min_meat_portions=MIN_MEAT_PORTIONS,
+    meat_foods=MEAT_FOODS,
     time_limit=None,
 ):
     ...
         gp.quicksum(foods[f]["sodium"] * x[f] for f in names) <= max_sodium,
         "max_sodium",
     )
+    # C6: at least min_meat_portions combined portions from meat_foods.
+    model.addConstr(
+        gp.quicksum(x[f] for f in meat_foods if f in names) >= min_meat_portions,
+        "min_meat",
+    )

T1 has to be re-derived — the plan it asserted is no longer optimal — and the suite gains one test for the alternative reading, to document that it behaves differently on purpose:

def test_t1_baseline_now_requires_3_combined_meat_portions():
    """T1: with C6 read as a combined total, 3 chicken alone satisfies
    it, shifting the plan to 3 chicken + 2 salad at $7.65."""
    result = run()

    assert result["status"] == "optimal"
    assert result["portions"] == {"chicken": 3, "salad": 2}
    assert result["cost"] == pytest.approx(7.65)


def test_t7_one_of_each_meat_item_is_infeasible():
    """T7: requiring at least 1 portion of each of hamburger, hot dog
    and chicken is infeasible -- hot dog alone is 1800mg sodium,
    already over the 1779mg cap."""
    result = run(require_each_meat_item=True)

    assert result["status"] == "infeasible"

Modeler re-runs the whole suite, not just the new test — the point of propagating in this order is that nothing is left stale behind the change.

Where it stops and asks

The ambiguity flagged during the conversation turns out to matter a great deal, not just in theory. “At least 3 portions of meat” has two natural readings when there are exactly 3 meat items on the menu — a combined total, or one of each — and they do not just differ in cost, one of them is infeasible outright:

Reading	Interpretation	Outcome
Combined total >= 3 portions	Any mix of hamburger, hot dog and chicken totaling 3	3 chicken + 2 salad, $7.65
At least 1 of each meat item	1 hamburger + 1 hot dog + 1 chicken, minimum	Infeasible — hot dog alone is 1800mg sodium, over the 1779mg cap

I implemented the combined-total reading, and it is a good thing I asked rather than assumed variety was implied: requiring one portion of each meat item is not just more expensive, it is infeasible. Hot dog alone carries 1800mg of sodium — over the 1779mg cap before anything else is even added to the plan. If “3 portions of meat” was meant to guarantee variety across hamburger, hot dog and chicken, that request cannot be satisfied under the current sodium target at all, and something else would have to give — a higher sodium cap, or dropping hot dog from the requirement. Which is closer to what you meant?

This is the loop ending in its second way: not a bug Modeler can fix, but a genuine ambiguity in what “3 portions of meat” was supposed to mean, one where picking wrong would have meant confidently returning an infeasible result as if it were a working plan. It reports what it found and hands the decision back rather than guessing.

The answer flips

Constraint	Plan	Cost
No meat minimum (original)	2 chicken + 3 salad	$6.75
Combined total >= 3 meat portions	3 chicken + 2 salad	$7.65
At least 1 of each meat item	—	Infeasible

Requiring 3 combined meat portions costs 90 cents a day — trading one salad portion for a third portion of chicken. The other reading does not cost more, it fails outright, because hot dog’s sodium leaves no room for anything else. That distinction only surfaced because the change went through the specification, where the ambiguity could be named and tested, rather than straight into the code.

The specification, the implementation and the tests never mention mathematics — that is deliberate, so the business owner can read them. But you may still need the formulation: to review the model, to document it, or to hand it to someone who thinks in constraints rather than in code. Ask at any point and Modeler derives one from the current specification and implementation, in Markdown with LaTeX, and saves it to the workspace with everything else.

Sets and indices

$i \in F = \{1, \dots, 9\}$: foods.

Parameters

$c_i$: price of one portion of food $i$.
$cal_i$: calories in one portion of food $i$.
$p_i$: protein (g) in one portion of food $i$.
$f_i$: fat (g) in one portion of food $i$.
$s_i$: sodium (mg) in one portion of food $i$.

Decision variables

$x_i \in \{0, 1, 2, 3\}$: whole portions of food $i$ to buy, capped at 3 by C5.

Objective function

Minimize total cost:

\[\min \; \sum_{i \in F} c_i \, x_i\]

Constraints

C1 — Calories fall within a daily target window.

\[1800 \leq \sum_{i \in F} cal_i \, x_i \leq 2200\]

C2 — Protein meets a daily minimum.

\[\sum_{i \in F} p_i \, x_i \geq 91\]

C3 — Fat stays under a daily cap.

\[\sum_{i \in F} f_i \, x_i \leq 65\]

C4 — Sodium stays under a daily cap.

\[\sum_{i \in F} s_i \, x_i \leq 1779\]

C5 — No single food may exceed 3 portions a day.

\[x_i \leq 3 \qquad \forall i \in F\]

Complete model

\[\begin{split}\begin{aligned} \min \quad & \sum_{i \in F} c_i \, x_i \\ \text{s.t.} \quad & 1800 \leq \sum_{i \in F} cal_i \, x_i \leq 2200 \\ & \sum_{i \in F} p_i \, x_i \geq 91 \\ & \sum_{i \in F} f_i \, x_i \leq 65 \\ & \sum_{i \in F} s_i \, x_i \leq 1779 \\ & 0 \leq x_i \leq 3, \; x_i \in \mathbb{Z} & \forall i \in F \end{aligned}\end{split}\]

Additional notes

The calorie constraint is a band, not a single bound — it needs two inequalities because the shopper wants a minimum and a maximum, unlike protein, fat and sodium, which each have only one side to enforce.
Portions are integer because the specification says “whole portions only.” Relaxing $x_i$ to continuous would let the model buy fractional portions, typically lowering the objective slightly, since it removes the rounding the integer restriction forces.
C5 is implemented as a variable bound ($x_i \leq 3$) rather than a separate constraint row, since a per-variable upper bound is handled directly by the solver without adding to the constraint matrix.
The model is feasible only when some combination of the nine foods, each capped at 3 portions, can simultaneously satisfy all four nutrient bounds — infeasibility here is a property of the whole food set under the cap, not of any single constraint, which is what makes scenario T4 (protein raised to 183g) fail outright rather than degrade gracefully.

Note that this is the formulation of the original model, before the minimum-meat-portions constraint added in the Changing the model tab. Gurobi’s own published diet example ships reference Python rather than a written formulation, and the calorie band and nutrient-minimum/maximum constraints in that code match C1 through C4 above; the per-food portion cap (C5) is specific to this conversation.

### Sets and indices

- $i \in F = \{1, \dots, 9\}$: foods.

### Parameters

- $c_i$: price of one portion of food $i$.
- $cal_i$: calories in one portion of food $i$.
- $p_i$: protein (g) in one portion of food $i$.
- $f_i$: fat (g) in one portion of food $i$.
- $s_i$: sodium (mg) in one portion of food $i$.

### Decision variables

- $x_i \in \{0, 1, 2, 3\}$: whole portions of food $i$ to buy, capped at 3 by **C5**.

### Objective function

Minimize total cost:

$$
\min \; \sum_{i \in F} c_i \, x_i
$$

### Constraints

**C1 — Calories fall within a daily target window.**

$$
1800 \leq \sum_{i \in F} cal_i \, x_i \leq 2200
$$

**C2 — Protein meets a daily minimum.**

$$
\sum_{i \in F} p_i \, x_i \geq 91
$$

**C3 — Fat stays under a daily cap.**

$$
\sum_{i \in F} f_i \, x_i \leq 65
$$

**C4 — Sodium stays under a daily cap.**

$$
\sum_{i \in F} s_i \, x_i \leq 1779
$$

**C5 — No single food may exceed 3 portions a day.**

$$
x_i \leq 3 \qquad \forall i \in F
$$

### Complete model

$$
\begin{aligned}
\min \quad & \sum_{i \in F} c_i \, x_i \\
\text{s.t.} \quad & 1800 \leq \sum_{i \in F} cal_i \, x_i \leq 2200 \\
& \sum_{i \in F} p_i \, x_i \geq 91 \\
& \sum_{i \in F} f_i \, x_i \leq 65 \\
& \sum_{i \in F} s_i \, x_i \leq 1779 \\
& 0 \leq x_i \leq 3, \; x_i \in \mathbb{Z} & \forall i \in F
\end{aligned}
$$

### Additional notes

- The calorie constraint is a band, not a single bound — it needs two
  inequalities because the shopper wants a minimum and a maximum, unlike
  protein, fat and sodium, which each have only one side to enforce.

- Portions are integer because the specification says "whole portions only."
  Relaxing $x_i$ to continuous would let the model buy fractional portions,
  typically lowering the objective slightly, since it removes the rounding
  the integer restriction forces.

- C5 is implemented as a variable bound ($x_i \leq 3$) rather than a separate
  constraint row, since a per-variable upper bound is handled directly by the
  solver without adding to the constraint matrix.

- The model is feasible only when some combination of the nine foods, each
  capped at 3 portions, can simultaneously satisfy all four nutrient bounds —
  infeasibility here is a property of the whole food set under the cap, not of
  any single constraint, which is what makes scenario T4 (protein raised to
  183g) fail outright rather than degrade gracefully.

Note that this is the formulation of the original model, before the
minimum-meat-portions constraint added in the **Changing the model** tab.
Gurobi's own [published diet example](https://docs.gurobi.com/projects/examples/en/current/examples/python/diet.html)
ships reference Python rather than a written formulation, and the calorie band
and nutrient-minimum/maximum constraints in that code match C1 through C4
above; the per-food portion cap (C5) is specific to this conversation.

Press `/` or click to search this documentation	Gurobi website	Gurobi community forum
Go to other Gurobi documentation	Gurobi download	Contact support