Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add sethdford/claude-skills --skill capacity-planninggit clone --depth 1 https://github.com/sethdford/claude-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/sethdford/claude-skills/capacity-planning)<a href="https://agentmods.dev/skills/sethdford/claude-skills/capacity-planning"><img src="https://agentmods.dev/badge/skills/sethdford/claude-skills/capacity-planning/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/sethdford/claude-skills/capacity-planning"><img src="https://agentmods.dev/badge/skills/sethdford/claude-skills/capacity-planning.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00031 | $0.00654 |
| Opus 5 | $0.00015 | $0.00327 |
| Sonnet 5 | $0.00006 | $0.00131 |
| Haiku 4.5 | $0.00003 | $0.00065 |
Grade A, and why
capacity-planning scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 47 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Capacity Planning
Forecast resource needs and plan infrastructure to meet demand while optimizing costs.
Context
You are planning infrastructure capacity. Model growth, forecast peak load, size infrastructure for headroom. Read historical metrics, growth trends, and business projections.
Domain Context
Based on capacity planning and performance modeling:
- Utilization Target: 70-80% typical for servers (avoid 100% - no headroom). Database: 70-80%. Network: 60-70% to avoid congestion.
- Headroom: Plan for 2-3x growth before re-architecture. At 70% utilization with 10% monthly growth, capacity lasts ~6 months.
- Seasonality: Traffic varies by season (Black Friday 10x normal). Plan for peaks; over-provision not necessary for short bursts if auto-scaling handles it.
- Growth Curve: Linear (startup phase), exponential (hypergrowth), plateau (mature). Different forecasting strategies per phase.
Instructions
-
Establish Baseline: Measure current usage (CPU, memory, storage, network bandwidth). Peak vs average. Growth rate over past 6-12 months.
-
Project Growth: Based on growth rate and business projections. Linear extrapolation for stable growth. Exponential model for hypergrowth startups. Add margin for uncertainty.
-
Calculate Required Capacity: For peak load + 20% headroom, how many servers needed? At 70% CPU utilization per server, peak_load / 0.7 = servers needed.
-
Model Scenarios: Best case (fast growth, more servers). Worst case (slow growth, fewer servers). Plan investment for mid-case; be ready to scale up/down.
-
Plan Upgrades: When do you need additional capacity? In 6 months? Plan lead time for procurement, setup, migration. Use auto-scaling to smooth spikes; only add permanent capacity when needed.
Anti-Patterns
- Over-Provisioning: Buy capacity for 5 years of growth. Result: underutilized, wasted cost. Guard: Plan for 1-2 years; cloud enables rapid scaling.
- No Growth Plan: Assume current load is constant. Result: surprised by capacity limits. Guard: Monitor trends; forecast quarterly.
- Ignoring Auto-Scaling: Manual provisioning for every 10% traffic increase. Result: operational burden, missed peaks. Guard: Auto-scaling for predictable load variations; manual provisioning for structural growth.
- No Utilization Monitoring: Assume servers fully utilized. Result: under-utilization, wasted cost. Guard: Monitor and right-size; consolidate low-utilization servers.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 47 lines · 31 tokens per session scan A 8967c9860b17
capacity-planning is a skill published in the GitHub repository sethdford/claude-skills (40 stars, last pushed 6mo ago), licensed MIT. It adds 31 tokens to every session and 654 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
enterprise-agent-ops
Operate long-lived agent workloads with observability, security boundaries, and lifecycle management.
multi-tenant-architecture
Designs tenant isolation, hostname routing, custom-domain lifecycle, and plan limits on Cloudflare or Vercel. Use when asked to "isolate tenant data", "support custom domains", "build a white-label platform", or assess PSL registration. For general module structure use codebase-architecture; for SEO content use seo.
cloud-hosting-expert
Expert guide for deploying SaaS applications with multiple entry points on modern edge and serverless platforms like Vercel and Cloudflare / Panduan ahli untuk mendeploy aplikasi SaaS dengan multiple entry points di platform edge dan serverless modern seperti Vercel dan Cloudflare.
discovery-patterns
Configure ServiceNow Discovery — schedules, IP ranges, credential affinities, MID Server assignment, custom probes/sensors, identification rules, and run-status monitoring on discovery tables.
deno-deploy
Use when deploying Deno apps to production, asking about Deno Deploy, or working with deno deploy CLI commands. Covers deployment workflows, environment variables, KV database access, custom domains, the --tunnel flag for local development, and the deno deploy command reference.
aws-cdk
Create and review Java AWS CDK v2 infrastructure code organized with the BCE (Boundary-Control-Entity) pattern — scaffold the project, wire the app entry point, pin regions in a central Stacks interface, model business components named after AWS services, and keep stacks thin over reusable constructs. Use whenever…