The SS + Pension Optimizer chooses your Social Security claiming age and your pension payout option together, because the two decisions interact. The standalone Social Security and Pension optimizers each hold the other lever fixed at your current plan, so neither sees the interaction; this one searches the combined grid and ranks the pairings.

Where it lives

A tab on the Optimizers page, shown only when your plan has both Social Security benefits entered and a pension source with two or more comparable payout options (for example Single Life vs Lump Sum, or the same option at different start ages). If either lever is missing, the tab doesn't appear - there's nothing joint to optimize, and the standalone tabs cover it.

Why optimize them together

The pension choice changes the best Social Security timing, and vice versa:

• A pension lump sum lands in your portfolio, which can fund the years before Social Security starts - making it cheaper to delay Social Security for a larger lifetime benefit.
• A monthly pension is a guaranteed income floor, which changes how much the portfolio has to carry and can shift the claiming answer the other way.
• Pension income and Social Security timing both move through the same tax, IRMAA, and Social-Security-taxability thresholds, so tuning them one at a time can miss an interaction that tuning them together catches.

Because of this, optimizing Social Security first and pension second (or the reverse) can land on a worse answer than searching the pairings jointly.

How it runs

For each pension option, the optimizer builds a plan variant and runs the full Social Security claiming grid against it through the Monte Carlo simulation - a two-pass search that screens every pairing at a lower iteration count, then re-runs the top candidates at full fidelity. Very large grids (many options on a couple plan) are refused rather than silently truncated; exclude some pension options on the Pensions page if you hit that.

Reading the results

• Pension Option - the payout choice for that row (e.g. "Single Life 65" or "Lump Sum 62"), with a one-line summary of the monthly and/or lump amounts.
• Primary / Spouse Claim Age - the Social Security claiming ages in that pairing.
• Success Rate - plan success rate, the primary sort key, with a delta vs your current plan on the top row.
• End Balance - median final portfolio balance.
• Lowest Balance - the low point of the portfolio's median path. An amber marker flags rows whose trough falls below 10% of your starting portfolio (see below).
• Apply - sets both the pension option and the Social Security claiming ages on your plan at once, then recalculates.

Why the Lowest Balance column matters

Success rate only asks whether the portfolio lasted, not how close it came to empty on the way. A plan that delays both the pension and Social Security and drains the portfolio to a thin buffer during the bridge years - then coasts on the guaranteed income - can post a high success rate while being fragile, with little cushion for a bad market or a surprise expense at the moment the portfolio is thinnest. The Lowest Balance column surfaces that trough so a high-success-but-nearly-depleted pairing is visible rather than hidden behind its headline number. It's information, not a veto: the ranking is still by success rate, but a low trough is a reason to prefer a slightly lower-success pairing that keeps a healthier buffer.

What it doesn't do

• One pension source at a time. If you have multiple pensions each with options, optimize them one source at a time.
• Doesn't change the ranking for the trough. A near-depletion pairing can still rank highly on success rate; the Lowest Balance flag is a caution, not a filter.
• Same modeling limits as the standalone optimizers - whole-year claiming ages, the configured COLA, and no Social-Security-policy stress test (use the What-If Explorer's SS cut for that).