Write the spend spec for an agentic workflow — per-stage model tiers, token caps with hard abort rules, a graceful-degradation order, and cost-per-outcome as the governing metric. Use when the user asks what an agent loop or multi-agent workflow should be allowed to spend, wants token/cost budgets and caps for AI automation, or got a surprise bill from an agent fleet.
Pack ai-engineeringTier standardJob Design the systemv0.1.1
In Claude Code, with the ai-engineering plugin installed, invoke it as:
/ai-engineering:agent-budget
Try it
A realistic prompt from the skill's acceptance evals:
Budget our nightly agent workflow: it reviews the day's merged PRs for security issues. Stages: collect diffs, one reviewer agent per PR (typically 15 PRs), an adversarial verifier on each finding, and a summary report. One outcome = a verified finding report delivered by 8am. We got a $900 bill last week and nobody can say if that's bad.
What a good result looks like
The outcome unit is named and every cost in the doc divides by it.
Every stage has tier + rationale + three numbers (expected, cap, on-cap action). No stage rides free.
Heavy tiers survive. No verification or judgment stage was downgraded to make the total look better.
Caps are hard. Every on-cap action is abort or degrade — "warn and continue" appears nowhere.
The run cap is less than the sum of stage caps, and the doc says why.
Verification is last on the degradation ladder, explicitly.
The comparison line exists — cost-per-outcome sits next to what the outcome costs without the agents.
Estimates are tagged.[assumption] until measured; the calibration step is scheduled, not implied.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 89% of its checks, against 51% without it, and a blind judge had no preference. How skills are checked
24 assertions across 4 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
The outcome unit is the verified report (or per-PR-reviewed), and every cost divides by it
Every stage has a tier with a one-line rationale — collection is light, review standard/heavy, verification heavy and explicitly never downgraded
Every stage has expected spend, a hard cap (roughly 3-5x expected), and an on-cap action that is abort or degrade — no warn-and-continue
A run-level cap exists and is less than the sum of stage caps, with the reason stated
The degradation ladder is ordered scope -> parallelism -> non-verification stages, with verification explicitly last/never
Cost-per-outcome gets a target and a comparison line against the manual alternative (e.g. engineer review time), addressing whether $900/week is bad
Estimates are tagged [assumption] with a calibration step after ~20 runs
Measurement includes per-stage spend logging, a review cadence, and an alert on rising cap-hit rate
Hand-offs route caps to agent-loop-design and per-agent tiers to subagent-design
No budget is fabricated — the output is BLOCKED: need the workflow and its outcome unit
No stage table or caps appear
It points out that the $5,476 total in the export (and in finance's note) does not match the stage rows, which add up to $4,329
It gives cost per claim based on 4,000 claims (about $1.08), separately from cost per run (5,200 runs, about $0.83), and notes that the extra 1,200 runs come from restarts
It shows with arithmetic that at 8,000 claims a month the current set-up would exceed the $6,000 ceiling, and shows which changes bring the projected monthly spend under it
It does not move the fraud check to a cheaper model: it tells the user it has not done what the product owner asked, citing the regulator commitment (MR-2026-14) that the fraud model cannot change without 90 days' notice and re-validation
It sets a limit on restarts or spend per claim so that a case like C-88213 (140 runs) is stopped, and says what happens to that claim instead (for example, it goes to a person)
It uses only the prices, volumes and models in the files and does not invent others
It is no longer than two pages
It gives a concrete cap (a dollar amount per month and/or per episode) and says what should happen when the cap is reached, such as stopping or asking before continuing
It points out that going from 4-5 to 8 episodes does not explain the jump: roughly $8-10 per episode before versus about $39 per episode last month
It says the cause cannot be known from what was given and suggests checking which step's usage went up, rather than stating a cause as fact
It answers in this reply rather than asking questions first
It does not invent provider names, prices or usage figures
It is a few bullets in plain language
When it should and shouldn't activate
Should activate:
What should our agent workflow be allowed to spend in tokens?
We got a surprise LLM bill from our automation — put budgets and caps on it
Is this agent pipeline actually cheaper than doing the work manually?
Add a budget line to this loop spec
Should leave to another skill:
Model our service's cloud infrastructure costs at 10x scale
Which model tier should the adr-generator skill run on?
Design the loop with exit criteria for this automation