Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add spacegrowth/claude-relay/plugin install 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/list)<a href="https://agentmods.dev/skills/spacegrowth/claude-relay/list"><img src="https://agentmods.dev/badge/skills/spacegrowth/claude-relay/list.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.1 | $0.00060 | $0.00656 |
| Opus 5 | $0.00030 | $0.00328 |
| Sonnet 5 | $0.00012 | $0.00131 |
| Haiku 4.5 | $0.00006 | $0.00066 |
Grade A, and why
list 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 6d 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.
What it actually says
Run: ${CLAUDE_PLUGIN_ROOT}/bin/relay list --lead "${CLAUDE_CODE_SESSION_ID}" (Claude Code
substitutes the plugin's absolute path and the current session id when this skill loads — call it
this way, not as bare relay, which often isn't on the Bash tool's non-interactive PATH).
The output has two sections: a LEADS block (every lead/project in flight, always shown in full,
with a relative LAST ACTIVE age so you can spot a probably-crashed lead) and an EXECUTORS
table (with a PROJECT column). Passing --lead "${CLAUDE_CODE_SESSION_ID}" scopes the executors
to this lead's project — its own executors plus any unowned ones — so a lead sees its own work by
default. If the calling session isn't a lead the scoping simply matches no owned executors (unowned
ones still show), which is harmless.
By default, closed/superseded/dead sessions are hidden — pass --closed to reveal them (capped at
15 most recent by update time); use relay prune --dry-run to see which ones are safe to delete.
Two columns worth reading: TOKENS is the executor's real spend so far (prompt/output tokens
summed from its transcript — use it to judge whether a territory deserves sonnet or haiku next
time), and LAUNCH is mcp/context/role (e.g. none/200k/A) — the first place to look when an
executor "doesn't have" a tool or compacts early.
Running list also auto-closes finished executors (reported, report already seen by you,
work landed in the worktree or idle past auto_close_idle_minutes) and prints a 🛏 line for each —
they show as closed (auto) under --closed, and /relay:send brings one back with full context.
A reported 📌 status is a pinned session (relay keep) that auto-close leaves alone.
Use ${CLAUDE_PLUGIN_ROOT}/bin/relay list --all for the global view — every executor across
every project, regardless of owner.
This is the decision-informing surface — always run it before spawning a new session, so you can
see whether a live idle session already owns the relevant worktree/branch/topic and should be
reused via /relay:send instead. It's also the crash-recovery surface: if you're a fresh lead
session picking this up cold, run this first to reconstruct what's already in flight before
asking anything.
Use ${CLAUDE_PLUGIN_ROOT}/bin/relay list --json instead if you need structured output to parse
programmatically.
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.
- 6d ago First seen · 44 lines · 60 tokens per session scan A 4d437bee3621
list is a skill published in the GitHub repository spacegrowth/claude-relay (1 stars, last pushed yesterday), licensed MIT. It adds 60 tokens to every session and 656 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
review-team
A multi-reviewer code review process that checks a change from several specialist viewpoints and combines the results into one report. It can cover bugs, security, tests, dependencies, frontend behavior, and continuous-integration workflows.
ultra
Fans the work out as a fleet of parallel Grok and Codex agents billed to their own subscriptions, then synthesizes one result. The peer engine equivalent of ultracode, adding intensity without spending Claude quota on the fleet. Use it for genuinely broad goals, not only explicit asks for intensity.
panel
Convenes a blind Codex and Grok panel on one neutral brief and adjudicates the verdicts.
grok-prompting
Brief writing guidance for composing self contained Grok briefs for coding, review, diagnosis, and second opinion tasks.
grok-result-handling
Internal guidance for presenting Grok companion output back to the user.
smoke
Runs a three probe live smoke wave after a plugin update and reports gate chain health before real work rides it.