2
8 Comments

Shipped a spend-alert tool for solo OpenAI users — here's the whole build, including the part I almost got wrong

Quick build-in-public post. The idea: solo devs using OpenAI's API get surprised by bills (retry loops, shared demo links) — team tools like Helicone/Vantage exist but are priced and built for a company, not a hobbyist.

Before writing any code I checked what kind of access key I'd actually need. OpenAI lets you scope an Admin key to exactly api.usage.read and nothing else — genuinely safe to ask a stranger for. Anthropic's equivalent (Claude Console admin keys) is currently all-or-nothing for individual accounts — full org-admin access, no scoped read-only option. That would've meant asking for way more trust than the product needed, so Claude support is on hold until that changes on their end. Small thing, but it's the kind of detail that either makes a tool trustworthy or makes it a "why does this need THAT much access" red flag.

Stack: Cloudflare Workers + D1 (free tier), Resend for email (free tier). Zero infra cost at this stage — earn before spend.

Live: https://fusebox.sifatsrk.workers.dev — genuinely want to know if this is a real problem or a problem I invented. Roast it.

posted toAvatar for product Fusebox
Fusebox
  1. 1

    The strongest part is the trust boundary. Scoping the API key to read-only usage data makes the product materially easier to trust than a tool asking for broad account access.

    1. 1

      Thanks, Aryan - that was genuinely the design constraint that shaped everything else. Once I decided "never ask for more than read-only usage data," a lot of other decisions fell out of it naturally: no need to store or touch model requests, no risk if the stored key ever leaked (worst case someone sees your usage numbers, not your account). Appreciate you noticing that's the actual point, not just a footnote.

      1. 1
        That makes sense. The read-only boundary is a strong trust signal, especially for something handling billing-related data.
        1. 1

          Exactly - and it cuts the other way too: if I ever mess something up, the blast radius is "someone can see your usage numbers," never "someone can spend your money or touch your account." That asymmetry is what let me feel okay shipping this solo without a security team behind me. Are you dealing with OpenAI API costs on something you're building, or just thinking about the pattern in general?

          1. 1
            More thinking about the pattern in general. The interesting part to me is how much trust you can create just by making the worst-case failure mode harmless. Have users actually mentioned the read-only boundary as a reason they felt comfortable connecting their key?
            1. 1

              Honestly? Not yet - zero real signups so far, so no user has told me that directly. What I do have is two people independently calling out the same boundary unprompted, right here in this thread, before ever using it. Curious whether that counts as a real signal in your research, or if it's too small a sample (and too self-selected, since you're both commenting on my own post) to mean anything yet.

              1. 1
                Ha, fair pushback on sample size! For what it's worth: sifatahmedsrk52@gmail.com - happy to keep this going by email if you want to dig into the research angle further.
              2. 1
                I’d treat it as an interesting directional signal, but far too early to call it validation. Happy to unpack how I’d separate the useful signal from the self-selection here privately — what’s the best email to reach you on?