Agentmetry
Free · Open source
SOC and DevSecOps teams
A single runaway agent on a Tuesday afternoon can burn through a month's API budget before you close your laptop — and most monitoring tools require you to ship your keys and traffic through their cloud to stop it. Burnban routes that enforcement decision through your own machine instead.
Burnban reads supported agent log files already sitting on disk, prices the recorded usage against public API list rates, and lets you set daily, weekly, monthly, or per-agent spend caps enforced in the request path — all from a local dashboard at localhost:4141. The ledger is SQLite on your machine. No keys leave to a Burnban server, no prompts hit a control plane, no account is required. The sharp edge is the word 'supported': log format and provider coverage are scoped, and anything outside that scope remains invisible to the meter. Teams tracking unsupported agents or providers find Burnban shows them a partial picture.
Bottom line: Pick this when you need an offline kill switch for personal or small-team API spend with zero cloud dependency — plan around it when your stack includes agents or providers outside the supported log formats, because those costs will run unmetered.
Find your fit
More options in LLM Observability. Compare pricing, platforms, and features side by side.
Free · Open source
SOC and DevSecOps teams
Freemium
Developers building GenAI apps and agents
API cost visibility usually means either reading provider dashboards after the damage is done or piping all traffic through a third-party cloud gateway you do not control. Burnban takes a different path: a single binary you install locally that reads supported agent log files in place, meters traffic routed through it to supported providers, and enforces spending caps before forwarding requests. The dashboard runs at localhost:4141, the ledger is local SQLite, and the allow-or-block decision executes on your machine — no Burnban account, no telemetry path, no hosted gateway in the request chain.
The standout feature is what the vendor calls the ‘subsidy’ command. Running `burnban subsidy –share` takes recorded local usage, reprices it against public API list rates for a chosen time window and model, and emits a clearly qualified cost estimate you can share with a team or manager — the window, rates, and plan multiplier travel with the output. The page documents one maintainer machine producing an equivalent figure of $4,173.49 over 30 days from local logs. That makes it a tool for surfacing hidden costs, not just capping future ones.
The architectural division Burnban draws between visibility and enforcement is the clearest signal of where it fits and where it does not. Log-based reading gives visibility; only traffic actively routed through the local meter can be blocked. Support for specific agent log formats and providers is scoped — the docs explicitly distinguish ‘supported’ agents and logs from the full universe of AI tooling. Teams running a homogeneous stack of supported agents get full metering and cap enforcement. Teams with mixed or unsupported agents get partial visibility at best and no enforcement for the uncovered traffic.
Burnban is MIT licensed, ships as a single binary for macOS, Linux, and Windows, and the installer verifies published checksums and ships with SBOMs. The vendor describes the complete local meter as $0 with no paid tier, no card, and no account. The source is publicly available and the page directs users to inspect every line before running the installer — an explicit acknowledgment that running a binary in the provider request path warrants scrutiny.
Sign in to rate this tool or suggest an edit.