Agent Expenditure
Spot wasted tokens when you dispatch multiple coding agents in parallel and need clear pass/fail criteria before scaling runs.
Overview
Agent expenditure is an agent skill most often used in Operate (also Build agent-tooling, Ship review) that defines detection criteria for five categories of token waste in parallel agent dispatch workflows.
Install
npx skills add https://github.com/athola/claude-night-market --skill agent-expenditureWhat is this skill?
- Defines five agent token waste categories with explicit detection rules (ghost agent, redundant reader, duplicate worker
- Ghost agent rule: >1.5× median tokens, <30% median findings, and weak evidence citations
- Redundant reader detection via cross-agent file access logs and overlapping scopes
- Duplicate worker when semantic finding overlap exceeds 50% across agents
- Mitigations: distinct file scopes and separated review dimensions before dispatch
- 5 categories of agent token waste defined with detection criteria
- Ghost agent threshold: >1.5× median tokens and <30% median findings count
- Duplicate worker when findings overlap >50% semantically across agents
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You run several agents at once and cannot tell which runs are expensive noise versus distinct, evidenced contributions.
Who is it for?
Solo builders batching parallel code review or exploration agents who want objective waste labels tied to tokens, findings count, and evidence quality.
Skip if: Single-agent chats with no parallel dispatch logs, or runs where you have not defined task-type medians and agent roles yet.
When should I use this skill?
Auditing parallel agent dispatches for token efficiency, overlapping scopes, or weakly evidenced outputs.
What do I get? / Deliverables
You label each run against concrete waste signals and adjust scopes and review dimensions before the next dispatch.
- Waste classification per agent run (ghost, redundant reader, duplicate worker, token hog, etc.)
- Scope and dimension adjustments for the next dispatch wave
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Operate because waste signals are meant to be read against live or recent dispatch telemetry (token spend vs output), not a one-off build task. Monitoring fits token budgets, median baselines, and overlap detection across agents—operational hygiene for agent fleets.
Where it fits
Draft a dispatch checklist that assigns security vs performance dimensions so duplicate-worker overlap stays under 50%.
After parallel PR reviews, classify a high-token run as a ghost agent when findings lack file paths and line citations.
Compare this week’s agent runs to medians by task type and flag token hogs before raising concurrency limits.
How it compares
Use as a rubric for dispatch hygiene, not as a substitute for pytest coverage or static security scanners.
Common Questions / FAQ
Who is agent-expenditure for?
Indie builders and small teams running multiple Claude, Cursor, or Codex agents in one session who need shared vocabulary for wasted spend.
When should I use agent-expenditure?
During Build when designing agent-tooling playbooks, during Ship when triaging overlapping review outputs, and during Operate when monitoring token budgets after parallel tasks.
Is agent-expenditure safe to install?
It is documentation-only criteria with no shell or network hooks; review the Security Audits panel on this Prism page before adding any repo skill to your agent.
SKILL.md
READMESKILL.md - Agent Expenditure
# Waste Signal Definitions ## 1. Ghost Agent An agent that consumes tokens without producing actionable output. **Detection criteria** (ALL must be true): - Token expenditure >1.5x median for task type - Findings count <30% of median for agent type - Findings lack evidence citations (no code refs, no line numbers, no file paths) **Exception**: Zero-finding results from low-risk scans (e.g., security audit of already-linted code) are valid, not waste. ## 2. Redundant Reader An agent that re-reads files already loaded by another agent in the same dispatch. **Detection**: Compare file access logs across agents. If agent B reads the same files as agent A and produces overlapping findings, agent B's reads were redundant. **Mitigation**: Assign distinct file scopes to each agent before dispatch. ## 3. Duplicate Worker An agent whose findings overlap >50% with another agent's output. **Detection**: Compare finding descriptions across agents. Semantic overlap (same issue described differently) counts as duplication. **Mitigation**: Assign distinct review dimensions (e.g., one agent reviews security, another reviews performance). ## 4. Token Hog An agent that exceeds 3x the median token count for its task type without proportional output. **Detection**: Compare agent token usage to historical median for the same task type. If output quality or quantity does not justify the excess, flag as waste. **Mitigation**: Set token budgets per agent. Use haiku for well-scoped tasks (see conjure cheapest-capable model selection). ## 5. Coordination Overhead When N > 5 agents and shared-file conflicts exceed 20% of total agent runtime. **Detection**: Count concurrent Read/Write operations on the same file by different agents, as percentage of total runtime. **Mitigation**: Reduce agent count, use git worktrees for isolation, or assign non-overlapping file scopes. --- name: agent-expenditure role: library description: Tracks per-agent token usage and flags waste in parallel dispatch. Use when evaluating parallel agent efficiency or after a multi-agent run. alwaysApply: false category: resource-optimization tags: - token-waste - agent-coordination - brooks-law - parallel-dispatch progressive_loading: true dependencies: hub: [] modules: - modules/waste-signals.md complexity: basic model_hint: fast estimated_tokens: 300 --- # Agent Token Waste Monitoring ## When To Use - After parallel agent dispatch completes - When evaluating whether to increase agent count - During retrospectives on agent-heavy workflows - When plan-before-large-dispatch rule triggers ## When NOT To Use - Single-agent workflows (no coordination overhead) - During active agent execution (post-hoc analysis) - For token budgeting (use token-conservation instead) ## Brooks's Law for Agents Dispatching more agents does not always help. Coordination overhead grows with agent count: | Agent Count | Expected Overhead | Guidance | |-------------|-------------------|----------| | 1-3 | Negligible | Dispatch freely | | 4-5 | 10-15% | Acceptable; plan first | | 6-8 | 20-30% | Monitor closely | | 9+ | 30%+ | Likely counterproductive | Coordination overhead is measured as shared-file conflicts: concurrent Read/Write operations on the same file by different agents, as a percentage of total agent runtime. ## Post-Dispatch Review Checklist After parallel agent runs, evaluate: 1. Did each agent produce unique findings? 2. Was total token expenditure proportional to value? 3. Did any agent duplicate another's work? 4. Would fewer agents have produced the same result? If 2+ questions answer no, reduce agent count in future dispatches of the same type. ## Waste Signals See `modules/waste-signals.md` for the 5 w