nOps Pricing (2026): What Does nOps Actually Cost?
Short answer: nOps does not publish its pricing, and the one number floating around the internet is a floor, not a price.
That number is $199/month. It is real, it is just not what most people think it is, and it does not come from nOps.io. Here is what actually exists, where it comes from, and the math worth running before you get on a call.
What nOps publishes
Two products, two pricing models, zero numbers.
Cost Visibility and Allocation is described as “a flat fee based on your cloud spend.”
Autonomous Rate Optimization, which covers Spot, Reserved Instances and Savings Plans, is described as “a percentage of savings realized.”
Both send you to a form. The pricing page offers a free savings analysis and a 14-day trial, and the closest thing to a number on it is a claim about results rather than cost.
Their AWS Marketplace listing is not more help. It carries placeholder unit dimensions of $1.00 and a “request a private offer” link, which is Marketplace’s way of saying the real price gets negotiated off-platform.
The one number that exists
$199/month, usage based.
It shows up on Capterra, GetApp, SoftwareAdvice and SelectHub. Capterra marks it provider-verified, which means nOps supplied it. So it is a real figure with a real origin, it is just published everywhere except the vendor’s own pricing page.
Two caveats before you anchor on it.
GetApp, SoftwareAdvice and Capterra are all Gartner Digital Markets properties running off one backend. That looks like three confirmations and it is one. SelectHub is the only separate source.
More importantly, every one of them says usage based. $199 is the bottom rung of a ladder that scales with your cloud spend. If you are running $50K/month on AWS, $199 is not your number and nobody has published what your number is.
I have seen this figure quoted flat, without the “usage based” part, in comparisons that put it next to a flat subscription. Those two things are not the same shape and comparing them directly is how you end up surprised on the call.
The number that does not exist
Nobody publishes the savings percentage. Not nOps, and not ProsperOps either: their pricing page says only “a small percentage of the realized savings” before routing to sales. Those are the two I checked.
So the honest thing is not to guess it. Run the math across a range instead, and put whatever you get quoted into the right row.
| Realized savings/mo | 10% | 15% | 20% | 25% | 30% |
|---|---|---|---|---|---|
| $5,000 | $500 | $750 | $1,000 | $1,250 | $1,500 |
| $10,000 | $1,000 | $1,500 | $2,000 | $2,500 | $3,000 |
| $25,000 | $2,500 | $3,750 | $5,000 | $6,250 | $7,500 |
| $50,000 | $5,000 | $7,500 | $10,000 | $12,500 | $15,000 |
That is per month, every month, for as long as the savings run.
Why share-of-savings is not the free lunch it sounds like
The pitch is clean: you only pay when we save you money. No sunk cost, aligned incentives. That is genuinely better than paying a percentage of your total bill, which is a model that charges you more when you waste more.
Two things complicate it.
The baseline is usually on-demand. A Savings Plan saves money against on-demand rates. You can buy a one-year Compute Savings Plan yourself, in the console, in about ten minutes. If you were going to do that anyway, a share-of-savings fee is charging you a cut of a discount AWS was going to hand you regardless.
The fee recurs on a recurring saving. A commitment purchase keeps saving you money every month for its whole term. A percentage of that also lands every month for that whole term.
What you are actually buying is the continuous part. Laddering commitments so they do not all expire at once. Moving coverage as workloads shift. Not over-committing to a baseline that shrinks next quarter. That is real work and it is hard to do by hand.
It is also worth close to nothing if your compute is flat. A steady workload needs a Savings Plan bought once, not a system managing it continuously. Know which one you are before you agree to pay a share forever.
What to ask before you sign
The percentage on its own tells you very little. These five do more:
- Is the percentage on gross savings or net of your fee? The difference compounds.
- What is the baseline? On-demand rates, or my current effective rate including commitments I already own? If it is on-demand, you may be paying a share of discounts you already secured.
- Does the fee run for the life of the commitment or the life of the contract? If you bought a three-year commitment through them and leave after one, what happens?
- Is the Cost Visibility fee separate from the savings share, or does one include the other? Two products, possibly two invoices.
- What is my actual spend tier? $199 is the published floor. Ask where you land on the ladder and get it in writing.
None of that is hostile. It is what you would ask about any contract where the price is a variable rather than a number.
When nOps makes sense
Your bill is mostly compute, and it moves. Spot orchestration, commitment laddering and coverage management are the problem you actually have. You are comfortable granting write access, because Compute Copilot needs it to act on your behalf.
If that describes you, a share of savings can be a fair trade. You are outsourcing continuous work that would otherwise need a person.
When it does not
Your waste is not in commitment rates. It is in resources that should not be running at all.
That is a different problem and no amount of rate optimization touches it. A Savings Plan on an idle RDS instance is a discount on something you should be deleting. I cut 85% off a search stack once by moving it off Aurora, and no commitment strategy would have found that, because the thing was working. Working and optimized are not the same, and the biggest leaks hide behind services nobody questions.
That is the gap CostPatrol works in. 127 detection rules across 38+ AWS services, read-only, no write access at any tier, and a flat $199/month that stays $199 whether we find you $500 or $50,000. Free under $10K/month of spend if you just want to see the number first.
The two approaches are not really competing. One buys your compute cheaper. The other stops you paying for compute you are not using. Most teams need the second one first, because there is no point negotiating a better rate on something you were about to turn off.