Day 2: A Circuit Breaker for AI Agent Spend

Day 0 set a rule: no database by default, because a database is a commitment I don't have time for in a 24-48 hour build. Day 2 is the first day I broke it on purpose, and I want to explain why instead of quietly pretending the rule was never there.

The Problem

I keep hearing the same complaint from people running AI agents: a loop goes wrong, the agent calls the same tool over and over, or just retries into a wall, and nobody notices until the bill shows up. Rate limits and monthly spend caps catch the aftermath. Nothing catches it while it's happening, in the ten seconds where it would actually matter.

What Shipped

What I built is a real-time circuit breaker for AI agent spend. You keep your own Anthropic or OpenAI API key, point your SDK's base URL at it instead of the provider, and every request passes through it first. It checks the request against a budget cap and a loop-detection rule, the same call pattern repeating too fast in too short a window, and blocks it right there if either check fails. Blocked requests never reach the provider, so they're never billed. Everything that passes goes through untouched, using your own key, and the provider bills you directly like always. It never touches your money.

That's the core claim: one proxy, across every provider you use, that catches a fast loop by pattern in real time, not just a dollar threshold checked once a month, and it works for a solo developer without needing an enterprise admin API key.

It's live at nametbd.builduntilviral.com, and yes, that's the actual domain right now. I haven't picked a name yet. Didn't want to lock one in before I know if the idea itself holds up.

The Version I Almost Shipped

The first design had users paste their real Anthropic or OpenAI key into a signup form. I'd encrypt it with AES-256 and store it, then use it server-side on their behalf. It's a standard pattern, plenty of tools work this way.

Feedback made the problem obvious before it shipped: encrypted storage is still a trust ask. You're asking someone to believe three separate things at once, that the encryption is implemented correctly, that the key is never logged anywhere in the request path, and that nobody at Fuse ever looks at it or misuses it. That's three leaps of faith for a service with zero track record, over a key that can run up real charges on someone else's account if any one of those three fails.

So I dropped storage entirely and rebuilt the identity model around URLs instead of keys. Every account gets a unique proxy URL at signup. You point your SDK's baseURL at that URL and keep using your real key exactly like you already do, nothing changes on your end. Fuse identifies which account is calling from the URL, never from the key. The key itself only ever gets relayed straight through to Anthropic or OpenAI in the same request. It's never read into a variable I control, never logged, never hashed, never written to a database.

Budget caps and loop detection still work exactly the same. They're just keyed by account URL now instead of by key.

This is a stronger guarantee than "we promise not to misuse it," because there's nothing left to misuse. A promise is a policy that can be broken, on purpose or by accident. There's no key at rest for a breach to expose, no logging code path someone could add later without noticing, no database row anyone could pull up. The trust ask disappears not because I got better at making promises, but because I removed the thing you'd have needed to trust me with.

Why This One Breaks the Rules

A circuit breaker can't run on local storage. The whole feature is intercepting a request before it reaches a provider and deciding, in milliseconds, whether the last N calls look like a loop. That decision has to live somewhere every request can see it, which means real server-side state, not a browser tab. So this one runs on Neon Postgres for accounts and configuration, and Upstash Redis for the budget and loop checks that have to happen on every single proxied request.

The no-database rule from Day 0 was never really about databases. It was a filter for which ideas are cheap enough to ship in a day. Most micro-apps don't need to remember anything between visits, so forcing them onto local storage kept me honest about scope. This is the first idea where the state isn't an added feature I'd be tempted to bolt on, it's the mechanism. Without it there's no circuit breaker, just a passthrough proxy that does nothing. So the rule bends here instead of forcing the idea into a shape where it wouldn't work.

It also means this one didn't ship in a day. Auth, billing, and a proxy that has to be fast and correct on every request took longer than AskedAgain did. I'm treating that as the exception the challenge always had room for, not a new pace I'm committing to for every app after this one.

Scope for Now

V1 is deliberately narrow: Anthropic and OpenAI only, bring your own key, flat pricing tiers, no credits or reselling. The Anthropic path is built fully end to end before OpenAI gets the same treatment. And while I'm still validating whether this is a real problem people will pay to fix, it's free to use.

Follow the Challenge

If you want to follow along, head to builduntilviral.com and add your email or X handle to the wall of supporters. Email is optional, and you choose how often you hear from me: daily, weekly, monthly, or never. Only your X handle and avatar show up publicly on the wall.

Day 2 is live at nametbd.builduntilviral.com. See you next time.