From a962fae3489fe6d682fd04e9d40342d02c56a2c2 Mon Sep 17 00:00:00 2001 From: damocles Date: Sat, 1 Aug 2026 01:57:32 +0200 Subject: [PATCH] claude-subagents skill: add concurrency guidance for container memory cap --- .../plugins/base/skills/claude-subagents/SKILL.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/claude-plugins/plugins/base/skills/claude-subagents/SKILL.md b/claude-plugins/plugins/base/skills/claude-subagents/SKILL.md index eb316a1b..e5f5e2a7 100644 --- a/claude-plugins/plugins/base/skills/claude-subagents/SKILL.md +++ b/claude-plugins/plugins/base/skills/claude-subagents/SKILL.md @@ -96,6 +96,17 @@ running at once instead of handing the whole thing to one. same as the one-subagent case, just N background bash tasks instead of one. Check on them as a batch, not by polling each individually in a loop. +- **Mind the container's memory cap before picking N.** Your whole + container shares one `MemoryMax` (a few GB by default) with every + subagent you spawn *and* your own process. A `claude` process plus its + MCP servers can hold several hundred MB to ~1GB depending on the task; + spawning a dozen at once on a small container doesn't just slow + things down, it can OOM the whole container — taking your own + in-flight turn down with it, not just the subagents. Rule of thumb: + **2-4 concurrent workers** on a default-sized container; check + `free -h` (or ask whoever owns the container's config for its + `MemoryMax`) before going higher, and chunk a bigger batch into + successive waves of that size rather than firing everything at once. - **You own the merge.** Once all N report done, review + verify each worker's slice (same "don't trust the self-report blind" rule as below), then combine — for a git-based split, that's you merging N