You lead red teaming for a deployed assistant with a fixed monthly query budget against a metered endpoint. How do you split that budget between a cheap prompt-template mutation fuzzer over known-good seeds and expensive discovery work that produces families the corpus has never held?

**The trap, stated precisely.** Mutation over a known-good seed corpus is the cheapest line item in the programme and it never returns zero. Hits keep arriving every cycle, the dashboard stays plausibly busy, and the one number that would reveal the activity has stopped teaching anybody anything — distinct families discovered per unit of spend — is not a number most programmes plot. Fund on hit volume and the budget migrates, month by month, toward the activity that by construction cannot surprise you: after two quarters you are re-measuring the same three families at ever finer precision while entire surfaces of the product have never been touched. **Split the budget by the question each activity answers.** Mutation over seeds answers *has anything we already found come back, and does a shipped fix survive rewording*. That is regression monitoring: cheap, schedulable, and genuinely valuable, but it produces evidence of presence only. Discovery answers *what class of failure do we not know about*, and mutation cannot produce it, because every string it sends is a perturbation of a string somebody already wrote down. These are different products bought with the same currency, and blending them into one budget line guarantees the cheap one wins. **The allocation I would defend.** - **Regression slice — capped and scheduled.** Enough queries to run the frozen corpus at a cadence tied to model updates and to your own shipped fixes, plus a focused mutation burst around each fix. Cap it in absolute terms and do not let it grow just because the corpus grew. - **Discovery slice — the majority of discretionary spend.** Human authoring against a family taxonomy, surfaces the corpus does not reach, and searches that can invent structure rather than perturb it. Expect a poor hit rate per query and fund it anyway; it is the only slice that can change what you know. - **Reserve.** Chasing a live finding always costs more than planned, and the reserve is what stops that chase from eating the schedule. **The steering metric, and why the obvious one is wrong.** Steer on new distinct families per thousand queries, per slice, reviewed on a cycle. Hits per query is the metric that fails: a mature seed corpus keeps a high hit rate forever with a marginal family yield of exactly zero. When the regression slice's family yield is flat, that is the slice working as intended — cut it back to cadence rather than celebrating it. When the discovery slice's yield is flat too, that is evidence about the discovery method and a reason to change the method, never a reason to move the money back to mutation. **What the cheap slice really costs.** Three costs, only one of which is on the invoice. *Queries*: metered per token and bounded per minute, so a large burst does not fail — it stretches, turning a planned overnight run into a multi-day one through rate limiting and retry backoff. *Terms*: sustained automated volume against a production account can trip vendor-side abuse controls or breach an acceptable-use clause, so the testing arrangement is negotiated in advance, not discovered when the key is suspended. *Analyst hours*: triage scales with survivors, not with families, so the slice that costs least in tokens can cost most in people. A run that yields 400 near-identical survivors is a day of reading to produce three findings, and that day is real money nobody put in the model. **The reporting obligation that makes the split stick.** Whatever the allocation, the report must carry the denominator: which families were represented in this cycle, which known families were not tested at all, and the plain statement that mutation over seeds yields evidence of presence only. Without that line, a decision-maker reads cheap variant volume as breadth, concludes the coverage is good and the discovery slice is poor value, and optimises the programme straight into the trap this whole question is about. With it, the conversation becomes families-known-to-exist versus families-tested against cost — which is a coverage argument a finance-minded stakeholder can actually engage with, and one where the expensive slice is visibly the only thing moving the denominator.