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 agentmods add skills/spacegrowth/claude-relay/spawnnpx skills add spacegrowth/claude-relay --skill spawngit clone --depth 1 https://github.com/spacegrowth/claude-relayWrote 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/spacegrowth/claude-relay/spawn)<a href="https://agentmods.dev/skills/spacegrowth/claude-relay/spawn"><img src="https://agentmods.dev/badge/skills/spacegrowth/claude-relay/spawn.svg" alt="Measured on agentmods" 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 | $0.00039 | $0.01398 |
| Opus 5 | $0.00019 | $0.00699 |
| Sonnet 5 | $0.00008 | $0.00280 |
| Haiku 4.5 | $0.00004 | $0.00140 |
Grade A, and why
spawn 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 3d 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 — 80 lines — stays where its author put it; the contents beside it link to each section on GitHub.
First run /relay:list — if a live idle session already owns this worktree/branch/topic,
use /relay:send on that session instead of spawning fresh (cheaper, keeps context). Only spawn
when nothing relevant is idle, the relevant session is dead/stalled, or you're upgrading to a
stronger model (a session's model is fixed at launch).
Choosing each executor's model — decide per packet, by judgment demanded and cost of a wrong-but- plausible result, never by file count:
- Haiku-class — mechanical, fully-specified, verifiable-by-command: rename sweeps, boilerplate tests from a shown template, config plumbing, doc formatting. The packet must be tight (exact files, exact acceptance commands). If the packet needs a "why" explained, it's not haiku work.
- Sonnet-class (the workhorse, default) — bounded features, bugfixes with a repro, test suites, refactors within one module. Most packets land here.
- Opus-class — unknown-root-cause debugging, cross-cutting changes, anything touching core logic/ledgers/parity tests, and any task where a wrong-but-plausible result would likely survive your review. Pay for judgment exactly where review can't catch its absence.
- Upgrade signals: two fix-list rounds haven't landed it (respawn stronger +
--supersede); ambiguity you can't spec away in the packet. Downgrade signal: your acceptance criteria could be checked by a script. - Effort rides the same judgment (packet
EFFORT:line or--effort): mechanical/ script-checkable →low/medium; leave unset for ordinary work;xhighfor unknown-root-cause or core-logic packets (maxwhen correctness beats cost). Fixed per process, like the model. - Version hygiene: pass the TIER alias (
haiku/sonnet/opus) and let relay resolve the concrete id through this machine's CLI — never type version ids (…-4-6) from memory; a stale id silently pins an old model.relay doctorshows what each alias resolves to here.
Write the task-specific packet content (ROLE / REQUIRED READING / WORK PACKET only — the standing
GATES and REPORT FORMAT are in the executor agent's system prompt, and relay appends the
per-packet report path / self-diff / closing line) to a file, then run:
${CLAUDE_PLUGIN_ROOT}/bin/relay spawn $worktree $topic $packet --model $model --lead "$CLAUDE_CODE_SESSION_ID"
$worktree is the ABSOLUTE path of the project directory the executor works in — the shared
project dir (e.g. /tmp/calc), NOT a per-task or per-module name. Parallel executors on the same
project all pass the same worktree; they just touch different files in it. (relay resolves it to
an absolute path and refuses to spawn if it isn't an existing directory.)
Pass --lead "$CLAUDE_CODE_SESSION_ID" (bash expands it to your own lead session id) so the
executor inherits your ownership — it's stamped with your lead id and project.
(Call relay via ${CLAUDE_PLUGIN_ROOT}/bin/relay — Claude Code substitutes the plugin's absolute
path — not bare relay, which often isn't on the Bash tool's non-interactive PATH.)
Relay lints every outgoing packet (advisory ⚠/ℹ lines at spawn and send — e.g. the text mentions
Linear but no MCP: line; big reading pinned to 200K; the packet tells the executor to commit or
to ask someone). Fix what it flags before the executor burns a turn on it; relay lint <packet> --worktree <dir> runs the same checks without sending.
Succeeding a retired session? Pass --seed <retired_session_id> (or a path to its
successor-seed.md) to inherit what that session did on this territory — its packet index and each
report's outcome/risk/UNVERIFIED lines get appended to this packet as context, ahead of the GATES.
See /relay:retire.
(--model optional — omit for the default. Add --keep if you already know a follow-up packet is
coming soon and don't want auto-close to park it in between (it can always be resumed; relay keep <sid> --off unpins). Add --name <label> for a custom session name, or
--scope <tag> for the short area tag shown in /relay:list. Add --pane to open this executor
as a split pane in your own window instead of a tab (--tab to force a tab), overriding the
executor_layout config default; iTerm only, falls back to a tab if your session can't be found.
Executors launch with NO MCP servers by default — saves tokens every turn and removes a
side-effect surface. If the packet genuinely needs one, declare it IN the packet with a line
MCP: linear (strict allowlist of servers configured in ~/.claude.json / the worktree's
.mcp.json; comma-separate several) or MCP: inherit (everything, incl. plugin/connector MCPs
like Chrome or Gmail). The packet is the source of truth — relay reads the line at spawn and, on a
later /relay:send, relaunches the executor's conversation with the wider set if it lacks what the
new packet declares. --mcp SPEC on the command line overrides the line. Decide per packet; don't
declare inherit by habit.
Context window: executors default to the 1M window (executor_default_context, shipped 1m —
the window is a ceiling, not consumption, so a bounded packet costs the same at either). To pin one
executor down, put CONTEXT: 200k in its packet; haiku always runs 200K. The window can't change
on resume — a heavy session is widened by /relay:retire + respawn.)
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.
- 3d ago First seen · 80 lines · 39 tokens per session scan A dec75393ecb6
spawn is a skill published in the GitHub repository spacegrowth/claude-relay (1 stars, last pushed 11d ago), licensed MIT. It adds 39 tokens to every session and 1,398 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-31.
Other skills, from other repositories
agent-orchestrator
Meta-skill que orquestra todos os agentes do ecossistema. Scan automatico de skills, match por capacidades, coordenacao de workflows multi-skill e registry management.
crewai-multi-agent
Multi-agent orchestration framework for autonomous AI collaboration. Use when building teams of specialized agents working together on complex tasks, when you need role-based agent collaboration with memory, or for production workflows requiring sequential/hierarchical execution. Built without LangChain dependencies…
foundry-hosted-agent-validation
Step-by-step process for validating a Python Foundry hosted agent sample (under python/samples/04-hosting/foundry-hosted-agents/) end to end — running it locally (native runtime and azd ai agent run) and after deploying it to an Azure AI Foundry project with azd. Use this when asked to validate a hosted agent sample.
python-feature-lifecycle
Guidance for package and feature lifecycle in the Agent Framework Python codebase, including stage meanings, feature-stage decorators, feature enums, and how to move APIs from one stage to the next.
build-and-test
How to build and test .NET projects in the Agent Framework repository. Use this when verifying or testing changes.
python-development
Coding standards, conventions, and patterns for developing Python code in the Agent Framework repository. Use this when writing or modifying Python source files in the python/ directory.