Why I'm building BurnCap

There's a specific kind of message that shows up in every AI builder community now. Someone wakes up, checks their provider dashboard, and finds a number that doesn't make sense. A retry loop ran all night. An agent got stuck calling the same tool 14,000 times. A test script pointed at a paid model and nobody noticed for three days.

These aren't hypotheticals. A misconfigured retry loop burned $72,000 in OpenAI credits overnight — and the dashboard showed the damage hours later, when the money was already gone. A LangChain agent made 14,000 redundant tool calls before anyone caught it. At the extreme end, one company ran up a $1.3M OpenAI bill in a single month. The OpenAI developer forum literally has a thread titled "Has anyone actually solved runaway agent costs?" The honest conclusion in that thread: the tools we have log the burn. None of them stop it.

That gap is why I'm building BurnCap.

The actual problem

AI products are cheap to prototype and unpredictable in production. The cost controls the providers give you are all post-hoc — they notify you after you've spent the money, and none of them can tell you the one thing you actually need to know when the bill spikes: which feature, which customer, or which model caused it.

If you're a big company, you solve this with a FinOps team and a Datadog contract. But the people getting hit hardest aren't big companies. They're indie founders shipping an AI wrapper, agencies building AI features for clients, and small teams of one to ten people. They have a real budget problem and zero appetite for an enterprise cost-management suite.

So the question I kept coming back to was simple: what would it take to catch the spike before the invoice does — for a team too small to build FinOps?

What BurnCap actually does

BurnCap ingests your LLM usage out of band. You don't route your traffic through it. You import a CSV, paste a read-only Admin key from OpenAI or Anthropic, or drop in a small SDK call. From there it does four things:

1. 01Attributes cost to the dimension that matters — not just "you spent $4,000," but "the summarizer feature spent $4,000, mostly on one customer."
2. 02Forecasts where the month lands, so you find out on the 9th, not the 30th.
3. 03Alerts on spikes, runaway loops, expensive models, and dev/test spend.
4. 04Enforces budgets — but only through an endpoint your app calls, that fails open if BurnCap is ever unreachable.

Why I think it's worth building

There are good observability platforms out there. But most of them are built around traces — they're debugging tools, and they price like debugging tools (often per trace, which punishes exactly the chatty agents most likely to blow up your bill).

"Am I going to lose money this month?" isn't a debugging question. It's a finance question. I haven't found a tool that's budget-first for small teams, that attributes cost per customer, that can tell you "you charge this person $49 a month and they're costing you $63," and that does it without asking you to re-architect your traffic. That's the wedge.

The math is forgiving, too. At a price in the $19–39/month range, BurnCap only has to prevent one surprise bill or surface one unprofitable customer a quarter to have paid for itself. I don't need to be magic. I just need to be there before the invoice.

What the first version intentionally won't do

I want to be honest about the cuts, because the cuts are the strategy:

• No proxy. Ever. I'm not going to put myself on your hot path. Out-of-band only.
• No stored prompts. Ever. Token counts and IDs, nothing else.
• No guessing. Every number is labeled — estimated, provider-billed, or forecasted. If I don't have a price for a model, I say "unpriced." I'd rather be honestly incomplete than confidently wrong, because the whole product rests on trusting the numbers.
• Not every integration on day one. OpenAI and Anthropic imports, CSV, and an SDK ship first. Gemini, LiteLLM, and gateway importers come later.
• No AI feature for the sake of an AI feature. The "insights" — cheaper-model suggestions, cache efficiency — are computed deterministically. There's no LLM inside BurnCap making things up about your spend. (That one surprised me too — I'll write a whole post about it.)

What I want to learn

I've built the thing. What I don't know yet is the stuff you can only learn by shipping: do people actually tag their usage with feature and customer IDs, or is that friction too high? Is daily-granularity import enough to be useful, or does the value only show up with per-request SDK data? Is the unit-economics view — "is this customer profitable?" — the hook I think it is, or a nice-to-have? Those are real open questions, and I'd rather find the answers in public than pretend I already have them.

How I'm documenting this

I'm building BurnCap under Eastbase Studio, and I'm going to write the whole thing up — roughly fourteen posts covering the real decisions: the scope cuts, the stack, the database design, the "AI feature with no AI in it," rate limiting without Redis, the launch. Not a polished case study after the fact — the actual reasoning, including the parts I'm unsure about.

If you've ever opened a provider dashboard with a sinking feeling, this series is for you.

Next up: who BurnCap is actually for — and who it isn't.