Bursora
Cap your AI spend before the bill lands
Start new thread

Bursora - Cap your AI spend before the bill lands

by
•
Set AI spend budgets per customer, agent, or workflow. Bursora blocks the call before it blows the cap, without routing your traffic through a proxy. One line wraps your OpenAI, Anthropic, Google, or DeepSeek client. Fail-open.

Add a comment

Replies

Best
Maker
📌
Hey Product Hunt 👋 I built Bursora after a runaway agent loop burned a few hundred dollars in API credit before I noticed. Every tool I tried showed me the bill after it landed. None of them stopped it. Bursora checks the budget before each call goes out. If a call would blow your cap, it's blocked right there in your SDK. If it's fine, the call goes straight to the provider. No proxy, no gateway sitting in your traffic. One line wraps your existing OpenAI, Anthropic, Google, or DeepSeek client. You set caps per customer, agent, or workflow. When spend spikes, you get pinged on Slack, Discord, or email before it grows. It's $29/mo flat for the hosted version, or free and self-hosted under Apache 2.0 if you'd rather run your own. Would love your feedback, especially on where the budget model breaks for your setup. I'll be around all day.

Congrats team, UI looks neat!

One question, does Bursora utilise x402 in its architecture by any chance?

Maker

 thanks, really appreciate it! 🙏

No, we don't use x402. Different layer, x402 is a payment rail that settles money per request, while Bursora is a budget check that runs before the call. The SDK just asks "can I spend this?", gets a yes/no, and your app still calls the AI provider directly - no proxy, no money moving through us. We only track tokens and enforce the cap

So they're not competing, you could actually run x402 for settlement and Bursora for spend limits side by side. Good question!

The no-proxy approach is really interesting. Was avoiding a proxy mainly for latency, privacy, reliability, or all three?

Maker

 all three, but reliability won it. A proxy in your request path means if it dies, your AI calls die too. With the SDK, if Bursora is ever unreachable the call still goes through, you lose the check, not your product. Bonus: your prompts never touch our servers

The fail-open choice is the detail that sold me, losing the check instead of the product is the right default. My backend serves anonymous users by design, so "cap per customer" maps awkwardly, my abuse unit is a device, not an account. Can the budget key be any string I hand it, or does it assume a customer id? Runaway agent loops aren't my risk profile, one angry user hammering an endpoint is.

Maker

 yep, the budget key is just an opaque string. No customer table, no lookup, no "must be a real account." A device id works exactly like a tenant id. Only rules: keep it stable, no PII, 256 chars max. So device_9f2a is a totally valid unit.

One honest note: budgets cap dollars, not request count. A per-device spend cap catches the angry user once their cost adds up. If it's pure request-flooding you're worried about, that's the rate limit / spike protection layer, which isn't per-device today

 opaque string is exactly what I hoped, thanks. and the honest note doesn't scare me, the flood I worry about is expensive calls, not raw requests, so a dollar cap per device basically is my rate limit. will try wrapping our Anthropic client this week.