DEV Community: Sifat Ahmed

You Don't Need a 12-Flag FFmpeg Script (or a Video API) to Generate Video From Code

Sifat Ahmed — Mon, 05 Oct 2026 13:36:21 +0000

If you've ever tried to generate video programmatically, you've probably ended up in one of two places.

Place one: FFmpeg scripting hell. You're hand-building a 12-flag command line, fighting codec mismatches, re-learning filter graph syntax every six months, and building your own queue/retry infrastructure around a binary that was never designed to be your rendering backend. It works, until it doesn't, and when it doesn't the error messages are unreadable.

Place two: a commercial video-generation API. Shotstack, FastPix, and similar services genuinely solve the rendering problem, but you pay for it in a different currency - usage-based pricing that scales with your output, and a template/API contract you don't control. Fine for some products, a real constraint for others.

There's a third option that's less talked about: treat the video as a normal webpage with a clock, and let a browser do the rendering.

That's the model behind HyperFrames, an open-source framework from HeyGen. A composition is HTML, CSS, and GSAP - a single paused timeline that gets seeked to exact timestamps instead of played in real time. A render pipeline (headless Chrome plus FFmpeg under the hood, but you never touch either directly) captures each timestamp as a frame and strings them into an MP4.

What that looks like in practice - no timeline editor, just markup:

<div class="clip" data-duration="2">
  <h1 class="title">Q3 Revenue Up 34%</h1>
</div>

The data-duration attribute is read by the render pipeline to know how long to hold each clip when seeking; GSAP animates whatever you want inside it, and because the timeline is paused and seeked rather than played, the render is deterministic - the same input always produces the same frames, no race conditions, no dropped frames from a slow machine.

This doesn't replace Remotion or Motion Canvas if you're already happy with React-based or TypeScript-based compositions - it's a different lane, closer to plain web dev than to a video framework. Where it fits is exactly the gap this post opened with: you want exportable video, you know HTML/CSS/JS, and you'd rather not learn FFmpeg's filter graph syntax or hand a vendor your rendering pipeline.

Disclosure: I wrote a short paid guide covering six full animation recipes built on HyperFrames (title cards, stat counters, crossfades, and so on) plus the "five pitfalls" that eat the most debugging time when you're starting out - Animate With Code. The framework itself is free and open-source either way.

How to Export a GSAP Animation to MP4 (No After Effects, No Screen Recording)

Sifat Ahmed — Wed, 23 Sep 2026 11:19:18 +0000

If you've searched "export gsap animation to mp4" or "gsap timeline to video," you've probably landed on a GSAP forum thread from years ago that never got a real answer. Here's the actual answer, with working code.

The short version: GSAP animates the DOM. A DOM doesn't export to video on its own - you need something to seek the animation to exact timestamps and screenshot each one. That's the whole trick. No After Effects, no screen recording, no proprietary timeline tool.

The core idea

Instead of playing your GSAP timeline in real time, you:

Build the timeline paused, not playing
Seek it to a specific time (e.g. tl.seek(1.2))
Screenshot the page at that exact moment
Repeat for every frame (e.g. 30 times per second)
Stitch the frames into an MP4 with ffmpeg

Because step 2 is deterministic - the same seek time always produces the same visual state - step 3 can happen in a headless browser, completely decoupled from real-time playback. That's what makes this exportable at all.

Working example: a counting stat animation

Here's a real, complete composition - a number counting up, the kind of stat card you see in product demos:

<!doctype html>
<html>
  <head>
    <script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script>    <style>
      body { margin: 0; background: #0b0f14; }
#root { width: 1920px; height: 1080px; display: flex; flex-direction: column; align-items: center; justify-content: center; font-family: sans-serif; }
#stat { font-size: 220px; font-weight: 800; color: #4fd1c5; }
#label { color: #8b98a9; font-size: 36px; text-transform: uppercase; }
</style>
  </head>
  <body>
    <div id="root">
      <div id="stat">0</div>
      <p id="label">Customers Served</p>
    </div>
    <script>
      const counter = { value: 0 };
      const statEl = document.getElementById("stat");

      const tl = gsap.timeline({ paused: true });
      tl.to(counter, {
        value: 12480,
        duration: 1.6,
        ease: "power1.inOut",
        onUpdate: () => {
          statEl.textContent = Math.round(counter.value).toLocaleString();
        }
      });

      // This is what makes it exportable: a paused, seekable timeline
      window.tl = tl;
    </script>
  </body>
</html>

Capturing the frames

Once you have a seekable timeline like window.tl above, exporting is mechanical: open the page in a headless browser (Puppeteer/Playwright both work), then for every frame number:

const fps = 30;
const duration = 3.6; // seconds
const totalFrames = Math.round(duration * fps);

for (let i = 0; i < totalFrames; i++) {
  const t = i / fps;
  await page.evaluate((time) => window.tl.seek(time), t);
  await page.screenshot({ path: `frame_${String(i).padStart(4, "0")}.png` });
}

Then stitch the PNG sequence into an MP4:

ffmpeg -framerate 30 -i frame_%04d.png -c:v libx264 -pix_fmt yuv420p out.mp4

That's the whole pipeline. The output is a real MP4, frame-accurate to the GSAP timeline, with zero screen-recording artifacts.

The five ways this silently breaks

None of these throw an error. You just get a blank render or a frozen frame and have to guess why, which is the actual reason this question keeps showing up unanswered in forums.

CSS transitions racing the seek. If a property is animated by a plain CSS transition instead of by GSAP, seeking the timeline doesn't touch it - it just keeps drifting toward its own target on its own schedule. The frame you capture can be mid-transition even though your timeline thinks it's settled. Fix: drive every timed property through GSAP, and set transition: none on anything time-driven.
Web fonts loading async. If a frame gets captured before a @font-face finishes loading, you get a silent fallback-font frame with no error thrown. Gate render start on document.fonts.ready.
Anything animating outside GSAP's ticker. Some third-party widgets run their own requestAnimationFrame loop internally. It won't respect your paused timeline's seek - it keeps advancing on its own and drifts out of sync with the frame you think you're capturing.
Non-deterministic loops. repeat: -1 never finishes, so a fixed-length export has no natural end. Compute a finite count instead: Math.max(0, Math.floor(duration / cycleDuration) - 1).
Non-deterministic ordering. Object.keys() or Map iteration order on data built at runtime, feeding into dynamically generated positions - fine on screen, but can render slightly differently frame to frame if anything touches randomness or unordered iteration. Fix everything at composition-author time, not render time.

Where this goes next

The seek-and-screenshot loop above is the whole mechanism, but hand-rolling it for anything more than a single stat card gets tedious fast: multiple timed elements, audio tracks, scene transitions, sub-compositions. HyperFrames (HeyGen's open-source framework, Apache-2.0) wraps exactly this pipeline into a CLI - npx hyperframes init, author the composition, npx hyperframes render.

If you want the mental model written out in more depth, plus five more working recipes (title cards, logo intros, scene crossfades, CTA morphs, Ken Burns drift) and the full pitfalls list, I wrote it up here: https://sidheart.gumroad.com/l/lyudd (pay what you want, starting at $1).

Happy to answer questions about the render pipeline or any of the pitfalls above in the comments.

Claude Desktop Won't Open on Windows? Here's the Real Cause (and the Fix That Actually Sticks)

Sifat Ahmed — Fri, 18 Sep 2026 06:37:34 +0000

If Claude Desktop on Windows just started throwing "This app can't open" out of nowhere, and reinstalling either doesn't fix it or fixes it for exactly one session before it breaks again - you're not imagining it, and it's not your machine. It's a real, documented Anthropic bug, and the standard "just reinstall" advice actively makes the underlying problem worse if you're using Claude Code, because it can silently destroy your session history in the process.

The actual root cause

Recent Claude Desktop builds on Windows ship as MSIX packages (Microsoft Store-style installers), and they bundle vk_swiftshader.dll. On any machine with Memory Integrity (HVCI) turned on - which is on by default on a lot of newer Windows installs - Windows Code Integrity blocks that DLL outright (you'll see event 3033 in the Event Viewer if you check). The GPU process crashes, and the whole MSIX package gets flagged Modified, NeedsRemediation by Windows' own package system. The next launch fails with "This app can't open."

Repairing or reinstalling only resets the clock - the same package self-corrupts again within a session, because the underlying trigger (HVCI blocking that DLL) is still there. It's been independently reproduced on NVIDIA, AMD, Intel-integrated, and Windows-on-ARM machines, and it's tracked in Anthropic's own bug tracker: anthropics/claude-code#88323.

Why "just reinstall" is actually risky if you use Claude Code

Reinstalling can silently destroy Claude Code's chat history while everything else (regular Chat, project files, memory) survives intact - a separate, confirmed bug: anthropics/claude-code#62997. Worse, the lost sessions are often unrecoverable from the UI even though the transcript files are still sitting on disk, so you frequently can't even tell what you lost without checking the filesystem directly: anthropics/claude-code#81907.

The fix that actually sticks

The permanent fix isn't repairing the MSIX build - it's switching to the older, non-MSIX Squirrel build, which has no package-integrity status for Code Integrity to flag in the first place. Short version:

Get the current version from https://downloads.claude.ai/releases/win32/x64/RELEASES, then build the download URL yourself (AnthropicClaude-<version>-full.nupkg) - the version number changes, so a hardcoded URL 404s.
.nupkg is a zip file wearing a different extension. Rename it to .zip and extract normally.
Copy everything inside lib\net45\ (not the folder itself) into %LOCALAPPDATA%\AnthropicClaude\app-<version>\.
Make a Desktop shortcut to claude.exe in that new folder.
Fully quit the old MSIX build first (tray icon → Quit, or Task Manager) - Electron's single-instance lock means a still-running old build silently hijacks the new one's launch.
Uninstall the old MSIX package for real once the new one's confirmed working, so Windows doesn't keep quietly auto-updating it back over your fix.

Full step-by-step with every gotcha I actually hit (nupkg extraction, the single-instance-lock trap, when it's safe to delete the download folder) is in the repo linked below.

Before you touch any of this, check if you're actually at risk

Not everyone on HVCI-enabled Windows is broken yet - some machines just haven't hit the trigger. I built a free, zero-setup diagnostic script called ClaudeGuard after this happened to me for real: it checks your package status, Code Integrity event log, and Memory Integrity state (read-only, changes nothing), and separately backs up your ~/.claude data with a manifest so if you do reinstall, you have a real answer to "did I lose anything" instead of guessing. Single PowerShell script, no dependencies, no account, no cost.

If you're already comfortable with git/bash/jq and want comprehensive cross-machine backup of Claude Code's entire data model, jtklinger/claude-code-backup-guide does that well and is actively maintained - ClaudeGuard is narrower on purpose, built specifically for the Windows MSIX corruption itself, not as a general backup workflow.

Why Is Your OpenAI API Bill So High? The Real Causes (and What Actually Stops It)

Sifat Ahmed — Fri, 18 Sep 2026 05:53:08 +0000

"Why is my OpenAI bill so high" is one of the most-searched questions about the API, and most answers stop at "use a cheaper model." That's true but incomplete. Here's the actual list of causes, roughly in order of how much money each one has cost real people, plus what genuinely stops each one (not just warns you about it).

1. Retry loops without backoff

The single most common cause. A request fails (rate limit, timeout, transient error), your code retries immediately, fails again, retries again - in a tight loop, that's hundreds of billed calls in minutes. Fix: exponential backoff with a hard retry ceiling (3-5 attempts, not infinite), and a circuit breaker that stops the whole loop after N consecutive failures rather than retrying forever.

2. A leaked or shared key

A key committed to a public repo, embedded in client-side code, or shared across a team with no per-key limit gets used by more than just you - sometimes within hours of being indexed by a scraper. Fix: never ship a key to the client, rotate immediately if a repo goes public with one in history, and if multiple people/services need access, give each its own key so a leak is isolated and traceable.

3. Defaulting to the expensive model for everything

Classification, extraction, routing, and simple formatting tasks almost never need the flagship model - a smaller/cheaper model handles them at a fraction of the cost with no meaningful quality loss. Fix: route by task complexity, not habit; reserve the expensive model for the calls that actually need its reasoning.

4. Resending the full conversation history every call

If your app passes the entire chat transcript as input on every turn, a 50-message conversation means message 50 pays for messages 1-49 all over again, every time. Fix: persist durable facts and pass a short summary plus relevant recent context instead of the whole history, and turn on prompt caching if your provider supports it - the repeated prefix (system prompt, tool definitions) drops to a fraction of normal input price.

5. Streaming and agent loops with no stop condition

An agentic loop that calls itself, evaluates, and calls again with no cap on iterations can burn through a budget in minutes if it gets stuck re-trying a task it can't complete. This is the fastest way to turn a $12 side project into a $300 bill overnight. Fix: hard iteration ceilings on any agent loop, and - this is the one most people skip - a check against actual spend so far, not just call count, since calls vary wildly in cost.

The setting that looks like a cap but isn't

OpenAI's dashboard "usage limit" is a notification threshold, not a hard stop. Cross it and you get an email; your requests keep going through. If you genuinely cannot afford to go past a number, that setting alone will not save you - you need something that actively checks spend before or during requests, not an email after the fact.

The real fix, for anyone building this themselves: don't do "read balance, compare, then decrement" as two separate steps - that has a race condition where two concurrent calls can both read "under budget" before either commits. Make the reservation itself atomic (a single compare-and-swap or a real ledger hold against one authoritative counter), so a second call's decrement simply fails once the first has already taken the balance below the threshold.

If you just want the email, not the engineering

Building the atomic-reservation version yourself is the right answer if you're already running agents in production at real volume. If you're a solo developer who just wants to know before a number gets crossed, that's a smaller problem, and it's the one I built Fusebox for: set a monthly ceiling, connect a read-only usage key (scoped so it can only ever see spend, never touch billing or make requests), get emailed at 50/80/100%. Free tier alerts once you've already crossed 100%; paid tier ($7/mo) adds the earlier 50/80% warnings that actually give you time to react before the bill is final. It's not a replacement for the atomic-reservation pattern above if you're at scale - it's the "email me" version for everyone else.

Either way, the actual lesson underneath all five causes above is the same one: OpenAI's per-token pricing means cost tracks behavior, not intent. Code that's correct can still be expensive if nothing is watching what it actually spends while it runs.

A counting-stat animation in HyperFrames, full working code (free recipe)

Sifat Ahmed — Sun, 06 Sep 2026 05:33:01 +0000

Following up on the guide I posted about a couple days ago (HyperFrames — renders video from plain HTML/CSS/GSAP instead of a timeline editor). Here's one full recipe from it, in full, free — no teaser cut-off.

The pattern

Turning a plain number into a small performance reads as far more "designed" than just displaying a static figure — genuinely effective for anything results/data-driven: a metric, a price, a countdown.

<section class="clip" data-start="0" data-duration="3" data-track-index="1">
  <div id="stat">0</div>
  <p>customers served</p>
</section>

const counter = { value: 0 };
tl.to(counter, {
  value: 12480,
  duration: 1.6,
  ease: "power1.inOut",
  onUpdate: () => {
    const el = document.getElementById("stat");
    el.textContent = Math.round(counter.value).toLocaleString();
  }
}, 0.2);

Why it's built this way

Tweening a plain JS object (not the DOM element itself) and writing the formatted number into the element on every tick is the reliable way to do this in a render pipeline that has to seek to arbitrary timestamps and always get the same pixels. It stays perfectly deterministic — the exact displayed number at any timestamp is a pure function of that timestamp — and it avoids animating a text property GSAP doesn't natively tween.

This is one of six recipes in the full guide (title reveal, logo intro, scene crossfade, CTA morph, Ken Burns background drift are the other five), plus a "five pitfalls" section on the mistakes that produce a blank render or frozen frame instead of a helpful error message. If the rest is useful: https://sidheart.gumroad.com/l/lyudd ($19).

Happy to answer questions about the pattern itself here for free either way.

Made a paid guide from an open-source Claude skill (without reselling it)

Sifat Ahmed — Sun, 06 Sep 2026 05:10:26 +0000

Quick build-in-public post, same vein as my earlier n8n automation service posts.

I wanted to package something adjacent to that work: a guide to HyperFrames, an open-source framework (from HeyGen) that renders video from plain HTML/CSS/GSAP instead of a timeline editor. There's a Claude Code skill that teaches an AI agent this framework - genuinely useful, but not something I built, so selling a copy of it would've been selling someone else's open-source work as my own.

What I did instead: wrote an original guide teaching the technique - the actual mental model (why the render has to be deterministic and seekable, and what that means for how you write animation code), plus six complete working recipes (title reveals, counting stats, crossfades, that kind of thing) with real code, checked against the framework's actual contract rather than simplified examples that fall apart the moment you try to render them for real. Same rule paid Docker/React courses run on: the tool itself is free, the technique you package around it is legitimately yours to sell.

$19 on Gumroad if it's useful to anyone building video-from-code pipelines: https://sidheart.gumroad.com/l/lyudd

Happy to answer anything about HyperFrames or the deterministic-rendering mental model if useful - not trying to oversell it, just sharing what I built.

OpenAI Shipped a Hard Spend Limit - Here's the Gap It Still Leaves Open

Sifat Ahmed — Fri, 04 Sep 2026 04:32:03 +0000

For most of 2026, this was true: OpenAI's budget field was alert-only. Cross your number, get an email, keep getting billed. That changed on July 23, when OpenAI rolled out real hard spend limits to every API account, free, no enterprise tier required. Set a cap at the org or project level, and once tracked spend reaches it, further requests fail with a 429 until the next billing cycle.

That's a genuine fix for the worst version of this problem - a leaked key or a runaway retry loop can no longer bill you into the ground forever. If you haven't turned it on, it's worth doing today: project settings, Limits, Edit spend limit, done in two minutes.

But a few weeks of watching this land tells me it doesn't close the gap most solo devs actually have. Two things stayed true even after the feature shipped.

It's a kill switch, not a warning

OpenAI's own guidance is to only use hard limits on dev/CI keys, not production - because the cutoff is account-wide and immediate. It doesn't stop the one customer or workflow that's spending; it stops everything behind that key. For a side project that's fine. For anything with real users hitting it, flipping that switch on means a runaway loop doesn't just cost you money anymore, it takes your app down completely, with no warning first.

So the same developers this feature was built for mostly end up leaving it off in production, for the same reason they left the old alert-only budget too high to matter: the downside of it firing is worse than the upside of it existing. That's not a flaw in OpenAI's implementation - a blunt, request-blocking cap has to work that way. It just means "OpenAI now has a hard limit" and "I can safely turn it on" are two different sentences.

A cap tells you after, not before

Even set up correctly, a hard limit is silent until it fires. You don't get a "hey, you're at 80%, might want to look" - you get a working app, then a 429. The dashboard shows you the number if you go check it, but nothing pushes a signal to you before the wall.

That's the part I built Fusebox around originally, and it's still true regardless of whether the hard limit exists: Fusebox watches your usage against a ceiling you set and emails you at 50%, 80%, and 100% of it, using a read-only Admin key scoped to api.usage.read - it can see your numbers, it can't spend or touch your account. Free tier emails you once you're over. Paid ($7/mo) adds the earlier warnings, which is the part that actually lets you catch a loop while it's still cheap to fix.

The honest way to put it: OpenAI's hard limit is the backstop you hope you never need. Fusebox is the thing that tells you early enough that you never do.

If you've turned on OpenAI's hard limit in production, I'd like to know - did you actually leave it on, or did the account-wide blast radius talk you out of it? That's the real open question this feature raised for me.

Bot protection and unsubscribe: the two features I built before Fusebox had a single user

Sifat Ahmed — Sat, 29 Aug 2026 16:02:07 +0000

Fusebox emails you before your OpenAI bill blows past a number you set. Before writing that pitch anywhere, I built two things nobody asks for in a demo: a bot check on signup, and a real unsubscribe link. Neither was optional, and neither was hard - but skipping them is exactly the kind of thing a solo project quietly does when there's no user yet to complain.

Why bot protection on day one

The signup form asks for an OpenAI Admin key. That's the one part of Fusebox that can't be undone if it goes wrong - a scraped or brute-forced signup endpoint means someone else's key sitting encrypted in your database, or a flood of junk rows with no real owner. reCAPTCHA was the obvious default, but it ships a tracking script and a visible "I'm not a robot" checkbox that doesn't fit a tool whose whole pitch is "we ask for less than you'd expect." Cloudflare Turnstile does the same job - a managed challenge that mostly resolves invisibly - without the tracking baggage, and it's free.

The actual wiring is small: a widget on the client that calls back with a token once it resolves, a submit button that stays disabled until that token exists, and a server-side check against Cloudflare's own siteverify endpoint before the signup handler does anything else:

async function verifyTurnstile(token: string, secretKey: string): Promise<boolean> {
  if (!token) return false;
  const res = await fetch("https://challenges.cloudflare.com/turnstile/v0/siteverify", {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ secret: secretKey, response: token }),
  });
  const data: any = await res.json().catch(() => ({}));
  return data?.success === true;
}

If that check fails, the request never reaches the part that touches an API key or the database. One rule worth calling out: on any submit attempt - success or failure - the client resets the token and re-disables the button. A stale token from a previous attempt is exactly the kind of thing that gets missed until someone abuses it.

Why the unsubscribe link isn't a preference toggle

The simplest version of "let people leave" is a settings page with a checkbox. Fusebox doesn't have an account system at all - just an email, an encrypted key, and a ceiling - so there's no login to put a checkbox behind. The unsubscribe link that goes out with every threshold email carries a random token generated once at signup and stored next to that subscriber's row. Clicking it is a single GET that flips one column:

const result = await env.DB.prepare(
  `UPDATE subscribers SET active = 0 WHERE unsubscribe_token = ? AND active = 1`,
).bind(token).run();

The AND active = 1 matters more than it looks. Without it, a link that's clicked twice - or forwarded, or hit by an email client's link-prefetcher - just re-runs the same update harmlessly. With it, the second click tells the truth: "already used," not a fake success. Small difference, but it's the kind of thing that's invisible right up until someone checks it, and getting it wrong is exactly the kind of bug that erodes trust in a tool whose entire pitch is trustworthiness.

Why write this down

Neither of these features is interesting on its own, and neither shows up in a screenshot or a pitch. They're the parts of a "trust us with your API key" tool that only matter when something goes wrong - a bot, a forwarded email, a link clicked twice - and by then it's too late to have skipped them. Building them before the first real signup, instead of after the first incident, was the point.

Fusebox is free, early access, live now: https://fusebox.sifatsrk.workers.dev

If you've built something similar and handled either of these differently, I'd like to hear about it in the comments.

I'm running a done-for-you automation service on self-hosted n8n — looking for a first pilot client

Sifat Ahmed — Sun, 23 Aug 2026 11:08:03 +0000

Quick build-in-public post. I've been setting up a small service: I build and run n8n automations for people — the repetitive stuff that eats an hour a day (copying data between tools, replying to the same kind of message, chasing follow-ups) — self-hosted on my own infrastructure, so you never touch the software or pay for a seat. You just get the automation working.

Stack is self-hosted n8n + Postgres, monitored (I run my own uptime checks on it so I know before you do if something's down), fronted through Cloudflare. Zero infra cost on my end at this stage, so pricing stays honest rather than padded to cover a cloud bill.

I'm looking for a first real pilot — something small and concrete (a workflow you're doing by hand right now that shouldn't need to be). I'll build it free or heavily discounted in exchange for honest feedback and, if it goes well, a testimonial. Not trying to oversell this: it's early, I have zero client track record yet, and I'd rather say that upfront than pretend otherwise.

If you've got something repetitive eating your time, or you know someone who does, I'd genuinely like to hear about it — reply here or DM.

Why Fusebox doesn't support Claude yet

Sifat Ahmed — Sun, 23 Aug 2026 02:50:06 +0000

Fusebox emails you before your OpenAI bill blows past a number you set. Before writing any of that code, I spent an afternoon checking one thing: what kind of API key would I actually need to ask people for?

That question mattered more than it sounds like it should. A tool that reads your spend needs some credential from your account. The honest version of that credential can only read - it can't touch billing, can't create or revoke other keys, can't add or remove people from your org. The dishonest version asks for more than it needs and hopes you don't check.

OpenAI: genuinely scoped

OpenAI lets you create an Admin key and restrict it to specific permissions per resource - None, Read, or Write. For usage and cost data specifically, that's a scope called api.usage.read. Grant only that, and the key can pull your spend numbers and do nothing else. That's exactly the shape of trust a tool like this should ask for.

Anthropic: not yet, for individual accounts

I checked the same thing for Claude, expecting a similar scoped option. Anthropic's own docs say otherwise, for Claude Console (the product individual developers actually use):

"Claude Console keys do not have selectable scopes; every key carries full access to all endpoints that accept Admin API keys."

Scoped read-only keys do exist on Anthropic's side (read:spend_limits, read:analytics) but only for Claude Enterprise organizations, not individual Console accounts. For everyone else, the only key that can read usage data can also manage your organization's members and revoke other people's API keys.

Asking a solo developer to hand that over, in service of a feature as small as "email me at 80% of my budget," is a bad trade. So Fusebox doesn't do it yet. Claude support is built and waiting - it's a small amount of code - but it stays off until Anthropic ships the same kind of scoping for individual accounts that OpenAI already has.

Why this is worth writing down

Most tools that ask for API access don't explain what they're actually asking for, and most users don't check. I'd rather the constraint be visible than quietly worked around.

Fusebox is free, early access, OpenAI-only for now: https://fusebox.sifatsrk.workers.dev

If you've found a cleaner way to do the Claude side of this safely, I'd genuinely like to hear about it in the comments.