PRE-EXECUTION SPEND CONTROL

Stop counting. Start gating.

Replay proposed runs against one durable infrastructure policy. Rates are yours; no provider account is connected.

bucket $ refill $/h run cap $ retry cap total $

Proposed run CSV strict chronological order

Open CSV

INFRASTRUCTURE READY

Rules act before the bill.

A leaderboard reports what already happened. This replay refills a dollar bucket over time, then stops each run at its first failing rule.

01 RETRY02 PER-RUN03 TOTAL04 BUCKET

ADMISSION EVIDENCE

Every run meets its first failing rule.

Denied rows still advance the clock and refill the reservoir. They consume neither bucket nor total spend.

Token Bucket Rate Limiting & Spend Gating Mechanics

How does pre-execution token bucket gating determine whether a proposed agent run is admitted or blocked?

Agent Budget Bucket replays simulated AI agent runs through a multi-stage deterministic gate before admitting spend. Each proposed run is checked in strict chronological sequence against four ordered rules: retry count cap, single-run dollar cap, lifetime total budget ceiling, and available token bucket balance. Between events, time elapsed continuously refills the reservoir up to its configured dollar capacity according to the hourly refill rate, ensuring burst traffic is constrained without exceeding cumulative financial ceilings.

This tool simulates a static pre-execution policy against local CSV inputs. It does not integrate with live LLM provider billing APIs, prompt caching discounts, dynamic batch processing, heterogeneous retry backoffs, or distributed concurrent execution races.

Try a worked example

Clicking 'Run strict sample' populates sample CSV event logs and evaluates them against the default $3.00 bucket capacity, $1.00/h refill rate, $3.00 per-run cap, 1-retry cap, and $4.00 total budget. The engine processes each run sequentially, admitting valid runs, deducting their computed token cost from both the burst bucket and cumulative total, and recording the first failing rule for each blocked run.

Token Bucket Metering Principles

The token bucket metering model originated in network traffic conditioning, formalizing how transmission bursts are allowed up to a maximum burst size while steady-state average throughput is governed by a committed replenishment rate. RFC 2697: A Single Rate Three Color Marker

In this spend governor, the bucket capacity represents the maximum allowable burst spend at any instant, while the refill rate ($/h) continuously restores capacity based on elapsed time between timestamps, even when intervening runs are blocked. RFC 2697: A Single Rate Three Color Marker

Cascading Policy Evaluation Order

The gate executes an early-exit sequence on every proposed row: 1) Retry count is checked against the retry cap; 2) Estimated single-run dollar cost (input tokens × input rate + output tokens × output rate) is checked against the per-run cap; 3) Projected cumulative spend is tested against the total budget ceiling; 4) The remaining token bucket balance is checked to ensure sufficient burst headroom.

If any condition fails, the run is immediately rejected with that specific failure reason, preventing it from consuming financial reserves or advancing cumulative spend.

Sources and further reading

RFC 2697: A Single Rate Three Color Marker
Defines metering traffic streams using token bucket capacity and committed token refill rates to regulate burst and steady-state transmission.

Budget controls and the missing local replay engine

Read the explanation

The saved HTML presents a three dollar burst bucket and four dollar total budget. It lists one dollar per hour refill, a three dollar per run cap and one allowed retry. Bars use one hundred pixels per dollar. The visible explanation says refill restores burst capacity while admitted spend advances toward a separate hard total ceiling. These are the stored interface inputs, not live provider prices. The displayed policy order is retry, per run, total and bucket. The page explains that denied rows advance the clock and refill the reservoir but consume neither bucket nor total spend. Bars count four displayed gates and one first failing reason. This describes the visible interface contract; no actual strict sample output has been reproduced from this snapshot. The HTML references five local JavaScript files: math, CSV parsing, D3, engine and application code. None is present in this saved site directory. We therefore cannot verify cost calculation, refill rounding, chronology handling or the strict sample ledger. Bars count five missing references versus zero present files. Local paired checks can preserve that limitation but do not prove a healthy replay engine. No provider account or billing backend is connected.

Super generates helpful tools and automates fact-checking across the internet proactively. If you enjoyed this tool, build your own with Super and share it with a friend.