[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-nvidia-cuopt-multi-objective-exploration":3,"mdc--rv0921-key":31,"related-repo-nvidia-cuopt-multi-objective-exploration":747,"related-org-nvidia-cuopt-multi-objective-exploration":853},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":20,"repoUrl":21,"updatedAt":22,"license":23,"forks":24,"topics":25,"repo":26,"sourceUrl":29,"mdContent":30},"cuopt-multi-objective-exploration","explore Pareto frontiers with cuOpt","Trace and interpret the Pareto frontier across competing objectives using repeated single-objective cuOpt solves (weighted-sum and ε-constraint).",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},"nvidia","NVIDIA","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fnvidia.png",[12,16,19],{"name":13,"slug":14,"type":15},"Mathematics","mathematics","tag",{"name":17,"slug":18,"type":15},"Optimization","optimization",{"name":9,"slug":8,"type":15},2473,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills","2026-07-14T05:27:11.448811","Apache-2.0",281,[],{"repoUrl":21,"stars":20,"forks":24,"topics":27,"description":28},[],"AI agent skills published by NVIDIA","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills\u002Ftree\u002FHEAD\u002Fskills\u002Fcuopt-multi-objective-exploration","---\nname: cuopt-multi-objective-exploration\nversion: \"26.08.00\"\ndescription: Trace and interpret the Pareto frontier across competing objectives using repeated single-objective cuOpt solves (weighted-sum and ε-constraint).\nlicense: Apache-2.0\norigin: cuopt-skill-evolution\nmetadata:\n  author: NVIDIA cuOpt Team\n  tags:\n    - multi-objective\n    - pareto\n    - epsilon-constraint\n    - tradeoff\n    - workflow\n---\n\n\n\n# Multi-Objective Exploration\n\n\ncuOpt 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.\n\nThis 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 \u002F MILP \u002F QP solves already covered by the formulation and API skills.\n\n## When this applies\n\nReach for this workflow when the problem has **two or more objectives with no agreed-upon weighting**, signalled by language like:\n\n- \"balance X and Y\", \"trade off\", \"as cheap as possible *without* hurting service\"\n- \"minimize cost *and* maximize coverage\", \"I want options, not one answer\"\n- any objective the user is willing to relax in exchange for another\n\nIf there is a single clear objective (everything else is a hard constraint), this skill does not apply — formulate and solve once.\n\n## Core idea — one solve is one point on a curve\n\nA 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.\n\nA 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.\n\nDo 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.\n\nObjectives 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`).\n\n## Step 1 — define the objectives\n\nAn 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.\n\n## Step 2 — build a payoff table (anchor each objective)\n\nSolve each objective **on its own** first. For *k* objectives this is *k* solves. Record, for each, the value of every objective at that optimum:\n\n```text\n              f1        f2        f3\nmin f1   →   f1*       f2(at f1*) f3(at f1*)\nmin f2   →   ...       f2*        ...\nmin f3   →   ...       ...        f3*\n```\n\nThe 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:\n\n- It sets the **sweep bounds** for the ε-constraint method (the feasible range of each constrained objective).\n- It supplies the **scales** for normalization — objectives in dollars, percent, and hours can't be weighted meaningfully until divided by their ranges.\n\nIf any single-objective solve is already infeasible, stop and fix the model before sweeping — the frontier doesn't exist yet.\n\n## Step 3 — choose a scalarization\n\n### Weighted sum\n\nCombine the objectives into one and sweep the weights:\n\n```text\nminimize  w1·f1(x) + w2·f2(x) + ... ,   for a grid of weight vectors w\n```\n\nCheap and trivial with any solver. Two limitations to respect:\n\n- **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.\n- **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.\n\n### ε-constraint (preferred for a complete frontier)\n\nKeep one objective; move the rest to constraints and sweep their right-hand sides:\n\n```text\nminimize  f1(x)\nsubject to  f2(x) ≤ ε2\n            f3(x) ≤ ε3\n            (original constraints)\n```\n\nSweep 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.\n\nε-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.\n\nSpot 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\u002FQP only).\n\n**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 means the bound is slack: the sweep has run past the frontier's edge. This reading needs LP\u002FQP and a *linear* ε-constraint (MILP optima and problems with quadratic constraints return no duals) — where duals are unavailable, difference adjacent frontier points instead.\n\n**Picking a method:** weighted-sum for a quick convex sketch or when you know the frontier is convex (e.g. a pure-LP\u002FQP tradeoff); ε-constraint when the problem is MILP, when the frontier may be non-convex, or when the user needs a faithful and complete curve.\n\n## Step 4 — sweep, collect, and filter\n\n```text\nfrontier = []\nfor each weight vector (or ε vector) in the grid:\n    set the combined objective (or ε right-hand sides)\n    solve with cuOpt              # reuse the prior solution as a warm start\n    if status is Optimal\u002FFeasible:\n        record (objective values, solution)\ndiscard dominated and duplicate points\nsort the survivors to form the frontier\n```\n\nPractical notes:\n\n- **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.\n- **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.\n- **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.\n- **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.\n- **Spend the budget where the slope changes (LP\u002FQP).** 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.\n- **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.\n\n## Step 5 — interpret the frontier\n\n- **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\u002FQP 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.\n- **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.\n- **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 (switch to ε-constraint) or a normalization mistake.\n- **State the weighting\u002Fε 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\u002FQP, 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.\n\n## Interfaces\n\nThis 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:\n\n- `cuopt-numerical-optimization-api` — LP, MILP, QP solves (Python, C, CLI).\n- `cuopt-routing-api-python` — the same frontier workflow applies to routing tradeoffs (distance vs. vehicles vs. time).\n",{"data":32,"body":43},{"name":4,"version":33,"description":6,"license":23,"origin":34,"metadata":35},"26.08.00","cuopt-skill-evolution",{"author":36,"tags":37},"NVIDIA cuOpt Team",[38,39,40,41,42],"multi-objective","pareto","epsilon-constraint","tradeoff","workflow",{"type":44,"children":45},"root",[46,55,77,89,96,108,142,147,153,165,183,195,209,215,227,233,258,270,298,325,330,336,343,348,357,362,393,399,404,413,441,491,496,526,536,542,551,556,656,662,712,718,723],{"type":47,"tag":48,"props":49,"children":51},"element","h1",{"id":50},"multi-objective-exploration",[52],{"type":53,"value":54},"text","Multi-Objective Exploration",{"type":47,"tag":56,"props":57,"children":58},"p",{},[59,61,67,69,75],{"type":53,"value":60},"cuOpt optimizes ",{"type":47,"tag":62,"props":63,"children":64},"strong",{},[65],{"type":53,"value":66},"one",{"type":53,"value":68}," 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 ",{"type":47,"tag":70,"props":71,"children":72},"em",{},[73],{"type":53,"value":74},"for one particular weighting",{"type":53,"value":76},",\" but it hides the tradeoff the user actually needs to see.",{"type":47,"tag":56,"props":78,"children":79},{},[80,82,87],{"type":53,"value":81},"This skill turns a sequence of single-objective cuOpt solves into a ",{"type":47,"tag":62,"props":83,"children":84},{},[85],{"type":53,"value":86},"Pareto frontier",{"type":53,"value":88}," — 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 \u002F MILP \u002F QP solves already covered by the formulation and API skills.",{"type":47,"tag":90,"props":91,"children":93},"h2",{"id":92},"when-this-applies",[94],{"type":53,"value":95},"When this applies",{"type":47,"tag":56,"props":97,"children":98},{},[99,101,106],{"type":53,"value":100},"Reach for this workflow when the problem has ",{"type":47,"tag":62,"props":102,"children":103},{},[104],{"type":53,"value":105},"two or more objectives with no agreed-upon weighting",{"type":53,"value":107},", signalled by language like:",{"type":47,"tag":109,"props":110,"children":111},"ul",{},[112,125,137],{"type":47,"tag":113,"props":114,"children":115},"li",{},[116,118,123],{"type":53,"value":117},"\"balance X and Y\", \"trade off\", \"as cheap as possible ",{"type":47,"tag":70,"props":119,"children":120},{},[121],{"type":53,"value":122},"without",{"type":53,"value":124}," hurting service\"",{"type":47,"tag":113,"props":126,"children":127},{},[128,130,135],{"type":53,"value":129},"\"minimize cost ",{"type":47,"tag":70,"props":131,"children":132},{},[133],{"type":53,"value":134},"and",{"type":53,"value":136}," maximize coverage\", \"I want options, not one answer\"",{"type":47,"tag":113,"props":138,"children":139},{},[140],{"type":53,"value":141},"any objective the user is willing to relax in exchange for another",{"type":47,"tag":56,"props":143,"children":144},{},[145],{"type":53,"value":146},"If there is a single clear objective (everything else is a hard constraint), this skill does not apply — formulate and solve once.",{"type":47,"tag":90,"props":148,"children":150},{"id":149},"core-idea-one-solve-is-one-point-on-a-curve",[151],{"type":53,"value":152},"Core idea — one solve is one point on a curve",{"type":47,"tag":56,"props":154,"children":155},{},[156,158,163],{"type":53,"value":157},"A single optimum encodes ",{"type":47,"tag":62,"props":159,"children":160},{},[161],{"type":53,"value":162},"one implicit weighting",{"type":53,"value":164}," of the objectives. Change the weighting and the optimum moves. The frontier is the curve traced by all the non-dominated optima.",{"type":47,"tag":56,"props":166,"children":167},{},[168,170,175,177,181],{"type":53,"value":169},"A solution ",{"type":47,"tag":62,"props":171,"children":172},{},[173],{"type":53,"value":174},"A dominates",{"type":53,"value":176}," B when A is at least as good on every objective and strictly better on one. Dominated solutions are never worth choosing. The ",{"type":47,"tag":62,"props":178,"children":179},{},[180],{"type":53,"value":86},{"type":53,"value":182}," 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.",{"type":47,"tag":56,"props":184,"children":185},{},[186,188,193],{"type":53,"value":187},"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 ",{"type":47,"tag":70,"props":189,"children":190},{},[191],{"type":53,"value":192},"for",{"type":53,"value":194}," the user. Trace the frontier and let them choose.",{"type":47,"tag":56,"props":196,"children":197},{},[198,200,207],{"type":53,"value":199},"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 ",{"type":47,"tag":201,"props":202,"children":204},"code",{"className":203},[],[205],{"type":53,"value":206},"cuopt-numerical-optimization-formulation",{"type":53,"value":208},").",{"type":47,"tag":90,"props":210,"children":212},{"id":211},"step-1-define-the-objectives",[213],{"type":53,"value":214},"Step 1 — define the objectives",{"type":47,"tag":56,"props":216,"children":217},{},[218,220,225],{"type":53,"value":219},"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 ",{"type":47,"tag":201,"props":221,"children":223},{"className":222},[],[224],{"type":53,"value":206},{"type":53,"value":226}," before sweeping.",{"type":47,"tag":90,"props":228,"children":230},{"id":229},"step-2-build-a-payoff-table-anchor-each-objective",[231],{"type":53,"value":232},"Step 2 — build a payoff table (anchor each objective)",{"type":47,"tag":56,"props":234,"children":235},{},[236,238,243,245,250,252,256],{"type":53,"value":237},"Solve each objective ",{"type":47,"tag":62,"props":239,"children":240},{},[241],{"type":53,"value":242},"on its own",{"type":53,"value":244}," first. For ",{"type":47,"tag":70,"props":246,"children":247},{},[248],{"type":53,"value":249},"k",{"type":53,"value":251}," objectives this is ",{"type":47,"tag":70,"props":253,"children":254},{},[255],{"type":53,"value":249},{"type":53,"value":257}," solves. Record, for each, the value of every objective at that optimum:",{"type":47,"tag":259,"props":260,"children":265},"pre",{"className":261,"code":263,"language":53,"meta":264},[262],"language-text","              f1        f2        f3\nmin f1   →   f1*       f2(at f1*) f3(at f1*)\nmin f2   →   ...       f2*        ...\nmin f3   →   ...       ...        f3*\n","",[266],{"type":47,"tag":201,"props":267,"children":268},{"__ignoreMap":264},[269],{"type":53,"value":263},{"type":47,"tag":56,"props":271,"children":272},{},[273,275,281,283,289,291,296],{"type":53,"value":274},"The diagonal (",{"type":47,"tag":201,"props":276,"children":278},{"className":277},[],[279],{"type":53,"value":280},"f1*",{"type":53,"value":282},", ",{"type":47,"tag":201,"props":284,"children":286},{"className":285},[],[287],{"type":53,"value":288},"f2*",{"type":53,"value":290},", …) is each objective's best achievable value; the off-diagonals give the ",{"type":47,"tag":62,"props":292,"children":293},{},[294],{"type":53,"value":295},"range",{"type":53,"value":297}," each objective spans across the others' optima. This table does double duty:",{"type":47,"tag":109,"props":299,"children":300},{},[301,313],{"type":47,"tag":113,"props":302,"children":303},{},[304,306,311],{"type":53,"value":305},"It sets the ",{"type":47,"tag":62,"props":307,"children":308},{},[309],{"type":53,"value":310},"sweep bounds",{"type":53,"value":312}," for the ε-constraint method (the feasible range of each constrained objective).",{"type":47,"tag":113,"props":314,"children":315},{},[316,318,323],{"type":53,"value":317},"It supplies the ",{"type":47,"tag":62,"props":319,"children":320},{},[321],{"type":53,"value":322},"scales",{"type":53,"value":324}," for normalization — objectives in dollars, percent, and hours can't be weighted meaningfully until divided by their ranges.",{"type":47,"tag":56,"props":326,"children":327},{},[328],{"type":53,"value":329},"If any single-objective solve is already infeasible, stop and fix the model before sweeping — the frontier doesn't exist yet.",{"type":47,"tag":90,"props":331,"children":333},{"id":332},"step-3-choose-a-scalarization",[334],{"type":53,"value":335},"Step 3 — choose a scalarization",{"type":47,"tag":337,"props":338,"children":340},"h3",{"id":339},"weighted-sum",[341],{"type":53,"value":342},"Weighted sum",{"type":47,"tag":56,"props":344,"children":345},{},[346],{"type":53,"value":347},"Combine the objectives into one and sweep the weights:",{"type":47,"tag":259,"props":349,"children":352},{"className":350,"code":351,"language":53,"meta":264},[262],"minimize  w1·f1(x) + w2·f2(x) + ... ,   for a grid of weight vectors w\n",[353],{"type":47,"tag":201,"props":354,"children":355},{"__ignoreMap":264},[356],{"type":53,"value":351},{"type":47,"tag":56,"props":358,"children":359},{},[360],{"type":53,"value":361},"Cheap and trivial with any solver. Two limitations to respect:",{"type":47,"tag":109,"props":363,"children":364},{},[365,375],{"type":47,"tag":113,"props":366,"children":367},{},[368,373],{"type":47,"tag":62,"props":369,"children":370},{},[371],{"type":53,"value":372},"It only finds points on the convex hull of the frontier.",{"type":53,"value":374}," 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.",{"type":47,"tag":113,"props":376,"children":377},{},[378,383,385,391],{"type":47,"tag":62,"props":379,"children":380},{},[381],{"type":53,"value":382},"Weights are not priorities until the objectives are normalized.",{"type":53,"value":384}," Divide each ",{"type":47,"tag":201,"props":386,"children":388},{"className":387},[],[389],{"type":53,"value":390},"f_k",{"type":53,"value":392}," by its payoff-table range first; otherwise the largest-magnitude objective dominates regardless of intent.",{"type":47,"tag":337,"props":394,"children":396},{"id":395},"ε-constraint-preferred-for-a-complete-frontier",[397],{"type":53,"value":398},"ε-constraint (preferred for a complete frontier)",{"type":47,"tag":56,"props":400,"children":401},{},[402],{"type":53,"value":403},"Keep one objective; move the rest to constraints and sweep their right-hand sides:",{"type":47,"tag":259,"props":405,"children":408},{"className":406,"code":407,"language":53,"meta":264},[262],"minimize  f1(x)\nsubject to  f2(x) ≤ ε2\n            f3(x) ≤ ε3\n            (original constraints)\n",[409],{"type":47,"tag":201,"props":410,"children":411},{"__ignoreMap":264},[412],{"type":53,"value":407},{"type":47,"tag":56,"props":414,"children":415},{},[416,418,424,426,432,434,439],{"type":53,"value":417},"Sweep each ",{"type":47,"tag":201,"props":419,"children":421},{"className":420},[],[422],{"type":53,"value":423},"ε_k",{"type":53,"value":425}," across the range from the payoff table. Each ",{"type":47,"tag":201,"props":427,"children":429},{"className":428},[],[430],{"type":53,"value":431},"(ε2, ε3, …)",{"type":53,"value":433}," combination is a single standard cuOpt solve. This recovers the ",{"type":47,"tag":62,"props":435,"children":436},{},[437],{"type":53,"value":438},"full",{"type":53,"value":440}," 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.",{"type":47,"tag":56,"props":442,"children":443},{},[444,446,451,453,459,461,467,469,474,476,481,483,489],{"type":53,"value":445},"ε-constrain ",{"type":47,"tag":70,"props":447,"children":448},{},[449],{"type":53,"value":450},"linear",{"type":53,"value":452}," objectives directly. A quadratic objective (e.g. risk ",{"type":47,"tag":201,"props":454,"children":456},{"className":455},[],[457],{"type":53,"value":458},"xᵀΣx",{"type":53,"value":460},") is simplest kept as the objective ",{"type":47,"tag":201,"props":462,"children":464},{"className":463},[],[465],{"type":53,"value":466},"f1",{"type":53,"value":468}," while you ε-constrain the linear ones. A ",{"type":47,"tag":62,"props":470,"children":471},{},[472],{"type":53,"value":473},"convex",{"type":53,"value":475}," quadratic objective ",{"type":47,"tag":70,"props":477,"children":478},{},[479],{"type":53,"value":480},"can",{"type":53,"value":482}," instead be ε-constrained directly: add it as a quadratic constraint ",{"type":47,"tag":201,"props":484,"children":486},{"className":485},[],[487],{"type":53,"value":488},"xᵀQx ≤ ε",{"type":53,"value":490},", which cuOpt supports. Non-convex or equality quadratic constraints are unsupported, and the MILP path stays linear-constraint only.",{"type":47,"tag":56,"props":492,"children":493},{},[494],{"type":53,"value":495},"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\u002FQP only).",{"type":47,"tag":56,"props":497,"children":498},{},[499,504,506,511,513,518,520,524],{"type":47,"tag":62,"props":500,"children":501},{},[502],{"type":53,"value":503},"Read that dual as the local exchange rate.",{"type":53,"value":505}," Where the frontier is smooth, the dual on a swept ε-constraint is its slope — how much the kept objective ",{"type":47,"tag":201,"props":507,"children":509},{"className":508},[],[510],{"type":53,"value":466},{"type":53,"value":512}," 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 ",{"type":47,"tag":62,"props":514,"children":515},{},[516],{"type":53,"value":517},"zero",{"type":53,"value":519}," dual means the bound is slack: the sweep has run past the frontier's edge. This reading needs LP\u002FQP and a ",{"type":47,"tag":70,"props":521,"children":522},{},[523],{"type":53,"value":450},{"type":53,"value":525}," ε-constraint (MILP optima and problems with quadratic constraints return no duals) — where duals are unavailable, difference adjacent frontier points instead.",{"type":47,"tag":56,"props":527,"children":528},{},[529,534],{"type":47,"tag":62,"props":530,"children":531},{},[532],{"type":53,"value":533},"Picking a method:",{"type":53,"value":535}," weighted-sum for a quick convex sketch or when you know the frontier is convex (e.g. a pure-LP\u002FQP tradeoff); ε-constraint when the problem is MILP, when the frontier may be non-convex, or when the user needs a faithful and complete curve.",{"type":47,"tag":90,"props":537,"children":539},{"id":538},"step-4-sweep-collect-and-filter",[540],{"type":53,"value":541},"Step 4 — sweep, collect, and filter",{"type":47,"tag":259,"props":543,"children":546},{"className":544,"code":545,"language":53,"meta":264},[262],"frontier = []\nfor each weight vector (or ε vector) in the grid:\n    set the combined objective (or ε right-hand sides)\n    solve with cuOpt              # reuse the prior solution as a warm start\n    if status is Optimal\u002FFeasible:\n        record (objective values, solution)\ndiscard dominated and duplicate points\nsort the survivors to form the frontier\n",[547],{"type":47,"tag":201,"props":548,"children":549},{"__ignoreMap":264},[550],{"type":53,"value":545},{"type":47,"tag":56,"props":552,"children":553},{},[554],{"type":53,"value":555},"Practical notes:",{"type":47,"tag":109,"props":557,"children":558},{},[559,584,608,618,628,638],{"type":47,"tag":113,"props":560,"children":561},{},[562,567,569,574,576,582],{"type":47,"tag":62,"props":563,"children":564},{},[565],{"type":53,"value":566},"Warm-start LP sweeps.",{"type":53,"value":568}," For an LP frontier, carry the previous solve's PDLP warmstart data into the next to cut solve time. Per cuOpt this is ",{"type":47,"tag":62,"props":570,"children":571},{},[572],{"type":53,"value":573},"LP-only",{"type":53,"value":575},": a MILP solve doesn't take a PDLP warmstart (you can optionally seed a MIP start instead). See ",{"type":47,"tag":201,"props":577,"children":579},{"className":578},[],[580],{"type":53,"value":581},"cuopt-numerical-optimization-api",{"type":53,"value":583}," for the calls.",{"type":47,"tag":113,"props":585,"children":586},{},[587,592,594,599,601,606],{"type":47,"tag":62,"props":588,"children":589},{},[590],{"type":53,"value":591},"Cap each MILP solve.",{"type":53,"value":593}," Set a per-solve time limit on MILP sweeps (see ",{"type":47,"tag":201,"props":595,"children":597},{"className":596},[],[598],{"type":53,"value":581},{"type":53,"value":600},") — 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 ",{"type":47,"tag":70,"props":602,"children":603},{},[604],{"type":53,"value":605},"to the gap you set",{"type":53,"value":607},", not certified optimal.",{"type":47,"tag":113,"props":609,"children":610},{},[611,616],{"type":47,"tag":62,"props":612,"children":613},{},[614],{"type":53,"value":615},"Filter dominated points.",{"type":53,"value":617}," 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.",{"type":47,"tag":113,"props":619,"children":620},{},[621,626],{"type":47,"tag":62,"props":622,"children":623},{},[624],{"type":53,"value":625},"Resolution is a budget.",{"type":53,"value":627}," Curve fidelity trades against solve count. Start coarse to see the shape, then refine the grid only where the curve bends.",{"type":47,"tag":113,"props":629,"children":630},{},[631,636],{"type":47,"tag":62,"props":632,"children":633},{},[634],{"type":53,"value":635},"Spend the budget where the slope changes (LP\u002FQP).",{"type":53,"value":637}," 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.",{"type":47,"tag":113,"props":639,"children":640},{},[641,646,648,654],{"type":47,"tag":62,"props":642,"children":643},{},[644],{"type":53,"value":645},"Verify, don't assume.",{"type":53,"value":647}," 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-",{"type":47,"tag":201,"props":649,"children":651},{"className":650},[],[652],{"type":53,"value":653},"Optimal",{"type":53,"value":655}," so a non-certified point is never read as exact.",{"type":47,"tag":90,"props":657,"children":659},{"id":658},"step-5-interpret-the-frontier",[660],{"type":53,"value":661},"Step 5 — interpret the frontier",{"type":47,"tag":109,"props":663,"children":664},{},[665,675,685,695],{"type":47,"tag":113,"props":666,"children":667},{},[668,673],{"type":47,"tag":62,"props":669,"children":670},{},[671],{"type":53,"value":672},"Report tradeoffs, not single numbers.",{"type":53,"value":674}," 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\u002FQP 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.",{"type":47,"tag":113,"props":676,"children":677},{},[678,683],{"type":47,"tag":62,"props":679,"children":680},{},[681],{"type":53,"value":682},"Flag knee points; don't auto-pick them.",{"type":53,"value":684}," 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.",{"type":47,"tag":113,"props":686,"children":687},{},[688,693],{"type":47,"tag":62,"props":689,"children":690},{},[691],{"type":53,"value":692},"Treat dominated or gappy output as a diagnostic.",{"type":53,"value":694}," 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 (switch to ε-constraint) or a normalization mistake.",{"type":47,"tag":113,"props":696,"children":697},{},[698,703,705,710],{"type":47,"tag":62,"props":699,"children":700},{},[701],{"type":53,"value":702},"State the weighting\u002Fε you used.",{"type":53,"value":704}," Every reported point is conditional on its scalarization. Make that explicit so a single solve is never mistaken for \"the\" optimum. On LP\u002FQP, the ε-constraint duals are the ",{"type":47,"tag":70,"props":706,"children":707},{},[708],{"type":53,"value":709},"implicit weights",{"type":53,"value":711}," 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.",{"type":47,"tag":90,"props":713,"children":715},{"id":714},"interfaces",[716],{"type":53,"value":717},"Interfaces",{"type":47,"tag":56,"props":719,"children":720},{},[721],{"type":53,"value":722},"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:",{"type":47,"tag":109,"props":724,"children":725},{},[726,736],{"type":47,"tag":113,"props":727,"children":728},{},[729,734],{"type":47,"tag":201,"props":730,"children":732},{"className":731},[],[733],{"type":53,"value":581},{"type":53,"value":735}," — LP, MILP, QP solves (Python, C, CLI).",{"type":47,"tag":113,"props":737,"children":738},{},[739,745],{"type":47,"tag":201,"props":740,"children":742},{"className":741},[],[743],{"type":53,"value":744},"cuopt-routing-api-python",{"type":53,"value":746}," — the same frontier workflow applies to routing tradeoffs (distance vs. vehicles vs. time).",{"items":748,"total":852},[749,766,780,794,806,823,838],{"slug":750,"name":750,"fn":751,"description":752,"org":753,"tags":754,"stars":20,"repoUrl":21,"updatedAt":765},"accelerated-computing-cudf","accelerate data processing with cuDF","Official NVIDIA-authored guidance for NVIDIA cuDF GPU DataFrames, pandas acceleration, dask-cuDF, ETL, joins, groupby, CSV\u002FParquet I\u002FO, nullable semantics, and multi-GPU DataFrame workloads.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[755,758,761,762],{"name":756,"slug":757,"type":15},"Data Analysis","data-analysis",{"name":759,"slug":760,"type":15},"Data Engineering","data-engineering",{"name":9,"slug":8,"type":15},{"name":763,"slug":764,"type":15},"Performance","performance","2026-07-14T05:28:43.176466",{"slug":767,"name":767,"fn":768,"description":769,"org":770,"tags":771,"stars":20,"repoUrl":21,"updatedAt":779},"aiq-deploy","deploy and manage NVIDIA AI-Q infrastructure","Use when asked to install, deploy, run, validate, troubleshoot, or stop NVIDIA AI-Q Blueprint infrastructure.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[772,775,778],{"name":773,"slug":774,"type":15},"Deployment","deployment",{"name":776,"slug":777,"type":15},"Infrastructure","infrastructure",{"name":9,"slug":8,"type":15},"2026-07-14T05:29:06.667109",{"slug":781,"name":781,"fn":782,"description":783,"org":784,"tags":785,"stars":20,"repoUrl":21,"updatedAt":793},"aiq-research","conduct deep research with AI-Q","Use when asked to run deep research or AI-Q research through a reachable NVIDIA AI-Q Blueprint backend.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[786,789,790],{"name":787,"slug":788,"type":15},"Agents","agents",{"name":9,"slug":8,"type":15},{"name":791,"slug":792,"type":15},"Research","research","2026-07-14T05:28:06.816956",{"slug":795,"name":795,"fn":796,"description":797,"org":798,"tags":799,"stars":20,"repoUrl":21,"updatedAt":805},"amc-run-sample-calibration","run AMC sample dataset calibration","Run end-to-end calibration on the shipped sample dataset (sdg_08_2_sample_data_010926.zip) against a running AMC microservice. Use when user says 'test sample dataset', 'run sample calibration', 'verify AMC install', or 'launch and test'.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[800,801,802],{"name":756,"slug":757,"type":15},{"name":9,"slug":8,"type":15},{"name":803,"slug":804,"type":15},"Testing","testing","2026-07-17T05:29:03.913266",{"slug":807,"name":807,"fn":808,"description":809,"org":810,"tags":811,"stars":20,"repoUrl":21,"updatedAt":822},"amc-run-video-calibration","calibrate video datasets with AutoMagicCalib","Calibrate a new dataset from pre-recorded video files via the AutoMagicCalib REST API. Use when user has local MP4s and says 'calibrate my videos', 'run AMC on these videos', or similar. For RTSP\u002Flive streams, use amc-run-rtsp-calibration instead.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[812,815,818,819],{"name":813,"slug":814,"type":15},"Automation","automation",{"name":816,"slug":817,"type":15},"Imaging","imaging",{"name":9,"slug":8,"type":15},{"name":820,"slug":821,"type":15},"Video","video","2026-07-17T05:28:53.905004",{"slug":824,"name":824,"fn":825,"description":826,"org":827,"tags":828,"stars":20,"repoUrl":21,"updatedAt":837},"amc-setup-calibration-stack","deploy AutoMagicCalib microservice with Docker","Launch AutoMagicCalib microservice and web UI from NGC release images via Docker Compose. Use when user says 'deploy auto calibration', 'launch auto calibration', 'launch AMC', 'start MS+UI', or 'set up auto-magic-calib'. Requires NGC API key.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[829,830,833,834],{"name":773,"slug":774,"type":15},{"name":831,"slug":832,"type":15},"Docker","docker",{"name":9,"slug":8,"type":15},{"name":835,"slug":836,"type":15},"Operations","operations","2026-07-17T05:28:56.913999",{"slug":839,"name":839,"fn":840,"description":841,"org":842,"tags":843,"stars":20,"repoUrl":21,"updatedAt":851},"cudaq-guide","develop quantum applications with CUDA-Q","CUDA-Q onboarding guide for installation, test programs, GPU simulation, QPU hardware, and quantum applications.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[844,845,848],{"name":9,"slug":8,"type":15},{"name":846,"slug":847,"type":15},"Quantum Computing","quantum-computing",{"name":849,"slug":850,"type":15},"Simulation","simulation","2026-07-14T05:26:58.898253",305,{"items":854,"total":1005},[855,873,889,900,912,926,939,953,964,973,987,996],{"slug":856,"name":856,"fn":857,"description":858,"org":859,"tags":860,"stars":870,"repoUrl":871,"updatedAt":872},"nemoclaw-user-guide","retrieve NemoClaw documentation and configuration","Guides human users' AI agents to the NemoClaw docs MCP server and canonical Fern documentation in Markdown form. Use when users ask how to install, configure, operate, troubleshoot, secure, or learn NemoClaw with an AI coding assistant. Trigger keywords - nemoclaw docs, use nemoclaw with ai agent, nemoclaw mcp docs, nemoclaw install help, nemoclaw quickstart, nemoclaw markdown docs, llms.txt, agent skills.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[861,864,867],{"name":862,"slug":863,"type":15},"Documentation","documentation",{"name":865,"slug":866,"type":15},"MCP","mcp",{"name":868,"slug":869,"type":15},"Search","search",21777,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FNemoClaw","2026-07-20T06:00:01.461044",{"slug":874,"name":874,"fn":875,"description":876,"org":877,"tags":878,"stars":886,"repoUrl":887,"updatedAt":888},"mcore-build-and-dependency","manage Megatron-LM development environments","Container-based dev environment setup and dependency management for Megatron-LM. Covers acquiring and launching the CI container, uv package management, and updating uv.lock.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[879,882,883],{"name":880,"slug":881,"type":15},"Containers","containers",{"name":773,"slug":774,"type":15},{"name":884,"slug":885,"type":15},"Python","python",17049,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FMegatron-LM","2026-07-27T06:06:11.249662",{"slug":890,"name":890,"fn":891,"description":892,"org":893,"tags":894,"stars":886,"repoUrl":887,"updatedAt":899},"mcore-bump-base-image","update NVIDIA PyTorch base images","Bump the NVIDIA PyTorch base image (`nvcr.io\u002Fnvidia\u002Fpytorch:YY.MM-py3`) used by Megatron-LM CI. Covers the two pin sites (GitHub CI in `docker\u002F.ngc_version.dev` and GitLab CI in `.gitlab\u002Fstages\u002F01.build.yml`), the post-bump CI loop (re-run functional tests, refresh golden values, mark broken tests), and the gotchas that bit PRs",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[895,898],{"name":896,"slug":897,"type":15},"CI\u002FCD","ci-cd",{"name":773,"slug":774,"type":15},"2026-07-14T05:25:59.97109",{"slug":901,"name":901,"fn":902,"description":903,"org":904,"tags":905,"stars":886,"repoUrl":887,"updatedAt":911},"mcore-cicd","manage CI\u002FCD pipelines for Megatron-LM","CI\u002FCD reference for Megatron-LM. Covers CI pipeline structure, PR scope labels, triggering internal GitLab CI (which force-pushes the current branch to a pull-request\u002FBRANCH ref — always dry-run and verify the destination first; never run against shared or protected branches), and CI failure investigation.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[906,907,908],{"name":896,"slug":897,"type":15},{"name":773,"slug":774,"type":15},{"name":909,"slug":910,"type":15},"GitHub","github","2026-07-27T06:06:12.278222",{"slug":913,"name":913,"fn":914,"description":915,"org":916,"tags":917,"stars":886,"repoUrl":887,"updatedAt":925},"mcore-create-issue","investigate CI failures and create issues","Investigate a failing GitHub Actions run or job and create a GitHub issue for the failure.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[918,921,922],{"name":919,"slug":920,"type":15},"Debugging","debugging",{"name":909,"slug":910,"type":15},{"name":923,"slug":924,"type":15},"Triage","triage","2026-07-14T05:25:57.442089",{"slug":927,"name":927,"fn":928,"description":929,"org":930,"tags":931,"stars":886,"repoUrl":887,"updatedAt":938},"mcore-linting-and-formatting","lint and format Megatron-LM code","Linting and formatting for Megatron-LM. Covers running autoformat.sh, tools (ruff, black, isort, pylint, mypy), and code style rules.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[932,935],{"name":933,"slug":934,"type":15},"Best Practices","best-practices",{"name":936,"slug":937,"type":15},"Code Analysis","code-analysis","2026-07-14T05:25:56.18433",{"slug":940,"name":940,"fn":941,"description":942,"org":943,"tags":944,"stars":886,"repoUrl":887,"updatedAt":952},"mcore-migrate-gpt-to-hybrid","migrate Megatron-LM models to HybridModel","Migration guide for moving Megatron Core GPTModel checkpoints, model providers, training commands, and layer mappings to HybridModel.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[945,948,951],{"name":946,"slug":947,"type":15},"Machine Learning","machine-learning",{"name":949,"slug":950,"type":15},"Migration","migration",{"name":9,"slug":8,"type":15},"2026-07-17T06:07:11.777011",{"slug":954,"name":954,"fn":955,"description":956,"org":957,"tags":958,"stars":886,"repoUrl":887,"updatedAt":963},"mcore-onboard-gb200-1node-tests","onboard functional tests for GB200","Onboard 1-node GitHub MR functional tests for GB200 from existing mr-scoped 2-node tests.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[959,962],{"name":960,"slug":961,"type":15},"QA","qa",{"name":803,"slug":804,"type":15},"2026-07-14T05:25:53.673039",{"slug":965,"name":965,"fn":966,"description":967,"org":968,"tags":969,"stars":886,"repoUrl":887,"updatedAt":972},"mcore-run-on-slurm","launch distributed training jobs on SLURM","How to launch distributed Megatron-LM training jobs on a SLURM cluster. Covers a minimal sbatch skeleton, environment-variable setup for torch.distributed.run, CUDA_DEVICE_MAX_CONNECTIONS rules across hardware and parallelism modes, container conventions, monitoring, and per-rank failure diagnosis.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[970,971],{"name":773,"slug":774,"type":15},{"name":776,"slug":777,"type":15},"2026-07-14T05:25:49.362534",{"slug":974,"name":974,"fn":975,"description":976,"org":977,"tags":978,"stars":886,"repoUrl":887,"updatedAt":986},"mcore-split-pr","split pull requests to reduce review load","Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[979,982,983],{"name":980,"slug":981,"type":15},"Code Review","code-review",{"name":909,"slug":910,"type":15},{"name":984,"slug":985,"type":15},"Pull Requests","pull-requests","2026-07-14T05:26:01.226578",{"slug":988,"name":988,"fn":989,"description":990,"org":991,"tags":992,"stars":886,"repoUrl":887,"updatedAt":995},"mcore-testing","run and manage Megatron-LM tests","Test system for Megatron-LM. Covers test layout, recipe YAML structure, adding and running unit and functional tests, golden values, marker filters, and CI parity.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[993,994],{"name":960,"slug":961,"type":15},{"name":803,"slug":804,"type":15},"2026-07-14T05:25:54.928983",{"slug":997,"name":997,"fn":998,"description":999,"org":1000,"tags":1001,"stars":886,"repoUrl":887,"updatedAt":1004},"nightly-sync","manage nightly main-to-dev sync workflows","Domain knowledge for the nightly main-to-dev sync workflow. Covers merge strategy, CI architecture, failure investigation, and known issues.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1002,1003],{"name":813,"slug":814,"type":15},{"name":896,"slug":897,"type":15},"2026-07-30T05:29:03.275638",496]