Agent abuse budgets and retry-amplification lab

What this experiment counts

A request is not a fixed amount of work. In this model, each incoming job launches a chosen number of child tasks, each child makes a chosen number of attempts, and each attempt costs 20 synthetic work units. Attempts include the first try, so a value of two means one initial attempt and one retry. Multiplying these values gives the planned cost of one job.

The bounded policy reserves the full planned cost before dispatch. It checks both the per-job allowance and the remaining tenant allowance. Request-only mode admits each job without accounting for child work. The displayed allowances are intentionally unenforced in that mode, making the difference visible.

Reproduce the baseline

The default has six jobs, three children per job, and two attempts per child. Each job costs 120 units. A 150-unit job allowance permits that plan, while a 500-unit tenant allowance admits four jobs for 480 units and rejects the remaining two. Switch to request-only mode: all six jobs run and consume 720 units, exceeding the displayed tenant allowance by 220.

Return to bounded mode and lower the job allowance to 100. Every 120-unit plan is rejected before dispatch. Alternatively reduce fan-out or attempts and observe how more jobs fit. This demonstrates that useful work can sometimes be preserved by narrowing the plan rather than simply increasing the budget.

Inspect admission decisions

Incoming jobs controls the number of proposed jobs. Child tasks and attempts determine amplification. Per-job allowance limits an individual plan, while tenant allowance bounds aggregate work in this run. Changing one control at a time makes the causal relationship easier to see. The inputs reject values outside their displayed ranges.

Start trace, Next step, Show all, and the step slider let you inspect each admission or denial. Metrics always describe the complete run, even when only part of the trace is visible. Reset restores the baseline. Export JSON saves the inputs and outcomes to your device; the experiment sends no jobs to an external service.

Limits and production accounting

This is a deterministic budget model, not a rate limiter or a queueing simulation. It has no wall-clock arrival process, token-bucket refill, stochastic completion time, or partial child execution. It assumes every admitted job consumes its full planned cost and that reservation is atomic. Real services may reserve estimates and settle actual usage, which requires additional accounting and crash recovery.

In production, bind all child work and retries to a server-assigned job identity. Use shared atomic accounting across replicas, define reservation expiry and reconciliation, and prevent a client retry from silently creating a fresh unlimited job. Keep per-user, tenant, and service limits where needed for fairness. Test cancellation and dependency outages so budget enforcement cannot be bypassed by an error path or turned into uncontrolled retry traffic.