Use capacity-cost-model

Build a capacity and cost model for a service or feature

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.

Reach for it 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.

Install it

npx skilldrop-cli install capacity-cost-model                 # Claude Code, your user folder
npx skilldrop-cli install capacity-cost-model --project       # Claude Code, this repo
npx skilldrop-cli install capacity-cost-model --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the SRE / on-call pack: --pack sre-oncall installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "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"

Requests like these belong to a different skill, so it shouldn't answer them:

• "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"

If another skill answers instead, ask for this one by name: "use capacity-cost-model".

Check what you get

A good result:

• 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.

Use something else when

• Deciding whether to build/buy/invest at all — that's business-case (this can feed its run-cost line)
• Setting the performance/availability targets — that's nfr-spec (this sizes to meet them)
• The migration/rollout sequence — that's migration-plan
• Finding waste in a bill you already pay — that's cloud-cost-review, which works from the cost export
• A fixed-price SaaS seat with no scaling math — just read the price sheet

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: business-case, cloud-cost-review, migration-plan, nfr-spec, success-metrics

Edit this page on GitHub · View source