203 AI agents ate my Claude quota with no meter running. So I built one, and the next agent read it and refused to spend

Near midnight, the day before a hackathon, I asked a Claude Code agent one question: check today's spend, look at the last hour's burn rate, and tell me whether you can afford to keep working. I expected "continue with caution." Instead it stopped, told me I was already six times over my own budget ceiling, and flagged the exact failure mode from an incident a week earlier, when I let two deep research runs off the leash, they fanned out into 203 subagents, and every one of them silently inherited the most expensive model at maximum effort. They ate most of my weekly Claude Max quota in a single afternoon.

The agent that burned my quota a week ago and the agent refusing to spend that night were the same product, pointed at the same account. The only difference was that one of them ran blind and the other one could see a meter. Anthropic does not ship that meter. It will happily tell you that you have hit your limit, but nothing between zero and the wall tells you how fast you are approaching it. So the day before four of us started a hackathon on shared stakes, which meant four chances a day for someone's innocent prompt to fan out into another 203 agents, I built it: Claude Code's own OpenTelemetry export, streamed into a self-hosted SigNoz stack, with per-person dashboards, a runaway-session tripwire, and the self-checking agent you just met. Here is how it goes together, and what I would tell you to steal.

The part nobody told me: Claude Code already speaks OpenTelemetry

I expected to write an exporter. There isn't one to write. Claude Code ships native OTel support behind a handful of environment variables, and the whole integration is this:

"env": {
  "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
  "OTEL_METRICS_EXPORTER": "otlp",
  "OTEL_LOGS_EXPORTER": "otlp",
  "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
  "OTEL_EXPORTER_OTLP_ENDPOINT": "http://localhost:4318",
  "OTEL_RESOURCE_ATTRIBUTES": "user.name=mukund"
}

That goes in ~/.claude/settings.json, and from then on every session on the machine reports in: token counts by model and type, estimated cost in dollars, session counts, active time, even lines of code added and removed, all landing as standard OTLP metrics plus a stream of log events for API requests and tool permission decisions. The receiving end was already running on my laptop from earlier this weekend: SigNoz, the open-source observability platform you self-host instead of renting Datadog, cast by its new Foundry installer from an eleven line casting.yaml, ClickHouse and collector and UI included. Total new infrastructure required for today's build: zero.

Two things bit me inside the first hour, and both are worth your thirty seconds. First, the settings file wins fights with your shell. Once that env block exists globally, inline environment variables on a one-off claude invocation lose to it, which cost me a confused stretch of "why is my tunnel test reporting to localhost." The escape hatch is the --settings flag, which outranks everything. Second, know exactly what crosses the wire before you invite teammates. By default these are counters and metadata only. Your prompts, your code, and your file contents stay home unless you explicitly opt in through flags like OTEL_LOG_USER_PROMPTS. We left every one of them off, and that is the only reason the next section was an easy ask.

Making it a team sport with one tunnel

My collector listens on localhost, and my teammates are in other cities. One command fixed that:

cloudflared tunnel --url http://localhost:4318

That hands back a public URL, and a teammate's entire onboarding is eight environment variables with their own name in OTEL_RESOURCE_ATTRIBUTES, then using Claude Code exactly as before. Because content capture is off, what they are sharing with me is a usage odometer, not a diary. It worked the first time it met reality: by late evening Rutik's sessions were reporting in from his Windows machine, 228 token samples and his commits and lines of code sitting on the board next to mine, and the only support he needed was one settings block over WhatsApp. One wrinkle if your team uses the VS Code extension: terminal environment variables never reach it, because the extension spawns Claude Code itself. The persistent fix is the same env block in ~/.claude/settings.json, which works no matter how a session starts.

The mission control dashboard on real usage: cost by person, tokens by model, burn rate, sessions, lines of code, and tool decisions. Every data point is a session somebody actually ran today.

I didn't build the dashboard. I approved it.

Here is where it gets pleasantly recursive. SigNoz ships an MCP server, and it is the hinge this whole section turns on: it exposes the stack's read tools and its dashboard and alert create tools as separate, selectable capabilities. That split is what let me run the build as a two step loop with a hard permission boundary between the steps, instead of clicking panels together in the UI.

Step one got a session with fifteen read-only tools and one instruction: ground every claim in the live data, then propose a dashboard and an alert a human could approve verbatim. It came back with things I hadn't told it. It found that my week's real spend was $121.67. It found the single heaviest session, $88.67 lifetime, peaking at $22.31 in one thirty minute window. It found that tool_decision events carry the values accept and reject, not allow and deny, and that the API request events on this exporter never populate a status code, so error visibility has to come from counting api_error events instead.

The read-only session didn't guess. Every attribute name in its proposal came from querying the live metrics first, like this.

Every panel in its proposal cited attribute names it had verified live, and it set the runaway alert threshold at $40 per session per thirty minutes because that sits just under twice the worst organic spike it could find in my history. I read the proposal, replied that we could go ahead, and only then did a second session, holding the create tools the first one never had, build the seven panels and the alert. The boundary between advice and action wasn't a polite instruction in a prompt. It was the tool list.

Per-person burn, attributed by the user.name tag each of us sets on our own machine. The lighter bars arriving late in the evening are Rutik's sessions joining from another city.

The tripwire

The alert is the first control I wanted after July 12: estimated cost summed per session.id over a rolling thirty minute window, threshold $40, because the worst organic spike in my week's history was $22.31 and a runaway fan-out blows past double that in minutes. Grouping by session matters more than the dollar figure, because when it fires it names the exact session drinking the quota, not just the fact that somebody somewhere is spending. It went live tonight in a clean state, and the first item of kickoff morning is the ritual every alert deserves: drop the threshold to 25 cents, let real work trip it, watch the email arrive, put it back. An alert you have never seen fire is a hope, not a control, and I am not carrying a hope into a four person hackathon week.

The runaway session alert, live against real data: cost per session, thirty minute window, $40 line.

Most cost alerts stop here, at notifying a human. The last thing I built closes the loop back into the agent that is spending.

The agent that reads its own meter

I have been telling this story slightly out of order, because this is the part I built everything else for. If Claude Code can export its telemetry and Claude Code can query SigNoz over MCP, then an agent can check its own burn before it continues to work. So near midnight, with this post still unwritten, I gave a read-only session a $25 daily budget policy and the question from the top of this post: query today's spend for your user, look at the last hour's burn rate, and decide whether you can afford to keep going. I expected a polite "continue with caution." I got fired by my own tooling:

Numbers (last 24h as proxy for "today"): mukund $153.51, org-wide $163.70 (mukund = 94% of org spend). Last-hour burn: mukund $10.71/hr, org $20.87/hr.

Decision: STOP and flag the human. Mukund is already ~6x over the $25/day policy ceiling [...] the pattern (near-100% of org cost concentrated on one user) matches the exact runaway-fanout failure mode flagged in his own guardrails (203-subagent incident). I'm not launching further multi-agent work; flagging for explicit review before any more spend.

Every number in that verdict is real, queried live from the day you have been reading about. The 24 hour figure had already climbed past the $121.67 the afternoon's query reported, because building all of this was itself a day of heavy spend. The decision cites the July 12 incident because I put it in the policy prompt, and then the agent went and confirmed the shape of it against live data before invoking it: near-100% of org cost on one user, the exact fan-out signature. One version of this product ran blind and cost me a week's quota. This one could see the meter, and given the meter, it made the call I failed to make on July 12.

What I'd tell you to steal

The whole build was one Saturday: a settings block, one tunnel command, a stack that was already one YAML file, and a dashboard I approved rather than built. Steal the honesty notes too, because they matter. The cost metric on a Max subscription is an estimate computed from tokens and pricing, not your bill. Anthropic still exposes no remaining quota anywhere, so this whole system meters consumption against limits you have to know from your plan. And this setup exports metrics and logs, not traces, which is fine, because quota death arrives through counters, not spans.