KI-Apps: Schwergewichts-Nutzer können Subskriptionsmodelle unrentabel machen
Bei KI-Apps im Abo ist der Umsatz pro Nutzer konstant, die Kosten jedoch nicht. Während leichte Nutzer nur wenige Cent kosten, kann ein intensiver Nutzer oder ein Hänger in einer Agent-Schleife mehr verursachen, als er zahlt. Da Tokenverbrauch und Umsatz in unterschiedlichen Dashboards liegen, bleibt das Problem oft unbemerkt.
Wenn man eine KI-App im Abonnement verkauft, bleiben die Einnahmen pro Nutzer konstant, während die Kosten pro Nutzer es nicht tun.
Ein gelegentlicher Nutzer kostet nur wenige Cent pro Monat. Ein intensiver Nutzer oder jemand, der in einer Agent-Schleife festhängt, kann jedoch mehr kosten, als er bezahlt. Die OpenAI-Rechnung zeigt Tokens, das Payments-Dashboard zeigt Einnahmen. Nichts verbindet beides auf Nutzerebene, weshalb man es erst von der Rechnung erfährt.
Ich habe FiscaLLM entwickelt, um eine einzige Frage zu beantworten: Welche Nutzer kosten mehr, als sie zahlen? Hier ist die Idee und wie man sie in etwa zehn Minuten ausprobieren kann.
import { createMeter } from " fiscallm "; // npm install fiscallm (Python: pip install fiscallm) const meter = createMeter ({ apiKey: process. env. FISCALLM_KEY, waitUntil }); const res = await openai. chat. completions. create ({ model, messages }); meter. trackOpenAI ( res, { userId, feature: " chat " }); Enter fullscreen mode Exit fullscreen mode Das SDK liest ausschließlich den Modellnamen und die Token-Zahlen. Es sieht niemals Prompts oder Antworten. Ereignisse werden im Hintergrund gebündelt, sodass die Anfrage keine zusätzliche Latenz erhält, und falls FiscaLLM ausfällt, bleibt die App unbeeinflusst.
Man fügt einfach eine RevenueCat- oder Stripe-Webhook-URL ein oder sendet Zahlungen selbst über die Revenue-API. FiscaLLM verknüpft Einnahmen und Kosten über die Nutzer-ID.
Man erhält die Marge pro Nutzer, pro Tarif und pro kostenloser Testphase sowie die Information, welches Modell oder welche Funktion die Rechnung antreibt. Anschließend kann man handeln:
Ich suche die ersten 10 Apps, die es ausprobieren. Wenn du eine KI-App mit Abonnements betreibst, sag mir in den Kommentaren oder auf dem Roadmap-Board, was noch fehlt.
Expand Marcus Kim Marcus Kim Marcus Kim Follow Freelance app developer with an MS in software engineering. I help beginners build real apps with AI, practical workflows, and fewer wasted hours. Location Los Angeles, CA Joined Jun 15, 2026 • Oct 23 Dropdown menu Copy link Hide Das Limit für erfasste Kosten und die Fail-open-Prüfung sollten eher als weiches Budget dargestellt werden, nicht als harte Ausgabenobergrenze.
Wenn zehn Anfragen meter.check(userId) durchlaufen, bevor ihre Nutzungsereignisse eintreffen, kann jede einzelne erlaubt werden, während das gebündelte Volumen insgesamt überschritten wird. Ich würde diesen Burst testen, indem ich die Ereignisübermittlung pausiere und dann die geschätzten Reservierungen mit den tatsächlichen Token-Kosten abgleiche. Das UUID-Detail ist auch bei SDK-Retries relevant: Man sollte die ursprüngliche Ereignis-ID wiederverwenden, statt bei jedem Senden eine neue UUID zu generieren.
Stehen Reservierungen oder eine explizite Anzeige der maximalen Überschreitung auf eurer Roadmap?
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
If you sell an AI app by subscription, your revenue per user is flat and your cost per user is not.
A light user costs you a few cents a month. A heavy one, or a user stuck in an agent loop, can cost more than they pay you. Your OpenAI bill shows tokens. Your payments dashboard shows revenue. Nothing joins the two by user, so you find out from the invoice.
I built FiscaLLM to answer one question: which users cost me more than they pay? Here's the idea and how to try it in about ten minutes.
import { createMeter } from " fiscallm "; // npm install fiscallm (Python: pip install fiscallm) const meter = createMeter ({ apiKey: process. env. FISCALLM_KEY, waitUntil }); const res = await openai. chat. completions. create ({ model, messages }); meter. trackOpenAI ( res, { userId, feature: " chat " }); Enter fullscreen mode Exit fullscreen mode The SDK reads only the model name and token counts. It never sees prompts or answers. Events are batched in the background, so it doesn't add latency to your request, and if FiscaLLM is down your app is unaffected.
Paste a RevenueCat or Stripe webhook URL, or send payments yourself with the revenue API. FiscaLLM joins revenue and cost on the user ID.
You get margin per user, per plan and per free trial, plus which model or feature drives the bill. Then you can act:
I'm looking for the first 10 apps to try it. If you ship an AI app with subscriptions, tell me what's missing in the comments or on the roadmap board.
Expand Marcus Kim Marcus Kim Marcus Kim Follow Freelance app developer with an MS in software engineering. I help beginners build real apps with AI, practical workflows, and fewer wasted hours. Location Los Angeles, CA Joined Jun 15, 2026 • Oct 23 Dropdown menu Copy link Hide The recorded-cost limit and fail-open check are worth presenting as a soft budget, not a hard spend ceiling.
If ten requests pass meter.check(userId) before their usage events arrive, each can be individually allowed while the batch overshoots. I'd test that burst with event delivery paused, then reconcile estimated reservations against actual token costs. The UUID detail also matters on SDK retries: reuse the original event ID rather than generating a new UUID per send.
Are reservations or an explicit maximum-overshoot indicator on your roadmap?