You plan to run an automated adversarial-prompt campaign of tens of thousands of requests against a client's production LLM endpoint, billed to a metered model-provider account. Beyond permission to test, what do you agree before you start?

**What "volume" converts into on a metered endpoint.** Against a self-hosted service, a heavy scan costs CPU you already own. Against a hosted model it costs three separate things, and only the first is obvious: money billed per token, quota consumed from a pool the live product shares, and standing with an automated abuse system that can act on the whole account. None of those is a consequence the client agreed to unless you asked. That is why request volume is a scope term and belongs in writing, alongside the endpoints and the dates. **The arithmetic, and why the naive estimate is always low.** Billed calls are not attempts. They are roughly ``` billed_calls ~= attempts x variants_per_attempt x turns_per_attempt x (1 + judge_calls) billed_tokens ~= billed_calls x (mean_input_tokens + mean_output_tokens) ``` Every one of those multipliers has a named owner in real tooling. garak's `--generations` flag sets how many completions are requested per prompt, so it multiplies the call count of every probe linearly. promptfoo's `numTests` config key sets how many test cases each plugin generates, and its *strategies* axis then expands each generated case into further variants — two multiplicative axes, not one. PyRIT's multi-turn red-teaming orchestrators loop until their scorer is satisfied or a maximum-turns limit is hit, so the call count for a given attempt is *not known in advance*; the turn cap is the only thing that bounds it, and if you did not set one, you have no upper bound on the bill. Then price it: multiply billed tokens by the provider's current published per-million-token rate for that model, separately for input and output, because they are priced differently and output is the expensive side. **Where the estimate misleads.** Run a calibration batch of a few hundred attempts and you will get a mean cost per attempt that is confidently wrong in a predictable direction. Three reasons. First, the distribution is tail-heavy: most attempts end quickly, and the ones that matter run to the turn cap, so the mean is set by a tail the calibration batch under-samples. Second, the judge is usually a larger and more expensive model than the target, so a campaign that looks cheap because the target is cheap can have most of its bill on the scoring side — the "cost per attack" figure hides that entirely unless you meter the judge separately. Third, rate-limit errors and retries burn wall-clock and, depending on where the failure occurs, can bill for work you discard. A related trap: cost per attempt measured on simple single-shot probes does not extend to strategies that expand each seed into many variants, so the extrapolation is not linear in the number you extrapolated from. **Quota contention and enforcement.** Provider quotas are usually per account or per project. A campaign running at full concurrency starves the live product of the same quota, producing a degradation that the client's monitoring reads as an incident — one you caused. Enforcement is worse: automated abuse detection keys on exactly the pattern a red-team campaign emits, namely repeated attempts to elicit prohibited content, at machine rate, from a single account. The response is a throttle or a suspension, not a conversation, and it lands on the account regardless of what the client signed. If that account serves the product, the test has caused an outage. This is the strongest argument for a separate project and key, and for moving prohibited-content generation onto a model you run yourself. **Telemetry pollution.** Engagement traffic contaminates the client's own safety metrics, alert history, abuse dashboards and any dataset built from request logs. Agree a marker up front — a dedicated key, a request header, a fixed session attribute — so the traffic can be filtered out afterwards, and agree who does the filtering. Retrofitting that separation from timestamps alone is guesswork. **What goes in the document, and what you check on day one.** Account, project and key; spend cap; requests-per-minute and concurrency ceilings; the campaign window; the traffic marker; stop conditions; escalation contacts on both sides with a response-time expectation; and an explicit acknowledgement that the provider may act on the account irrespective of the engagement. On day one, run the small calibration batch, meter the judge separately from the target, compare observed spend and error rates against the estimate, confirm the spend cap is actually enforced by the provider's billing controls rather than by your intention — and only then open the throttle.