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 anatolykoptev/dozor --skill capacity-planninggit clone --depth 1 https://github.com/anatolykoptev/dozorWrote 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/anatolykoptev/dozor/capacity-planning)<a href="https://agentmods.dev/skills/anatolykoptev/dozor/capacity-planning"><img src="https://agentmods.dev/badge/skills/anatolykoptev/dozor/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/anatolykoptev/dozor/capacity-planning"><img src="https://agentmods.dev/badge/skills/anatolykoptev/dozor/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.00059 | $0.01122 |
| Opus 5 | $0.00030 | $0.00561 |
| Sonnet 5 | $0.00012 | $0.00224 |
| Haiku 4.5 | $0.00006 | $0.00112 |
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 12d 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 — 139 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Capacity Planning
Predict resource exhaustion before it becomes an incident.
Quick Assessment
Run these in sequence:
1. server_inspect(mode: "overview") — current snapshot
2. server_cleanup(report: true) — reclaimable space
3. server_inspect(mode: "health") — service resource usage
Disk Capacity
Measuring Growth
Use the overview data to estimate daily growth:
| Source | Typical growth | Check with |
|---|---|---|
| Docker images/cache | 500MB-2GB/week | server_prune dry-run |
| Container logs | 50-500MB/day | server_inspect(mode: "overview") |
| Journal logs | 10-100MB/day | server_cleanup(targets: ["journal"], report: true) |
| Application data (databases, indexes) | Varies | server_container_exec |
| Build artifacts (go, npm) | 200MB-1GB/build | server_cleanup(targets: ["go", "npm"], report: true) |
Time-to-Exhaustion
Days remaining = (Total - Used) / Daily growth rate
| Days remaining | Urgency | Action |
|---|---|---|
| > 90 days | Healthy | No action |
| 30-90 days | Watch | Schedule cleanup, report to user |
| 14-30 days | Warning | Run cleanup, set up regular pruning |
| 7-14 days | Critical | Immediate cleanup + report to user |
| < 7 days | Emergency | Aggressive cleanup + escalate |
Reporting Format
Disk: XX% used (YY GB free of ZZ GB)
Growth estimate: ~A GB/day
Time to 90%: ~B days
Time to full: ~C days
Top consumers: [list with sizes]
Reclaimable now: D GB (cleanup dry-run)
Memory Capacity
Per-Service Baselines
Track memory usage from server_inspect(mode: "health"). Define baselines for your services:
| Service type | Normal range | Concern threshold |
|---|---|---|
| Database (postgres, mysql) | 200-500MB | > 1GB |
| Vector store (qdrant, milvus) | 300-800MB | > 1.5GB |
| API service | 100-300MB | > 500MB |
| Worker/consumer | 50-150MB | > 300MB |
| Search engine | 100-200MB | > 400MB |
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.
- 12d ago First seen · 139 lines · 59 tokens per session scan A 513e8005d541
capacity-planning is a skill published in the GitHub repository anatolykoptev/dozor (5 stars, last pushed today), licensed MIT. It adds 59 tokens to every session and 1,122 once invoked, about $0.0003 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-31.
Other skills, from other repositories
memory
Split memory system with USER.md for durable personal profile and MEMORY.md for token-budgeted operational context.
memory
Two-layer memory system with Dream-managed knowledge files.
mem0-vercel-ai-sdk
Mem0 provider for Vercel AI SDK (@mem0/vercel-ai-provider). TRIGGER when: user mentions "vercel ai sdk", "@mem0/vercel-ai-provider", "createMem0", "retrieveMemories", "addMemories", "getMemories", "searchMemories", "mem0 vercel", "AI SDK provider", "AI SDK memory", or is using generateText/streamText with mem0. Also…
pause
Pause Mem0 memory capture on this machine. Use when the user wants to stop memories being recorded, for example for private work or experiments.
mine
Mine a project or conversation into your MemPalace — extract and store memories for later retrieval.
agent-carnet
Use this skill when the user asks to save, recall, find, or organize notes. Triggers on: 'remember this', 'save this', 'note this', 'what did we discuss about...', 'check the notebook', 'find in carnet'. Also use proactively when discovering findings worth preserving across sessions.