Cuopt Multi Objective Exploration

NVIDIAOfficialCreated by NVIDIA cuOpt Team

Skill
Workflow
Data and AI
Apache-2.0
Medium risk

From the author

Trace, complete, and interpret the Pareto frontier across competing objectives using repeated single-objective cuOpt solves (weighted-sum and ε-constraint).

— the description by NVIDIA cuOpt Team

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a systematic workflow for exploring multi-objective optimization problems where competing goals, such as cost versus service level, cannot be collapsed into a single weighted objective. By orchestrating a series of single-objective solves using either weighted-sum or epsilon-constraint methods, the skill enables the construction of a Pareto frontier. It emphasizes the importance of identifying non-dominated solutions, normalizing objectives, and interpreting the resulting tradeoffs through dual values or point-to-point analysis, ensuring users can make informed decisions based on the full range of possibilities rather than a single, potentially arbitrary, optimal point.

What it does

Defines objectives and establishes a payoff table to determine feasible ranges.
Implements weighted-sum scalarization for quick convex frontier sketches.
Uses the epsilon-constraint method to recover complete frontiers, including non-convex regions.
Filters dominated and duplicate solutions to isolate the true Pareto frontier.
Identifies and fills gaps in the frontier to ensure high-fidelity results.
Calculates local exchange rates to quantify tradeoffs between competing objectives.

When to use it

When a problem has two or more conflicting objectives with no agreed-upon weighting.
When you need to present a range of optimal options rather than a single answer.
When you need to understand the 'cost' of relaxing one constraint to improve another.
When working with MILP models where weighted-sum methods may fail to capture the full frontier.

Advantages

Prevents the silent, arbitrary collapse of multi-objective problems into a single point.
Provides a rigorous method to identify the most efficient tradeoffs.
Enables the discovery of non-convex regions of the frontier via epsilon-constraint.
Supports warm-starting to optimize performance across multiple iterative solves.

Usage examples

“How do I balance delivery cost and vehicle count in my routing model?”: The agent will guide you to formulate both as objectives, build a payoff table, and use the epsilon-constraint method to sweep vehicle counts, resulting in a Pareto frontier showing the cost-per-vehicle tradeoff.
“I have a budget constraint and a service level target; how do I see the tradeoff?”: The agent will help you promote the budget to an epsilon-constraint, sweep it across a range of values, and plot the resulting frontier to show the maximum achievable service level for every budget increment.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/nvidia/cuopt-multi-objective-exploration/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip cuopt-multi-objective-exploration.zip -d .agents/skills

Documentation by NVIDIA cuOpt Team

Multi-Objective Exploration

cuOpt optimizes one objective per solve. Many real problems have several objectives that pull against each other — cost vs. service level, return vs. risk, makespan vs. overtime, distance vs. vehicle count. A single solve answers "what's optimal for one particular weighting," but it hides the tradeoff the user actually needs to see.

This skill turns a sequence of single-objective cuOpt solves into a Pareto frontier — the set of solutions where you can't improve one objective without giving up another — and gives the discipline to read it. It adds no solver features; it orchestrates the LP / MILP / QP solves already covered by the formulation and API skills.

When this applies

Reach for this workflow when the problem has two or more objectives with no agreed-upon weighting, signalled by language like:

"balance X and Y", "trade off", "as cheap as possible without hurting service"
"minimize cost and maximize coverage", "I want options, not one answer"
any objective the user is willing to relax in exchange for another

If there is a single clear objective (everything else is a hard constraint), this skill does not apply — formulate and solve once.

Core idea — one solve is one point on a curve

A single optimum encodes one implicit weighting of the objectives. Change the weighting and the optimum moves. The frontier is the curve traced by all the non-dominated optima.

A solution A dominates B when A is at least as good on every objective and strictly better on one. Dominated solutions are never worth choosing. The Pareto frontier is exactly the non-dominated set; the user's job is to pick a point on it, and yours is to show them the whole curve plus where the tradeoff is sharpest.

Do not collapse a multi-objective problem to a single weighted number and report its optimum as "the answer" — that silently makes the tradeoff decision for the user. Trace the frontier and let them choose.

Objectives and constraints are interchangeable. A requirement currently treated as fixed — a coverage floor, a fairness cap, a budget — is often a latent objective: its level was assumed, not given. Promoting such a constraint to a parametric ε-constraint and sweeping it reveals a tradeoff you'd otherwise hide, so read a single-objective model's hard constraints as candidate objectives, not just limits — but only when the level was an assumption. A genuinely fixed, non-negotiable limit (a hard budget cap, a regulatory minimum) stays a constraint; don't manufacture a tradeoff that isn't there. Express any promoted quantity linearly so it can serve as an ε-constraint (see cuopt-numerical-optimization-formulation).

Step 1 — define the objectives

An informative frontier needs objectives that genuinely conflict: if they don't pull against each other, it collapses to a single point with nothing to trade off. And each objective has to be formulated correctly, since a wrong form, sense, or scale distorts the tradeoff and shifts where the knee falls. Formulate each one with cuopt-numerical-optimization-formulation before sweeping.

Step 2 — build a payoff table (anchor each objective)

Solve each objective on its own first. For k objectives this is k solves. Record, for each, the value of every objective at that optimum:

              f1        f2        f3
min f1   →   f1*       f2(at f1*) f3(at f1*)
min f2   →   ...       f2*        ...
min f3   →   ...       ...        f3*

The diagonal (f1*, f2*, …) is each objective's best achievable value; the off-diagonals give the range each objective spans across the others' optima. This table does double duty:

It sets the sweep bounds for the ε-constraint method (the feasible range of each constrained objective).
It supplies the scales for normalization — objectives in dollars, percent, and hours can't be weighted meaningfully until divided by their ranges.

If any single-objective solve is already infeasible, stop and fix the model before sweeping — the frontier doesn't exist yet.

Step 3 — choose a scalarization

Weighted sum

Combine the objectives into one and sweep the weights:

minimize  w1·f1(x) + w2·f2(x) + ... ,   for a grid of weight vectors w

Cheap and trivial with any solver. Two limitations to respect:

It only finds points on the convex hull of the frontier. Concave (non-convex) regions of the frontier are unreachable no matter how you choose weights, and for MILP the reachable points can be sparse with large gaps. A frontier that looks suspiciously linear or has only a few clustered points is the symptom.
Weights are not priorities until the objectives are normalized. Divide each f_k by its payoff-table range first; otherwise the largest-magnitude objective dominates regardless of intent.

ε-constraint (preferred for a complete frontier)

Keep one objective; move the rest to constraints and sweep their right-hand sides:

minimize  f1(x)
subject to  f2(x) ≤ ε2
            f3(x) ≤ ε3
            (original constraints)

Sweep each ε_k across the range from the payoff table. Each (ε2, ε3, …) combination is a single standard cuOpt solve. This recovers the full frontier, including the concave regions weighted-sum cannot reach, which is why it's the default when completeness matters. The cost is more solves (a grid over the constrained objectives) and bookkeeping of the ε values.

ε-constrain linear objectives directly. A quadratic objective (e.g. risk xᵀΣx) is simplest kept as the objective f1 while you ε-constrain the linear ones. A convex quadratic objective can instead be ε-constrained directly: add it as a quadratic constraint xᵀQx ≤ ε, which cuOpt supports. Non-convex or equality quadratic constraints are unsupported, and the MILP path stays linear-constraint only.

Spot it in existing code: a hand-coded loop over a target or budget value (a return target, a cost cap) is already the ε-constraint method — name it as such, filter dominated points, and read the swept constraint's dual (LP/QP only).

Read that dual as the local exchange rate. Where the frontier is smooth, the dual on a swept ε-constraint is its slope — how much the kept objective f1 moves per unit of the bound — at no cost beyond the solve already run; at a kink it gives only a one-sided rate. A zero dual usually means the bound is slack — the sweep has run past the frontier's edge (one-way: a slack bound always shows a zero dual, but under degeneracy a binding bound can too). This reading needs LP/QP and a linear ε-constraint (MILP optima and problems with quadratic constraints return no duals) — where duals are unavailable, difference adjacent frontier points instead.

Picking a method: weighted-sum for a quick convex sketch or when you know the frontier is convex (e.g. a pure-LP/QP tradeoff); ε-constraint when the problem is MILP, when the frontier may be non-convex, or when the user needs a faithful and complete curve.

Step 4 — sweep, collect, and filter

frontier = []
for each weight vector (or ε vector) in the grid:
    set the combined objective (or ε right-hand sides)
    solve with cuOpt              # reuse the prior solution as a warm start
    if status is Optimal/Feasible:
        record (objective values, solution)
discard dominated and duplicate points
sort the survivors to form the frontier

Practical notes:

Warm-start LP sweeps. For an LP frontier, carry the previous solve's PDLP warmstart data into the next to cut solve time. Per cuOpt this is LP-only: a MILP solve doesn't take a PDLP warmstart (you can optionally seed a MIP start instead). See cuopt-numerical-optimization-api for the calls.
Cap each MILP solve. Set a per-solve time limit on MILP sweeps (see cuopt-numerical-optimization-api) — a sweep is many solves, and branch-and-bound can over-spend certifying optimality past a tiny gap, while cuOpt sets no limit by default and won't warn. Report the points as optimal to the gap you set, not certified optimal.
Filter dominated points. A correct sweep can still emit dominated points (especially weighted-sum near the hull, or MILP). Drop them; they are not part of the frontier.
Resolution is a budget. Curve fidelity trades against solve count. Start coarse to see the shape, then refine the grid only where the curve bends.
Spend the budget where the slope changes (LP/QP). Because the ε-constraint dual is the frontier's local slope, compare it across solved points: where it barely changes, the curve is nearly straight — interpolate rather than add solves; where it jumps by more than the solve tolerance, the frontier bends between those points — refine there (smaller differences are solver noise, not curvature). This concentrates solves where the curve actually bends instead of spreading them over a uniform grid. On MILP, judge where to refine from the gaps between primal objective values instead.
Verify, don't assume. When you claim one method beats another, measure it — e.g. count the efficient points ε-constraint recovered that weighted-sum missed — rather than asserting it; and flag any solve returning feasible-but-not-Optimal so a non-certified point is never read as exact.

Step 5 — complete the frontier: measure and fill what the sweep missed

A weighted-sum sweep returns only supported points (Step 3's convex-hull limitation); on MILP frontiers, non-supported points — the ones no weighted-sum weighting returns — often make up much of the non-dominated set. A coarse ε-constraint grid leaves gaps the same way: any finite sweep can miss regions. Before presenting a swept frontier, measure the likely miss and decide whether to fill.

Measure the miss

Sort the swept points by one objective. For each adjacent pair, form the rectangle (in general, the box) between them in objective space; flag any box much larger than the median adjacent box (3× is a reasonable bar) or covering a large share of the frontier's spanned area — a sweep that returned only a handful of points is all gaps, so no box stands out from the median. Large boxes have two causes — non-supported regions (weighted sum cannot reach them, common under fixed-charge structure) and weight clustering (a finite grid re-discovering the same corners, even on a nearly convex frontier). The fill step treats both the same.

If all boxes are small and even, the sweep is likely adequate — say so and stop.

Fill the largest gaps first

For each flagged box, solve one ε-constraint subproblem targeted inside it: optimize one objective with the other bounded at the box midpoint (bi-objective; with more objectives, sort by each objective in turn and place one target per flagged box instead of recursing). Only certified Optimal results settle or steer anything here — a time-limited incumbent is kept as a point (tagged, below) but proves nothing about the gap. A new certified point that survives Step 4's dominance filter means the gap was real (an ε solve can return a weakly optimal point) — bisect: two more targets inside the two sub-boxes it creates. A certified endpoint coming back clears just the probed side of the bound; certifying the whole box as a true discontinuity also needs a known objective step size — all-integer objective coefficients over integer variables give one — to place the bound just inside the far endpoint and match its certified optimum. Without that step size, report the box as a candidate gap, not a proven discontinuity. Stop on a solve budget, or when the remaining boxes fall below the flag bar.

Warm-start each solve (cheap insurance)

Consecutive fill solves differ by one bound, so seed each with its neighbor as a MIP start (Step 4's warm-start note) — one line, and it never changes what is optimal. Expect unchanged solve times; the value is insurance on hard subproblems.

Degrade gracefully, never silently

If a subproblem hits its time limit with a feasible incumbent (FeasibleFound), keep the point — it is feasible, and the solve's reported gap bounds its suboptimality — but record it as approximate. The time-capped solve is the primary fallback: it returns both an incumbent and a bound.

Report with provenance

Every presented point carries one of two tags:

exact — Optimal at your gap setting, i.e. optimal to that gap (Step 4);
approximate — time-limited incumbent (quote its reported gap).

State the counts with the frontier ("14 points, 11 exact, 3 approximate near the low-cost end, worst gap 2.4%"). Never present a mixed frontier as uniformly optimal.

Step 6 — interpret the frontier

Report tradeoffs, not single numbers. A frontier point means nothing in isolation. Quote the exchange rate — "≈ $4k of extra cost per 1% of added coverage in this region" — so the user can judge whether a move is worth it. On an LP/QP frontier this exchange rate is the swept constraint's dual at that point — the local slope of the frontier, accurate to the solve's optimality tolerance (tighten it before relying on a dual); on MILP, estimate it from the gap to the adjacent frontier point.
Flag knee points; don't auto-pick them. The "knee" is where the curve bends most sharply — beyond it you pay a lot for a little. It's often the best-balanced compromise and worth highlighting, but the final choice is the user's preference, not a rule. At the knee the slope is two-sided — the dual just below differs from just above — so quote the exchange rate there as a range, not one number.
Treat dominated or gappy output as a diagnostic. If dominated points survive filtering, or the frontier is implausibly sparse or perfectly linear, suspect the sweep or the model — most often weighted-sum hiding a concave region (return to Step 5 and fill the gaps) or a normalization mistake.
State the weighting/ε you used. Every reported point is conditional on its scalarization. Make that explicit so a single solve is never mistaken for "the" optimum. On LP/QP, the ε-constraint duals are the implicit weights at that point — the effective price the solution puts on each constrained objective, and the weights a weighted-sum solve would need to reproduce that tradeoff. Reporting them makes the accepted tradeoff ratio explicit.

Interfaces

This skill is solver- and interface-agnostic. The per-solve mechanics — building the objective, adding the ε constraints, passing a warm start, reading status — live in the API skills:

cuopt-numerical-optimization-api — LP, MILP, QP solves (Python, C, CLI).
cuopt-routing-api-python — the same frontier workflow applies to routing tradeoffs (distance vs. vehicles vs. time).

Files

ATTRIBUTION.mdAdded by AutoGineer968 B
BENCHMARK.md8.9 KiB
LICENSELicence file added by AutoGineer11.2 KiB
SKILL.md15.0 KiB
evals/evals.json14.5 KiB
skill-card.md5.1 KiB
skill.oms.sig4.5 KiB

evals/evals.json

[
  {
    "id": "multiobj-explore-eval-001-supplier-interpretation",
    "question": "A procurement lead is sourcing a component. The candidate suppliers lie on a cost-vs-reliability tradeoff (cheaper tends to be less reliable): CN03 cost $7.05 reliability 81.1; SEA03 $7.63 / 82.6; LA04 $9.93 / 87.2; EU04 $11.29 / 88.2; NA01 $11.74 / 90.3; NA03 $12.33 / 91.0; NA04 $13.37 / 91.1. She asks: 'Which suppliers should we commit to?' Advise her.",
    "expected_skill": "cuopt-multi-objective-exploration",
    "expected_script": null,
    "ground_truth": "The agent treats this as a two-objective tradeoff with no fixed weighting. It does NOT collapse to a single 'best' supplier; it lays out the cost/reliability tradeoff, quotes the exchange rate (e.g. roughly how much cost per reliability point between adjacent options), flags the knee/balanced region, states the assumption behind any option it highlights, and leaves the final pick to the lead (often a diversified mix rather than one supplier).",
    "expected_behavior": [
      "Frames it as two competing objectives (cost vs reliability) with no agreed weighting",
      "Does NOT declare one supplier as THE answer; preserves a genuine choice across options",
      "Quantifies the tradeoff as an exchange rate (cost per unit of reliability, or vice versa)",
      "Flags a knee / balanced region but leaves the final pick to the lead",
      "States where on the tradeoff any specific option it names sits"
    ]
  },
  {
    "id": "multiobj-explore-eval-002-supplier-exploration",
    "question": "A procurement lead must choose which of 12 candidate suppliers to contract to maximize total supply-chain resilience and minimize total annual cost, while covering required demand. There is no agreed weighting between resilience and cost. Using cuOpt, how would you approach this and what would you report back?",
    "expected_skill": "cuopt-multi-objective-exploration",
    "expected_script": null,
    "ground_truth": "The agent recognizes a multi-objective (resilience vs cost) selection problem with no fixed weighting and a hard demand constraint, builds a payoff table by solving each objective alone for ranges, then traces the Pareto frontier with repeated single-objective cuOpt solves. Because the supplier selection is combinatorial (non-convex), it prefers the epsilon-constraint method (e.g. minimize cost subject to a resilience floor, sweeping the floor) over weighted-sum, which would miss non-supported portfolios. It filters dominated points and reports the tradeoff curve plus the knee, deferring the final pick, and defers per-solve mechanics to the api-* skills and formulation to cuopt-numerical-optimization-formulation.",
    "expected_behavior": [
      "Recognizes two competing objectives with no agreed weighting; does NOT collapse to one weighted optimum",
      "Builds a payoff table (each objective alone) for ranges/normalization",
      "Traces the Pareto frontier via repeated single-objective cuOpt solves; prefers epsilon-constraint over weighted-sum for completeness on a non-convex/MILP problem",
      "Filters dominated and duplicate portfolios",
      "Reports the tradeoff and flags the knee, leaving the final pick to the lead",
      "Since supplier selection is MILP (no duals), estimates the cost/resilience exchange rate by differencing adjacent frontier points, not from constraint duals"
    ]
  },
  {
    "id": "multiobj-explore-eval-004-dual-exchange-rate",
    "question": "An analyst is building a risk-return efficient frontier across a set of assets: minimize portfolio variance and maximize expected return, with no fixed risk appetite. Using cuOpt, how would you trace the frontier, and at each point how would you tell the investor the rate at which they are paying variance for extra return without spending additional solves?",
    "expected_skill": "cuopt-multi-objective-exploration",
    "expected_script": null,
    "ground_truth": "The agent recognizes a two-objective tradeoff (variance vs return) with no fixed weighting and traces the frontier by epsilon-constraint: it keeps the quadratic variance as the objective and sweeps a linear return floor (return >= epsilon), each value a single convex QP solve. At each solved point it reads the dual value on the binding (linear) return-floor constraint as the marginal variance per unit of required return -- the local exchange rate, i.e. the slope (tangent) of the frontier at that point -- taken directly off the solve at no extra cost rather than by differencing two adjacent points, and accurate to the solve's optimality tolerance. It notes the dual reading applies to continuous LP/QP solutions, not MILP, and that the swept constraint must be linear since any quadratic constraint makes cuOpt return no duals for the whole solve. It filters dominated points, flags the knee, and leaves the risk appetite to the investor, deferring per-solve mechanics to the api-* skills and formulation to cuopt-numerical-optimization-formulation.",
    "expected_behavior": [
      "Frames variance vs return as two competing objectives with no agreed weighting",
      "Traces the frontier via epsilon-constraint, keeping the quadratic variance as the objective and sweeping a linear return floor (each a single QP solve)",
      "Reads the swept (linear) constraint's dual as the local exchange rate (marginal variance per unit return) and slope of the frontier, taken straight off each solve rather than by differencing",
      "Notes the dual / exchange-rate reading applies to continuous LP/QP, not MILP, and is accurate to the solve tolerance",
      "Filters dominated points, flags the knee, and leaves the final risk appetite to the investor"
    ]
  },
  {
    "id": "multiobj-explore-eval-003-single-objective-decoy",
    "question": "A procurement lead must contract suppliers to MAXIMIZE total supply-chain resilience, but the annual budget is hard-capped: total cost must not exceed $34 (a firm limit, not negotiable), and the set must cover demand. Which suppliers should we contract?",
    "expected_skill": null,
    "expected_script": null,
    "ground_truth": "DECOY (negative) — the multi-objective-exploration skill should NOT activate. There is a single clear objective (maximize resilience) with the cost as a hard constraint, so there is no tradeoff to explore. The correct response is a single optimization (maximize resilience subject to cost <= 34 and demand coverage) returning ONE recommended supplier set, not a Pareto sweep or a range of options.",
    "expected_behavior": [
      "Recognizes a single objective with a hard constraint, not a tradeoff",
      "Does NOT trace a frontier or sweep the budget as if it were a tradeoff dial",
      "Returns one recommended supplier set (one solve), citing the binding budget and demand coverage"
    ]
  },
  {
    "id": "multiobj-explore-eval-005-latent-objective",
    "question": "A planner runs a multi-period production model to MAXIMIZE priority-weighted finished-goods inventory at the end of a 10-period horizon. The model also carries full cost data — per-item unit and holding costs, per-resource hourly production cost — but the current objective ignores it, and leadership has set no budget. The planner asks: 'Push supply as high as it will go — what's the plan?' Using cuOpt, how would you respond?",
    "expected_skill": "cuopt-multi-objective-exploration",
    "expected_script": null,
    "ground_truth": "The agent recognizes that cost is a SECOND objective sitting latent in the problem — the data is present and no budget pins it down — and does NOT simply return the single maximum-supply plan, nor silently fold cost into a weighted-sum blend (maximize supply minus lambda*cost) with a self-chosen lambda. It surfaces the supply-vs-cost tradeoff and traces the Pareto frontier with cuOpt by epsilon-constraint (cap total cost, maximize supply, sweep the cap from tight to slack). Because the model is a MILP (no usable duals), it estimates the supply-per-dollar exchange rate by differencing adjacent frontier points, reports supply in interpretable units rather than the raw priority-weighted total, flags the knee where supply per dollar collapses, names two or three candidate operating points, and defers the budget decision to leadership. It distinguishes this from a hard-budget case: cost is unconstrained here, so the right move is to expose the tradeoff, not to pick one plan. It defers per-solve mechanics to the api-* skills and formulation to cuopt-numerical-optimization-formulation.",
    "expected_behavior": [
      "Recognizes a LATENT second objective (cost) present in the data but unstated; does NOT optimize the single stated objective (supply) in isolation",
      "Does NOT silently collapse to a weighted-sum blend (maximize supply minus lambda*cost) with a self-chosen weight",
      "Surfaces the supply-vs-cost tradeoff and traces the Pareto frontier via epsilon-constraint (sweep a total-cost cap, maximize supply)",
      "Since the model is MILP (no duals), estimates the supply-per-dollar exchange rate by differencing adjacent frontier points",
      "Reports supply in interpretable units, flags the knee, names candidate operating points, and defers the budget call to leadership",
      "Distinguishes this from a hard-budget case (cf. the decoy): cost is unconstrained here, so it exposes the tradeoff rather than returning a single plan"
    ]
  },
  {
    "id": "multiobj-explore-eval-006-gap-detection-completion",
    "question": "A planner swept 20 weight combinations over cost and coverage for a facility-selection MILP and got only 6 distinct plans, with a big empty stretch in the middle of the curve. She asks: 'Are there really no options in between, or is my sweep missing them?' Advise her.",
    "expected_skill": "cuopt-multi-objective-exploration",
    "expected_script": null,
    "ground_truth": "The agent recognizes the symptom of a weighted-sum sweep on a MILP: weighted-sum reaches only supported points (the convex hull of the frontier), so non-supported plans in between are invisible no matter how many weights are tried. It does NOT recommend simply adding more weight vectors. It measures the miss by forming the boxes between adjacent swept points, treats boxes much larger than the median spacing as candidate gaps, and fills the largest first with targeted epsilon-constraint subproblems (optimize one objective with the other bounded inside the box, bisecting when a new point appears). It notes that only certified Optimal solves settle a gap (a time-limited incumbent proves nothing), that a probe returning an existing endpoint clears just the probed side of the bound, and that certifying a true discontinuity additionally needs a known objective step size (e.g. all-integer objective coefficients over integer variables) to place a bound just inside the far endpoint -- otherwise the region is reported as a candidate gap, not a proven one -- and that filling stops on a solve budget or when the remaining boxes are small. It defers per-solve mechanics to the api skills and formulation to cuopt-numerical-optimization-formulation.",
    "expected_behavior": [
      "Attributes the empty stretch to weighted-sum reaching only supported (convex-hull) points on a MILP, not to the intermediate options being absent",
      "Does NOT prescribe more weight vectors as the fix",
      "Measures the miss via the boxes between adjacent swept points and flags outsized boxes as candidate gaps",
      "Fills the largest gaps first with targeted epsilon-constraint subproblems bounded inside each box, bisecting when new points appear",
      "Does NOT declare a gap empty from a single midpoint probe; certifies a discontinuity only with certified Optimal solves plus a known objective step size (bound just inside the far endpoint), otherwise reports a candidate gap; stops on a solve budget or size threshold"
    ]
  },
  {
    "id": "multiobj-explore-eval-007-provenance-reporting",
    "question": "While tracing a cost-vs-emissions frontier for a plant-scheduling MILP with per-solve time limits, three of an analyst's epsilon-constraint solves hit their limit but returned feasible solutions. He asks: 'Can I include those points in the tradeoff table I hand my team?' Advise him.",
    "expected_skill": "cuopt-multi-objective-exploration",
    "expected_script": null,
    "ground_truth": "The agent says yes, keep the time-limited incumbents — they are feasible and near the frontier — but only with provenance: every point in the table is tagged exact (proved optimal for its scalarization at the gap setting) or approximate (time-limited incumbent), each time-limited incumbent quoting its solver-reported remaining gap or bound, and the two counts are reported alongside the frontier (e.g. '14 points, 11 exact, 3 approximate near the low-cost end, worst gap 2%'). The mixed frontier is never presented as uniformly optimal; silently including the points and discarding them are both wrong. Optionally it notes that a larger per-solve budget can later upgrade approximate points to exact.",
    "expected_behavior": [
      "Keeps the feasible time-limited incumbents rather than discarding them",
      "Tags every reported point exact or approximate and reports the two counts with the frontier",
      "Never presents the mixed frontier as uniformly optimal; approximate points are identified, not silently included",
      "Distinguishes proved-optimal-at-gap (exact) from time-limited results (approximate), quoting each incumbent's reported gap or bound",
      "Leaves the tradeoff choice to the team; the table shows options, not one answer"
    ]
  },
  {
    "id": "multiobj-explore-eval-008-single-objective-lp-decoy",
    "question": "A plant manager wants next month's production schedule at MINIMUM total cost, subject to machine capacity, labor hours, and contracted demand — all firm requirements. Report the optimal schedule and its cost.",
    "expected_skill": null,
    "expected_script": null,
    "ground_truth": "DECOY (negative) — the multi-objective-exploration skill should NOT activate, and in particular the front-completion workflow should not. There is a single clear objective (minimize cost) and the requirements are genuinely fixed, so there is no tradeoff to explore, no frontier to trace, and no gaps to measure or fill. The correct response is one optimization solve returning ONE schedule and its cost.",
    "expected_behavior": [
      "Recognizes a single objective with hard constraints, not a tradeoff",
      "Does NOT trace a frontier, sweep weights or epsilon bounds, or run any gap-measurement/fill pass",
      "Returns one optimal schedule and its cost from one solve"
    ]
  }
]

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python

Security

What our scanner noticed· Medium risk

Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by

NVIDIA cuOpt Team

Publisher

NVIDIA (Official)

Source

NVIDIA/skills · skills/cuopt-multi-objective-exploration · commit fce3cca

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE-APACHE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

AutoGineer is not affiliated with or endorsed by NVIDIA cuOpt Team or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download cuopt-multi-objective-exploration.zip