TL;DR: Recompute the break-even against uncovered usage only. Discounts do not stack in cloud billing - an hour of usage gets one discount, the best one - so applying a savings plan discount to hours an RI already covers invents savings the bill will never show. Fetch current RI and savings plan coverage first, subtract covered hours, then model the new commitment on the remainder.

```text
agent's break-even math double-counted the savings plan discount  -  it stacked it on top of an existing reserved instance
```

1. List current commitment coverage for the workload: active RIs and savings plans, what they cover, and when they expire. Expected: you see the existing RI covering part or all of the usage the agent modeled as on-demand.
2. Recompute the break-even against the uncovered baseline only. Subtract covered hours first, then apply the savings plan discount to the remainder. Expected: the corrected break-even is longer (or never), and the savings shrink to the real number.
3. Check whether the agent's recommendation still makes sense on the corrected math. Expected: a clear buy or do-not-buy call based on uncovered usage, not the inflated figure.
4. Add a coverage-first rule to the agent: before modeling any new commitment, it must fetch current RI and savings plan coverage and exclude covered usage from the baseline. Expected: future break-even calculations never stack discounts on already-discounted usage.

## Use this when
- Break-even or ROI math for a new commitment looks too good to be true
- The agent modeled savings against full on-demand rates while RIs are already active
- You need to validate a commitment recommendation before purchase

## Not for this skill when
- There is genuinely no existing coverage - then the on-demand baseline is correct
- The existing RIs expire before the new commitment starts - no overlap, no double count
- You are comparing two new commitments against each other - model both against the same clean baseline

## Variant phrasings
- savings plan roi double counted existing reserved instance
- break even math stacked discounts on already covered usage
- agent recommended savings plan on top of active ri
- how to check ri coverage before buying savings plan

## Why it happens
The agent pulls on-demand list prices and applies the savings plan discount to all of them, because that is the simple formula. Existing coverage is a separate API call (or three) that the agent's math step never made. Discounts do not stack in billing, so the model invents savings that will never appear on the invoice.

## Edge cases
- Partial coverage (an RI covering 60 percent of hours) still leaves 40 percent eligible. The fix is excluding covered hours, not rejecting the purchase outright.
- Coverage that expires mid-term changes the math over time. Model the baseline year by year if an RI lapses during the new commitment.
- Regional and family scoping can make nominal coverage not actually cover the modeled usage. Verify the scope matches, not just the totals.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bIwfel9Q0m1xKJoZBvOlaQ