Clawy / Guides / Eine bezahlte KI-API bepreisen

Wie man eine bezahlte KI-API bepreist, ohne Geld zu verlieren

Wenn du GPT oder Claude zu einem Pauschalpreis pro Call weiterverkaufst oder wrappst, kann ein einziger großer Prompt dich mehr kosten, als du verlangst. Hier ist die Rechnung und zwei Wege, das zu beheben.

Du hast ein LLM gewrappt, hinter einen Endpunkt gesetzt und verlangst einen sauberen Pauschalpreis — sagen wir $0,15 pro Call. Klar für deine Kunden, leicht nachvollziehbar. Das Problem: Das Modell darunter rechnet nicht pro Call ab. Es rechnet pro Token ab, und Tokens skalieren mit Prompt- und Antwortgröße. Bei einer kleinen Anfrage steckst du eine fette Marge ein. Bei einer großen kannst du mehr zahlen, als du eingenommen hast — und du merkst es erst, wenn die Provider-Rechnung kommt.

Warum Pauschalpreise lecken

Token-abgerechnete Modelle berechnen Input (den gesendeten Prompt) und Output (was das Modell generiert) getrennt. Laut den offiziellen Listenpreisen für Claude:

Deine Kosten für einen Call sind einfach:

cost = (input_tokens × input_price + output_tokens × output_price) / 1,000,000

Nimm Opus 4.8 zum Pauschalpreis von $0,15/Call. Allein der Output kostet $25 pro Million Tokens — also kosten schon 6.000 Output-Tokens $0,15 und fressen deinen ganzen Preis auf, bevor du einen einzigen Input-Token gezählt hast. Lass einen Kunden ein 100.000-Token-Dokument als Kontext schicken und eine lange Antwort verlangen, und dieser eine Call kann dich ein Vielfaches dessen kosten, was du verlangt hast. Multipliziere das mit ein paar Power-Usern, und das "profitable" Produkt läuft mit Verlust.

Finde deinen Break-even vor dem Launch

Die entscheidende Zahl ist der größte Prompt, den du bedienen kannst, bevor ein Call mehr kostet, als du verlangst. Bei fester Output-Größe ist die Break-even-Input-Größe:

break_even_input_tokens = (price × 1,000,000 − output_tokens × output_price) / input_price

Für Opus bei $0,15 mit einer 800-Token-Antwort: (0.15 × 1,000,000 − 800 × 25) / 5 = 26,000 Input-Tokens. Über ~26k Token Prompt verliert jeder Call Geld. Wenn dein echter Traffic das regelmäßig überschreitet, ist Pauschalpreis das falsche Modell — oder dein Preis ist zu niedrig.

Lösung 1 — Input und Output begrenzen

Wenn du Pauschalpreise behalten willst (Kunden lieben die Vorhersehbarkeit), begrenze beide Seiten, damit der Worst-Case-Call deinen Preis nicht übersteigen kann:

• Input-Größe begrenzen. Lehne Prompts über einem Token-/Zeichenlimit ab oder kürze sie — und zwar bevor du abrechnest oder das Modell aufrufst, damit eine übergroße Anfrage dich nichts kostet.
• Output begrenzen (max_tokens). Ein großzügiger Standard begrenzt trotzdem die teure Seite. Bei $25/1 Mio. sind je 1.000 Output-Tokens $0,025.
• Bemiss die Limits aus der Rechnung oben. Wähle Grenzen, bei denen worst-case cost < price gilt, mit Reserve für Retries, Fallbacks und Prompt-Cache-Misses (plane ~25–40 % Puffer ein).
• Kommuniziere die Limits. Schreibe die Input-/Output-Grenzen in dein API-Schema, damit Clients sich selbst begrenzen, statt auf überraschende Ablehnungen zu stoßen.

Genau so bleibt ein pauschal bepreister Endpunkt zahlungsfähig: Der Preis ist fix, aber die Arbeit dahinter ist begrenzt, sodass er nie ins Minus laufen kann.

Lösung 2 — nutzungsbasierte Preise

Die Alternative ist, aufzuhören so zu tun, als seien Calls gleichförmig, und nach tatsächlichem Verbrauch abzurechnen: Tokens messen (oft mit einem Aufschlagsfaktor über deinen Kosten) oder gestaffelte Preise nach Anfragegröße. Du gibst die Einfachheit einer runden Zahl auf, kannst aber bei einer großen Anfrage nie Geld verlieren, weil der Preis mit den Kosten mitläuft. Nutzungsbasiert ist richtig, wenn Promptgrößen stark schwanken oder du Large-Context-Workloads bedienst.

Vergiss die versteckten Kosten nicht

• Retries & Fallbacks. Ein fehlgeschlagener Call, der auf einem zweiten Modell wiederholt wird, kann die Token-Ausgaben für eine kundensichtbare Anfrage verdoppeln.
• Prompt-Cache-Misses. Caching senkt die Kosten für wiederholte Präfixe um ~90 %, aber nur bei Treffern — ein stiller Cache-Invalidator (ein Zeitstempel im System-Prompt, unsortiertes JSON) bedeutet, dass du jedes Mal den vollen Preis zahlst.
• Thinking-/Reasoning-Tokens. Wenn du Extended/Adaptive Thinking aktivierst, werden auch diese Tokens als Output abgerechnet.

Welches Modell du auch wählst, die Disziplin ist dieselbe: Kenne deine Kosten pro Call, kenne deinen Break-even und begrenze den Worst Case, bevor er einen zahlenden Kunden erreicht.