So verhindern Sie, dass ein einzelner Kunde Ihre OpenAI-Rechnung sprengt

Posted on Oct 13 • Originally published at llmbrake.com

If you run a SaaS on top of an LLM API, your provider bill is one number. OpenAI and Anthropic let you set limits per organization or project. Those limits protect your account, not your margins: they can't tell you which customer drove the spend, and they can't stop one customer without stopping everyone.

Here's a pattern that fixes both, and the edge cases to watch for.

Every chat completion returns token usage. Convert it to dollars immediately, because token counts aren't comparable across models:

cost = ( uncachedInput * inputPrice + cachedInput * cachedInputPrice + output * outputPrice ) / 1 _000_000 Enter fullscreen mode Exit fullscreen mode Cached input tokens: OpenAI reports them in usage.prompt_tokens_details.cached_tokens, and they're billed at a lower rate. Ignore them and you'll over-count. Dated snapshots: model names like gpt-5.4-mini-2026-03-17 should resolve to the base model's price.

Price table: keep it in one place, with a source link and the date you read it. Prices change. When I checked OpenAI's pricing page on 2026-10-09, it listed gpt-5.5 at $5 input / $30 output per 1M tokens and gpt-5.4-mini at $0.75 / $4.50.

Verify before you rely on that. 2. Check before the call, record after it before call: spent = store.get(customer, month) if spent >= budget → block if spent >= 0.8 * budget → swap to a cheaper model call provider after call: store.add(customer, month, cost) Enter fullscreen mode Exit fullscreen mode The check has to sit in the request path, before the call.

A nightly job that emails you the damage is forensics, not protection.

With stream: true, OpenAI only reports usage if you set stream_options: { include_usage: true }, and it arrives in the final chunk. Wrap the async iterator, pass chunks through unchanged, and record the cost in a finally block so it still runs when the client stops reading early.

A hard cutoff is a bad experience for a paying customer. A softer first step works better: past 80% of the budget, route the same task to a cheaper model. Many users won't notice, and your margin is protected. At 100%, block with a specific error so your UI can say "You've reached this month's AI limit. Upgrade?" instead of showing a generic failure.

In-memory counters are fine for one process. With several instances or serverless functions, use an atomic increment such as Redis INCRBYFLOAT llmbrake:{month}:{customer} {cost}. Key it by month and budgets reset without a cron job; add an EXPIRE so old months clean themselves up.

Once spend is attributed per customer, join it with what they pay you, for example Stripe subscriptions. A table of customer, AI cost, revenue and margin is usually enough to spot plans that need repricing or a lower cap.

I packaged this pattern as LLMBrake, a small MIT-licensed TypeScript library (about 500 lines, zero runtime dependencies):

npm install llmbrake Enter fullscreen mode Exit fullscreen mode import { createGuard, isBudgetExceededError } from " llmbrake "; const guard = createGuard ({ budgetUsd: ( ctx ) => ( ctx. plan === " pro "? 20: 2 ), downgradeAt: 0.8, downgradeMap: { " gpt-5.5 ": " gpt-5.4-mini " }, }); const chat = openai. chat. completions; const create = guard. wrap ( chat. create. bind ( chat )); const res = await create ( { model: " gpt-5.5 ", messages: [{ role: " user ", content: " Hello " }] }, { customerId: user. id, plan: user. plan, feature: " chat " }, ); // at the cap → throws BudgetExceededError Enter fullscreen mode Exit fullscreen mode It covers cached-token pricing, streaming usage, the downgrade step, a typed block error, metadata-only usage events, and a pluggable store with a fail-open default. Use it, or copy the pattern.

There's an in-browser demo (real library, simulated provider): https://llmbrake.com/demo?ref=devto

Disclosure: I build LLMBrake. A hosted dashboard (shared counters, alerts, AI cost vs. revenue per customer) is in early access at app.llmbrake.com.