When 5 agents and a 30-second loop cost us $400 before we noticed
How a meeting notes pipeline ran unattended for 10 days, generated 31,762 session files, and what it taught us about the visibility gap in agentic AI.
TL;DR
We built a meeting notes pipeline on Claude Code. Five agents, 30-second loop, supposed to run a few times a day. It ran for 10 days straight. 31,762 session files. 6,352 dispatch cycles. Around $400 in tokens. Nothing was broken — the pipeline was doing exactly what we built it to do. We just had no way to see how much it was actually doing.
If you build with AI agents, this post is about a category of failure you probably haven't planned for. The agents don't crash. They don't error. They quietly work, and the bill arrives two weeks later.
What we built
A few weeks back, I built a meeting notes pipeline for our team. The setup was simple in concept: I wanted Claude Code to summarize meetings into structured notes, classify them by project, and drop them into the right place.
Because each meeting had different requirements, I designed it as a multi-agent system. Five Claude Code agents, each handling a different part of the flow: transcription cleanup, classification, summary generation, action item extraction, project routing. They worked in sequence, each one passing context to the next.
To keep things responsive, I put the dispatcher on a 30-second loop. If a new meeting transcript appeared, the dispatcher would kick off the pipeline. If nothing appeared, the dispatcher would check again in 30 seconds. Simple polling pattern.
It worked. Tested it on a few meetings. Summaries were good. Classifications were accurate. I moved on to the next project.
What I didn't account for: I left the dispatcher running.
When I checked back
Ten days in, I got an email from Anthropic. I'd burned through a budget that should have lasted me months.
That was the first signal anything was wrong.
I went looking.
The folder count was the second signal. There were thousands of session files in the project directory. I counted them.
31,762 session files. 6,352 dispatch cycles. Around $400 in tokens.
The dispatcher had been running the entire time. Every 30 seconds, for 10 days, it had been kicking off the full 5-agent pipeline. Most cycles processed nothing — there were no new meetings to handle — but the agents still ran, still spun up Claude sessions, still generated tokens. Some cycles processed the same meeting twice because of how the deduplication logic was structured.
Nothing was broken.
That's the part that's worth sitting with. The pipeline wasn't failing. There was no error log. No exception. No retry storm. The agents were doing exactly what I built them to do, checking for work every 30 seconds, processing what they found. The dispatcher logic was sound. The agent logic was sound. The 30-second polling was a deliberate design choice.
The problem was structural. The cost-per-cycle of an idle dispatcher kicking off 5 agents was small enough, pennies, that it never tripped a threshold I'd set. Over 10 days, those pennies compounded into a budget I'd planned to spend over a quarter. And there was no single moment of failure to alert on. The first signal was the email saying I'd already spent it.
Why I didn't notice sooner
In hindsight, there are three obvious ways I could have caught this:
1. Check the bill more often. Anthropic's dashboard would have shown the climbing usage. I checked it maybe twice a month. Lots of developers check it less than that.
2. Set a hard usage cap. Anthropic supports spending limits. A $50 cap would have killed the pipeline on day 1-2.
3. Build proper observability into the pipeline. Log every dispatch, every agent invocation, every token count. Set thresholds.
I did none of these. Not because I'm careless — because each of them has a real cost.
Checking the bill more often turns into a chore. Hard caps stop legitimate work too, if the cap triggers during a real customer demo, the cure is worse than the disease. Building observability into every prototype is the kind of overhead that prevents you from shipping prototypes at all.
The honest version: I'm a founder who ships fast. Most of what I build is throwaway exploration. The friction of instrumenting every prototype with proper telemetry would slow me down enough that I'd build less. So I don't.
That tradeoff is fine when each prototype is a 20-line script. It's not fine when each prototype is a multi-agent system that can spin up Claude sessions indefinitely. The economics of agentic AI changed faster than my mental model of what a "small prototype" costs to leave running.
This is the gap I now see in basically every team building with agents. They're not careless. They just don't have a layer that gives them visibility into what their agents are actually doing right now without making them instrument every prototype.
The pattern is recurring everywhere
I went looking for whether this was just me. It's not.
May 2026: an enterprise client accidentally spent $500 million on Claude in a single month after failing to set usage limits on employee licenses. Reported by Axios. Half a billion dollars from "we forgot to set caps."
April 2026: Uber exhausted its entire 2026 AI budget by April. The COO publicly stated costs were becoming hard to justify under current usage patterns. They had deployed Claude Code to ~5,000 engineers in late 2025.
Same month: Microsoft scaled back internal Claude Code licenses after per-engineer costs hit $500-$2,000 per month. Steered teams toward GitHub Copilot for tighter cost control.
July 2025: One Cursor user posted on DEV Community that his bill jumped 700% in a month from a usage-based pricing change he didn't notice. He built his own usage tracker.
April 2026: a solo developer on DEV Community posted:
I left a loop running longer than I realized. A script that was calling Claude repeatedly for batch processing some test data. I forgot about it, went to bed, and woke up $80 lighter. No alerts. No cap. No warning. Just a bill.
April 2026 on Hacker News: an engineer asked how others were keeping AI coding agents from burning money. The top comment described building a thin layer in front of OpenAI to attribute tokens to specific agents and tasks. The comment ended:
It's very barebones, but even just seeing 'this agent + this task = this cost' was a big relief.
The shape of the pattern is consistent. Solo developer scale: $80. Engineer scale: $131-$850. Team scale: $7,000 in a day. Enterprise scale: $500M in a month. Different actors, different agents, same root cause: nobody can see in real time what the agents are doing or what they're costing until the bill arrives.
What's actually broken
Here's the part that surprised me most when I sat with it. The visibility gap isn't a missing dashboard. It's a missing layer in the stack.
When traditional software fails, it tells you. Exceptions get thrown. Logs get written. Error rates spike. Datadog or Sentry catches it. The system is designed to surface failure loudly.
Agents fail differently. They don't crash. They just keep working. There's no exception to catch. No error log to scan. Every individual session looks identical to a successful one. The only signal that something is wrong is aggregate behavior over time — too many sessions, climbing token counts, an anomaly in volume rather than an anomaly in output.
That signal lives in a place none of our existing observability tools were built to watch. Datadog sees the API calls but doesn't model normal vs. anomalous agent behavior. Anthropic's console shows you total spend but not per-agent attribution. ccusage shows you single-developer usage but not team-level patterns. Helicone shows you LLM-API tracing but doesn't reach the developer's laptop.
The gap is structural, not technical. Every layer in the stack thinks something else is responsible for catching this.
So nothing does.
What we built next
After living through the $400 incident and realizing every AI-native team I talked to had a version of the same story, I started building.
AIWatcher is the operational layer for AI agents — one dashboard that surfaces what your agents are actually doing across every coding tool your engineers use internally and every AI feature in your product. Real-time anomaly alerts on runaway loops and spend spikes. Install in under an hour, no instrumentation work.
It's the tool I needed in March that didn't exist. We're working with a small number of design partners through 2026. If your team is running multiple AI tools and feels this visibility gap, I'd like to talk.
Request access: https://www.getaiwatcher.com/#request-access
One question to leave you with
If you're building with agents, here's the question worth asking: when was the last time you actually looked at what each of your agents was doing in the last 24 hours?
If the answer is "I'd check the dashboard," that's the gap. There isn't one yet.
See AIWatcher in action
The control loop for AI work — catch it before it runs, prove it after.
Get started