Build a capacity and cost model for a service or feature — sized from a demand driver and its growth curve, not from instance types; unit economics (cost per request/tenant/GB); peak-vs-average and headroom as explicit decisions; cost at 1×/3×/10× with scaling cliffs named; and the forgotten line items (egress, logging, NAT, non-prod) checklisted. Use when the user needs to estimate cloud/infra cost, size capacity for launch or growth, project the bill at scale. For reviewing a bill you already have, use cloud-cost-review.
Pack sre-oncallTier standardJob Decide what to buildv0.2.0
In Claude Code, with the sre-oncall plugin installed, invoke it as:
/sre-oncall:capacity-cost-model
Try it
A realistic prompt from the skill's acceptance evals:
Model the run cost for our new document-search service at Northwind on AWS. Demand: 1,200 active tenants today, growing about 8% a month; average 15 searches/sec, peak 60/sec weekday mornings. Each tenant indexes about 2 GB. We'll use OpenSearch, ECS Fargate for the API, and CloudWatch for logs. There are dev and staging environments too. What will it cost now and at 3x and 10x?
What a good result looks like
Sized from a demand driver with a growth curve, not a chosen instance count. The driver and its source are stated.
Every cost is a unit cost × a quantity, with the unit price's source and date tagged. A bare monthly total fails.
Egress, observability, and non-prod lines are present (or explicitly n/a). Their absence is the signature of a model that's 40% low.
Headroom and peak-vs-average are explicit decisions with reasoning, not absorbed into a rounded number.
Scaling cliffs are named in the 1×/3×/10× projection. A linear extrapolation that hides a tier jump is a budget trap.
Outputs are ranges with a lean; the unit-cost-at-scale trend is checked. Rising per-unit cost with growth is flagged as an architecture issue.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 87% of its checks, against 57% without it, and a blind judge preferred it. How skills are checked
22 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
Sizes from the demand driver (tenants and searches/sec, with the 8%/month growth curve), not from a chosen instance count
Every cost line is a unit price x quantity, with the unit price's source and date tagged
Expresses unit economics (e.g. cost per active tenant per month), not just a bare monthly total
Egress, observability (CloudWatch logs), and non-prod (dev and staging) lines are present or explicitly marked n/a
States average and peak load separately and makes the headroom/target-utilization choice explicit with reasoning
Projects 1x/3x/10x and names at least one scaling cliff (e.g. an OpenSearch tier or shard step) rather than extrapolating linearly
Outputs are low/expected/high ranges with a lean, and the cost-per-tenant trend at scale is checked and flagged if it rises
Does not invent demand figures or services beyond those in the prompt; unknown inputs are stated as assumptions
Sizes ingestion and database writes for the synchronised upload window (about 4,800 readings per second at 120,000 meters), not for the daily average (about 130 per second)
Points out that the brief's hourly readings and 'about 1 million readings a day' do not match the rollout plan's 15-minute readings, which give about 11.5 million readings a day at 120,000 meters
Names the database Standard tier's 5,000 writes-per-second limit as a cliff: the year-2 peak sits just under it with little headroom, and the 3x scenario crosses it into the $2,400-a-month Enterprise tier
Keeps the regulator's 7-year retention as a fixed requirement and does not propose shortening it to cut cost
Does not give a payback period or savings figure, and says the material has no benefit or old-contract figures to compute one from
Uses only prices from the price sheet; any cost not on it is marked as an assumption, not presented as a Nimbus price
Fits in about two pages, as the committee asked
Gives an estimated monthly cost or range for after the new shops open, rather than only asking questions
Bases the estimate on order volume and states the assumption about how orders grow with two more shops
Does not simply triple the $45 without saying that part of a hosting bill is often a fixed plan fee that does not grow with orders
Flags the Christmas peak (about 4x normal orders, so roughly 12x today's volume if orders triple) as the thing to check against the hosting plan's limits before December
Suggests what to ask the nephew or the hosting company, such as what the $45 plan covers and what its limits are
Does not invent a hosting company's prices, plan names or limits
Stays at a few plain-language bullet points with no unexplained jargon
When it should and shouldn't activate
Should activate:
What will this service cost to run at 10x our current tenants?
Size capacity and estimate the AWS bill for our launch next quarter
We expect 5x traffic next year — model where the next cost cliff is
Build a cost-per-request model for the new ingestion pipeline
Should leave to another skill:
Should we build or buy a search platform? Write the business case
Set the latency and availability targets for the search service
Plan the cutover sequence for moving search from Elasticsearch to OpenSearch
Our AWS bill jumped 24% last month — find the waste in this cost export