Die Preise von KI-App-Buildern hängen davon ab, was als Arbeit zählt

Der günstigste Tarif für 100 Prompt-Iterationen pro Woche ist meist der, der rund um jeden Prompt am wenigsten Arbeit zählt. Der angegebene Monatspreis sagt fast nichts aus, solange du nicht weißt, ob ein Wiederholungsversuch, ein Planungsschritt, ein Testlauf, eine Bereitstellung und ein im Hintergrund arbeitender Agent auf demselben Zähler landen.

Ich habe Teams erlebt, die Tarife verglichen haben, indem sie den Abopreis durch 100 Prompts teilten. Das ist eine saubere, aber falsche Rechnung. Ein Prompt, der den Text eines Buttons ändert, und ein Prompt, der eine Datenbank umstrukturiert, zählen für die tippende Person jeweils als eine Nachricht. Sie können jedoch sehr unterschiedliche Rechnungen verursachen. Ein ehrlicher Vergleich beginnt mit einem Arbeitsprotokoll und wendet anschließend die Abrechnungsregeln jedes Anbieters auf genau dieses Protokoll an.

Dieser Artikel nutzt einen hypothetischen Preiskatalog, nicht die Preise eines bestimmten Anbieters. Er soll dir eine Berechnung geben, die du vor dem Kauf durch echte Tarifbedingungen ersetzen kannst.

Dieselbe Prompt-Zahl kann drei unterschiedliche Rechnungen verbergen

Die Zahl der Nutzernachrichten misst Unterhaltung, nicht Rechenleistung oder erledigte Arbeit. Credit-Tarife erfassen meist Modellaktivität, aufgabenbasierte Tarife eine vom Anbieter definierte Arbeitseinheit, und Pauschaltarife verkaufen Zugang innerhalb einer Grenze. Diese Grenzen führen zu unterschiedlichen Summen, obwohl die Anwendung und die 100 wöchentlichen Anfragen gleich bleiben.

Angenommen, ein Gründer fordert jede Woche 70 kleine Änderungen an der Oberfläche, 20 Änderungen an mehreren Dateien und 10 Änderungen am Build oder an der Bereitstellung an. Sichtbar sind 100 Anfragen. Dahinter kann der Builder das Repository untersuchen, einen Plan erstellen, ein Modell mehrmals aufrufen, Tests ausführen, eine fehlgeschlagene Änderung reparieren, die App neu bauen und einen Agenten weiterlaufen lassen, nachdem die Chat-Antwort angezeigt wurde. Ein Tarif kann jeden Modellaufruf berechnen. Ein anderer wertet die gesamte Folge als eine Aufgabe. Ein Abo kann sie einschließen, begrenzen oder Teile davon als Mehrverbrauch abrechnen.

Genau hier verschwimmt für Käufer oft der Unterschied: Eine Iteration ist ein Entscheidungszyklus des Nutzers, ein abrechenbares Ereignis dagegen das, was der Anbieter zu messen beschlossen hat. Wer beides gleichsetzt, bevorzugt den Tarif mit der vage formuliertesten Preisseite. Außerdem kann ein günstig wirkender Tarif teuer werden, sobald das Team seine Anwendung an die Plattform gebunden hat.

Nutze für den Vergleich einen Monatsfaktor von 4,33 Wochen, statt so zu tun, als hätte jeder Monat vier Wochen. Aus hundert wöchentlichen Iterationen werden 433 monatliche Iterationen. Diese kleine Korrektur fügt 33 Iterationen hinzu, noch bevor ein einziger Wiederholungsversuch oder Hintergrundjob in die Rechnung kommt.

Eine gute Angebotsanfrage bittet den Anbieter, die Arbeit zu klassifizieren, statt nur eine Gesamtsumme zu schätzen. Frage: Was startet den Zähler? Wann stoppt er? Zählt ein fehlgeschlagener Lauf? Zählt eine automatische Wiederholung? Welche Arbeit läuft weiter, nachdem die Oberfläche die Antwort als abgeschlossen zeigt? Kann ungenutzte Kapazität übertragen werden? Die Antworten bestimmen die Rechnung.

Eine Arbeitslast festlegen, bevor du den Taschenrechner öffnest

Stelle eine typische Woche aus der Arbeit zusammen, die du wirklich erwartest, und friere sie vor dem Tarifvergleich ein. Wenn du die Arbeitslast für jedes Preismodell änderst, prüfst du Verkaufstexte statt Preise.

Für den Beispielvergleich nutze ich diese wöchentliche Arbeitslast:

• 70 kleine Änderungen mit je einer Credit-Einheit
• 20 Änderungen an mehreren Dateien mit je drei Credit-Einheiten
• 10 Änderungen am Build oder an der Bereitstellung mit je fünf Credit-Einheiten
• 25 Wiederholungsläufe mit durchschnittlich zwei Credit-Einheiten
• 35 Hintergrundläufe, die zusammen 45 Credit-Einheiten verbrauchen

Die 100 angeforderten Iterationen verbrauchen bei ihren ersten Durchläufen 180 hypothetische Credit-Einheiten. Wiederholungen fügen 50 hinzu. Planung, Indexierung, Tests und Bereitstellung fügen 45 hinzu. Das ergibt 275 Einheiten pro Woche oder 1.190,75 Einheiten in einem durchschnittlichen Monat.

Unter aufgabenbasierter Abrechnung hat dieselbe Aktivität eine zweite Form. Sie erzeugt jede Woche 100 vom Nutzer gestartete Aufgaben, 25 gestartete Wiederholungen und 35 gestartete Hintergrundaufgaben. Das sind 160 Ereignisse pro Woche und 692,8 Ereignisse pro Monat. Ob alle 692,8 abrechenbar sind, hängt von der vertraglichen Definition einer Aufgabe ab.

Erfasse erfolgreiche und fehlgeschlagene Arbeit getrennt. Eine Fehlerquote, die nur auf sichtbaren Fehlermeldungen beruht, übersieht stille Reparaturen, automatische Modellwechsel und erneut ausgeführte Tests. Der Nutzungs-Export der Plattform ist, sofern vorhanden, aussagekräftiger als ein Chat-Verlauf, weil ein Chat mehrere Agentenläufe in einer Antwort zusammenfassen kann.

Nutze eine Woche mit dem normalen Chaos: einem unklaren Prompt, einem Abhängigkeitskonflikt, einem Test, der aus einem anderen Grund fehlschlägt, und einer Reparatur bei der Bereitstellung. Eine makellose Demowoche liefert ein Budget, das nur bis zum Beginn echter Entwicklung hält.

Blähe die Arbeitslast nicht auf, um dich abzusichern. Füge nach der Berechnung der beobachteten Basis einen separaten Puffer für Schwankungen hinzu. Wenn Basis und Puffer getrennt bleiben, erkennst du, ob ein Tarif wegen normaler Arbeit teuer ist oder weil du dich gegen einen arbeitsreichen Monat abgesichert hast.

Credit-Pakete berechnen die Arbeit innerhalb des Builders

Credit-Pakete kosten weniger, wenn die Preise pro Einheit auf der Plattform niedrig sind, ungenutzte Credits lange genug erhalten bleiben und der Builder wenige Reparaturdurchläufe braucht. Sie kosten mehr, wenn eine einfache Anfrage mehrere für den Nutzer unsichtbare Modellaufrufe auslöst.

Ein Credit ist keine genormte Einheit. Er kann Tokens, Modellaufrufe, Agentenschritte, Sekunden oder eine gewichtete Mischung abbilden. Ein Anbieter kann für ein schnelles Modell und ein leistungsfähigeres Modell auch unterschiedlich viele Credits berechnen. Die Credit-Zahl zweier Pakete zu vergleichen, ist sinnlos, solange beide Plattformen den Verbrauch nicht auf dieselbe Weise definieren, was selten der Fall ist.

Berechne die hypothetische Arbeitslast mit einem Paket aus 500 Einheiten für 30 US-Dollar. Der Monatsbedarf beträgt 1.190,75 Einheiten. Weil Pakete nicht teilbar sind, braucht der Käufer drei Pakete und zahlt 90 US-Dollar. Am Monatsende bleiben 309,25 Einheiten übrig, falls Credits nicht verfallen. Die effektiven Kosten der verbrauchten Arbeit liegen bei etwa 7,56 Cent pro Einheit, obwohl das Paket mit 6 Cent wirbt, weil ungenutzte Kapazität gekauft werden musste.

Übertragbarkeit verändert das Ergebnis. Bleiben die 309,25 Einheiten erhalten, können im nächsten Monat zwei statt drei Pakete reichen. Über mehrere stabile Monate nähert sich der Durchschnittspreis dem beworbenen Satz an. Verfallen Credits monatlich, gehört der ungenutzte Rest zum Preis. Lass ihn nie aus dem Modell weg.

Die Modellauswahl kann den Verbrauch verändern, ohne die Prompt-Zahl zu ändern. Wenn die Plattform komplexe Änderungen an ein Modell mit vierfachem Einheitenfaktor leitet, können die zehn schwierigsten Anfragen die Rechnung dominieren. Frage, ob diese Weiterleitung automatisch erfolgt, ob du sie später sehen kannst und ob du eine Obergrenze setzen kannst. Ein günstigeres Modell, das zweimal scheitert und erneut versucht wird, kann mehr kosten als ein leistungsfähiges Modell, das beim ersten Mal Erfolg hat.

Credit-Pakete eignen sich für unregelmäßige Projekte, weil du zahlst, wenn Arbeit anfällt, sofern die Credits ausreichend lange gültig bleiben. Für ein Team, das frei experimentiert, sind sie schwerer zu budgetieren. Der Zähler kann Verhalten verändern: Menschen bündeln unzusammenhängende Anforderungen in übergroße Prompts, vermeiden Tests oder akzeptieren schwache Ergebnisse, um Credits zu sparen. Damit sinkt die Rechnung auf Kosten der Anwendung.

Die heikle Frage lautet, ob Hintergrundarbeit Credits verbrauchen sollte. Sie verbraucht Ressourcen, deshalb ist ihre Abrechnung vertretbar. Problematisch wird es, wenn der Käufer sie weder vorhersehen noch stoppen kann. Eine faire Bewertung prüft, ob die Oberfläche jede Hintergrundgebühr zeigt und ob ein Ausgabenlimit neue Arbeit stoppt, bevor das Guthaben auf null fällt.

Aufgabenbasierte Abrechnung hängt davon ab, wo eine Aufgabe beginnt und endet

Aufgabenbasierte Abrechnung kann das günstigste Modell sein, wenn ein Preis den gesamten Versuch abdeckt, einschließlich Planung, Modellaufrufe, Tests und Reparaturen. Sie wird am teuersten, wenn jede interne Aktion zu einer neuen Aufgabe wird.

Wende einen hypothetischen Satz von 0,14 US-Dollar auf jedes gestartete Ereignis im Protokoll an. Bei 692,8 monatlichen Ereignissen betragen die Kosten nach Rundung auf Cent 96,99 US-Dollar. Das ist mehr als das Ergebnis der Credit-Pakete mit 90 US-Dollar, obwohl vierzehn Cent auf einer Preisseite nach wenig klingen.

Ändere nun einen Vertragssatz: Berechne nur die 433 vom Nutzer angeforderten Iterationen und schließe Wiederholungen sowie Hintergrundarbeit in jede Aufgabe ein. Die monatlichen Kosten sinken auf 60,62 US-Dollar. An der Anwendung hat sich nichts geändert. Die Aufgabengrenze hat sich geändert, und sie verschiebt 36,37 US-Dollar.

Abrechnung nach abgeschlossenen Aufgaben braucht eine weitere Definition. Wenn ein Lauf Dateien ändert, die Bereitstellung aber fehlschlägt, hat die Plattform die Aufgabe dann abgeschlossen? Wenn der Nutzer das Ergebnis ablehnt und um eine Korrektur bittet, ist das eine neue Aufgabe oder eine Fortsetzung? Anbieter brauchen Regeln, damit unter einer Gebühr nicht unbegrenzt gearbeitet wird. Käufer brauchen jedoch Regeln, die sie aus einem Aktivitätsprotokoll nachvollziehen können.

Die verbreitete Empfehlung, Kosten pro erfolgreichem Prompt zu vergleichen, ist falsch, wenn Erfolg selbst gemeldet wird. Nutzer akzeptieren Teilergebnisse, teilen große Anforderungen auf und korrigieren Ausgaben manuell. Niedrige Kosten pro erfasstem Erfolg können viele Stunden Nacharbeit verschleiern. Vergleiche stattdessen die Kosten pro akzeptierter Änderung, also ab dem Punkt, an dem das Team das Ergebnis zusammenführen, bereitstellen oder anderweitig behalten würde.

Aufgabenpreise haben beim Budgetieren einen Vorteil, wenn die Einheit etwas abbildet, das Menschen erkennen. Ein Team kann 400 akzeptierte Änderungen verlässlicher schätzen als Millionen Tokens. Dieser Vorteil verschwindet, wenn das Produkt Indexierung, Planung, Tests und Bereitstellung als separate Aufgaben bezeichnet. Lies die Ereignisnamen in einer echten Rechnung oder einem Nutzungs-Export, bevor du die Einheit als stabil ansiehst.

Frage auch, wie Parallelität funktioniert. Zwei gleichzeitig laufende Agenten können die Dauer verkürzen und zugleich die Zahl der gestarteten Aufgaben verdoppeln. Eine Hintergrundreparatur, die einen Testagenten startet, kann einmal, zweimal oder gar nicht zählen. Die Rechnung folgt dem Zähler, nicht der verstrichenen Zeit.

Pauschalabos gewinnen nur innerhalb ihrer enthaltenen Grenze

Ein Pauschalabo kostet für diese Arbeitslast am wenigsten, wenn die Monatsgebühr alle 433 Nutzeriterationen, 108,25 gestarteten Wiederholungen und 151,55 gestarteten Hintergrundaufgaben einschließt. Liegt eine Kategorie außerhalb des Abos, rechne sie hinzu, bevor du den Pauschaltarif für günstiger erklärst.

Nimm einen hypothetischen Monatstarif für 79 US-Dollar, der bis zu 600 interaktive Läufe und Wiederholungen sowie 200 Hintergrundläufe enthält. Das Beispiel erzeugt monatlich 541,25 interaktive Läufe und Wiederholungen sowie 151,55 Hintergrundläufe. Beide Werte passen hinein, daher bleiben die Kosten bei 79 US-Dollar. Unter diesen Annahmen schlägt der Pauschalpreis die Credit-Pakete für 90 US-Dollar und den Tarif nach gestarteten Aufgaben für 96,99 US-Dollar.

Das Wort «unbegrenzt» hat in einer Tabelle keinen Wert. Ersetze es durch die tatsächliche Fair-Use-Schwelle, ein Parallelitätslimit, eine Modellbeschränkung oder eine Regel zur Verlangsamung. Wenn der Anbieter keine Grenze nennt, modelliere einen niedrigen und einen hohen Fall. Ein Tarif, der nur bei einer grenzenlosen Auslegung günstig aussieht, hat keinen verlässlichen Preis geliefert.

Pauschaltarife erzeugen auch Sprungkosten. Bei 599 enthaltenen Läufen kostet ein weiterer Lauf möglicherweise nichts. Bei 600 kann der nächste Lauf einen Mehrverbrauch auslösen oder einen höheren Tarif erzwingen. Zeichne mindestens drei Auslastungsstufen auf: einen ruhigen Monat, den erwarteten Monat und einen Release-Monat. Nur der erwartete Fall verdeckt den Punkt, an dem das Abo springt.

Sitze zählen, wenn nach Nutzern statt nach Arbeit abgerechnet wird. Ein Tarif für 79 US-Dollar für eine Person kostet 316 US-Dollar für vier erforderliche Sitze, auch wenn das Team dieselben 433 Iterationen teilt. Gehe nicht davon aus, dass die gemeinsame Nutzung eines Kontos erlaubt ist. Berechne die Personen ein, die Prompts prüfen, Bereitstellungen freigeben oder die Nutzung kontrollieren müssen.

Eine Pauschalgebühr kann gesundes Experimentieren fördern, weil jede fehlgeschlagene Idee keine sichtbare Kleinstgebühr auslöst. Sie kann Verschwendung aber auch verbergen, bis die Plattform das Konto drosselt. Die Nutzung muss weiterhin sichtbar sein. Du musst wissen, ob Agenten in Schleifen laufen und ob ein Release-Monat die enthaltene Grenze überschreitet.

Jahresrabatte kommen in der Berechnung zuletzt. Ermittle zuerst das günstigste Modell zu monatlichen Bedingungen. Rechne danach Rabatt und Bindungskosten ein. Zehn Monate für ein Tool zu zahlen, das nach drei Monaten aufgegeben wird, ist keine Ersparnis.

Wiederholungen gehören in die Basis, nicht in eine Fußnote

Wiederholungen gehören zur normalen Entwicklungsarbeit. Ein Preisvergleich, der von perfekten Ergebnissen beim ersten Versuch ausgeht, eignet sich nicht für eine Kaufentscheidung. Die hilfreiche Kennzahl ist der Wiederholungsfaktor: Gesamtzahl der Versuche geteilt durch angeforderte Iterationen.

Im Beispiel stehen 125 interaktive Versuche 100 angeforderten Iterationen gegenüber, also beträgt der Wiederholungsfaktor 1,25. Das heißt nicht, dass 25 Prozent der Prompts schlicht fehlschlagen. Manche Anfragen müssen präzisiert werden, manche Änderungen bestehen Codeprüfungen, verfehlen aber die Absicht, und manche Fehler entstehen durch Tools oder Abhängigkeiten. Für die Abrechnung ist es dasselbe, wenn der Tarif einen weiteren Versuch misst.

Miss Wiederholungen mit einer Regel, die zwei Personen einheitlich anwenden können. Zähle einen Wiederholungsversuch, wenn der Nutzer nach Ablehnung oder Reparatur der vorherigen Ausgabe dasselbe gewünschte Ergebnis erneut verlangt. Zähle eine wirklich neue Anforderung nicht als Wiederholung. Kennzeichne automatische Wiederholungen separat, da ein Nutzer sie möglicherweise nie sieht.

Ein kleiner Pilot sollte die Aufgaben enthalten, die voraussichtlich schwierig sind. Wenn du nur Texte für Landingpages und Farbänderungen testest, sagt die Wiederholungsrate wenig über Datenbankmigrationen, Authentifizierung, Zustandsverwaltung oder Mobile Builds aus. Führe mindestens eine riskante Änderung mit jedem Kandidaten durch und prüfe das Aktivitätsprotokoll.

Wiederholungen wirken sich je nach Modell unterschiedlich aus:

• Bei Credit-Abrechnung werden meist die Ressourcen jedes Versuchs berechnet.
• Bei Abrechnung nach gestarteten Aufgaben wird meist jeder Versuch berechnet, wenn die Wiederholung ein Ereignis erzeugt.
• Bei Abrechnung nach Abschluss können fehlgeschlagene Versuche enthalten sein, je nach Abschlussregel.
• Pauschaltarife fangen Wiederholungen ab, bis sie ein enthaltenes Limit oder eine Fair-Use-Kontrolle erreichen.

Akzeptiere kostenlose Wiederholungen nicht als vollständige Antwort. Frage, ob die Wiederholung dasselbe Modell nutzt, ob ein automatischer Wechsel ein separates Kontingent verbraucht und wie lange das kostenlose Wiederholungsfenster offen bleibt. Eine am nächsten Morgen eingereichte Korrektur kann zu einer neuen Aufgabe werden, obwohl die Arbeit offensichtlich dieselbe ist.

Es gibt außerdem menschliche Kosten für Wiederholungen. Ein Tarif kann in Dollar günstig und in Aufmerksamkeit teuer sein, wenn Nutzer jede Reparatur überwachen müssen. Erfasse im Pilotprojekt die Minuten für die Prüfung pro akzeptierter Änderung. Drücke diese Zeit nicht zwanghaft in die Plattformrechnung, sondern stelle sie daneben, damit ein niedriger Preis keinen schlechten Ablauf verdeckt.

Hintergrundagenten sind der unsichtbare Multiplikator

Die Arbeit von Hintergrundagenten muss als eigene Zeile erscheinen, weil sie weiterlaufen kann, nachdem der Nutzer eine Antwort sieht. Repository-Indexierung, Planung, Abhängigkeitsprüfungen, Tests, Build-Überwachung, Bereitstellung und Reparaturagenten können Budget verbrauchen, ohne eine weitere Chat-Nachricht zu erzeugen.

Unser Beispiel setzt 35 Hintergrundläufe und 45 Credit-Einheiten pro Woche an. Diese Zahlen sind bewusst sichtbare Annahmen. Ersetze sie durch Nutzungsdaten aus einem Pilotprojekt. Wenn ein Anbieter nur eine kombinierte Gesamtsumme zeigt, führe denselben Prompt einmal mit deaktivierter optionaler Automatisierung und einmal mit aktivierter Automatisierung aus. Die Differenz ist eine Schätzung, kein Beweis, aber besser, als die Arbeit als kostenlos zu behandeln.

Der Planungsmodus verdient besondere Aufmerksamkeit. Ein Plan kann teure fehlgeschlagene Umsetzungen vermeiden, indem er Konflikte früh erkennt. Er kann aber auch vor jeder trivialen Änderung einen kostenpflichtigen Schritt hinzufügen. Teste ihn getrennt bei kleinen und großen Änderungen. Die richtige Regel kann sein, Planung für Schemaänderungen und Arbeit an mehreren Dateien einzusetzen, sie bei Textänderungen aber auszulassen.

Die Indexierung hat eine andere Kostenform. Der erste Durchlauf über ein Repository kann teuer sein, spätere inkrementelle Aktualisierungen dagegen wenig kosten. Ein einwöchiges Pilotprojekt kann die laufenden Kosten überzeichnen, wenn es die Erstanalyse enthält, oder sie unterschätzen, wenn das Produktiv-Repository deutlich größer ist. Trenne Einrichtungsverbrauch von wiederkehrendem Verbrauch.

Tests und Bereitstellung sind kein verzichtbarer Ballast. Wenn du sie ausschaltest, um innerhalb eines Credit-Limits zu bleiben, verlagerst du die Fehlererkennung auf Nutzer. Bepreise den sicheren Ablauf, den du tatsächlich betreiben willst, einschließlich der Prüfungen, die ihn schützen. Ein Vergleich auf Basis deaktivierter Tests beantwortet die falsche Geschäftsfrage.

Koder.ai unterstützt Planungsmodus, Bereitstellung und Hosting, Snapshots und Rollback sowie Quellcode-Export. Ein Pilotprojekt kann diese Teile des Ablaufs daher beobachten, statt nur Chat-Nachrichten zu bepreisen. Tarifnamen und Preise müssen dennoch in der aktuellen Produktoberfläche geprüft werden, weil der Kontext hier Stufen, nicht ihre aktuellen Kontingente festlegt.

Setze ein Hintergrundbudget, wenn das Produkt es erlaubt, aber verwechsle eine Obergrenze nicht mit Vorhersehbarkeit. Eine Obergrenze verhindert überhöhte Ausgaben, indem sie Arbeit stoppt. Die Anwendung kann dennoch einen Release verpassen, während ein Agent auf mehr Kapazität wartet. Halte sowohl die finanzielle Grenze als auch die betriebliche Folge fest.

Jeden Kandidaten mit demselben Protokoll prüfen

Ein Protokoll macht den Vergleich nachvollziehbar und legt Vertragsunklarheiten offen, bevor daraus ein Streit über die Rechnung wird. Eine Zeile sollte ein gemessenes Ereignis beschreiben und genug Kontext enthalten, um es Credits, Aufgaben und Abo-Kontingenten zuzuordnen.

Kopiere diese CSV-Kopfzeile und nutze sie während eines Pilotprojekts:

week,event_id,requested_iteration,event_type,outcome,retry_of,background_kind,credit_units,task_events,flat_bucket,notes
2026-W01,001,1,user_edit,accepted,,,1,1,interactive,copy change
2026-W01,002,2,user_edit,rejected,,,3,1,interactive,multi file edit
2026-W01,003,2,retry,accepted,002,,2,1,interactive,repair after failed test
2026-W01,004,2,background,completed,,test,1,1,background,automatic test run

Halte Ereignistyp und Ergebnis getrennt. Ein Hintergrundtest kann erfolgreich abgeschlossen werden, während die angeforderte Änderung trotzdem nicht akzeptiert wird. Wenn du diese Fakten in einem Status zusammenfasst, kannst du die Regel eines Anbieters für abgeschlossene Aufgaben nicht prüfen.

Berechne am Ende der Woche vier Werte:

monthly_iterations = weekly_requested_iterations * 4.33
monthly_credits = weekly_credit_units * 4.33
monthly_task_events = weekly_task_events * 4.33
retry_amplification = (user_attempts + retry_attempts) / requested_iterations

Wende dann die Tarifbedingungen an, ohne die Zeilen zu verändern. Für den hypothetischen Katalog lautet die Berechnung:

credit_cost = ceil(1190.75 / 500) * $30 = $90.00
started_task_cost = 692.8 * $0.14 = $96.99
flat_cost = $79.00, because 541.25 interactive runs < 600
             and 151.55 background runs < 200

Eine Tabelle sollte außerdem ungenutzte Credits, verbleibende enthaltene Kapazität und die nächste Preisgrenze zeigen. Der Gewinnertarif im Beispiel hat noch 58,75 interaktive Läufe und 48,45 Hintergrundläufe übrig. Dieser Puffer reicht nicht für eine Release-Woche, die die Bereitstellungsarbeit verdoppelt. Das Team sollte diesen Fall deshalb vor einer Bindung berechnen.

Bitte den Anbieter, eine anonymisierte Protokollseite zu prüfen. Frage nicht, welcher Tarif am günstigsten ist. Frage, wie jede Zeile klassifiziert würde. Eine schriftliche Klassifizierung hilft mehr als eine Verkaufsschätzung, weil du sie mit der ersten Rechnung vergleichen kannst.

Schwankungen sind wichtiger als der Listenpreis

Im Beispiel gewinnt das Pauschalabo mit 79 US-Dollar, gefolgt von Credit-Paketen mit 90 US-Dollar und Abrechnung nach gestarteten Aufgaben mit 96,99 US-Dollar. Diese Reihenfolge gilt nur für den genannten Katalog und die genannte Arbeitslast. Eine kleine Änderung bei der Behandlung von Wiederholungen oder enthaltener Hintergrundarbeit kann sie umkehren.

Berechne für jedes Paar den Break-even-Punkt. Der Pauschaltarif für 79 US-Dollar schlägt Credit-Pakete für 30 US-Dollar, sobald der Monatsbedarf drei oder mehr Pakete erfordert, sofern ungenutzte Credits keinen künftigen Wert haben. Wenn die Übertragung erlaubt, jede Einheit zu nutzen, entsprechen 79 US-Dollar bei sechs Cent je Einheit etwa 1.316,7 Credit-Einheiten. Darunter sind vollständig genutzte Credits günstiger.

Gegenüber gestarteten Aufgaben zu 0,14 US-Dollar entsprechen 79 US-Dollar etwa 564,3 Ereignissen. Die erwarteten 692,8 Ereignisse liegen darüber. Berechnet der Aufgabentarif jedoch nur die 433 angeforderten Iterationen, kostet er 60,62 US-Dollar und gewinnt. Wieder ist eine Definition wichtiger als der beworbene Satz.

Führe Sensitivitätsfälle durch, statt so zu tun, als sei die Schätzung exakt. Ändere für diese Arbeitslast den Wiederholungsfaktor von 1,10 auf 1,50, die Hintergrundarbeit von 20 auf 60 wöchentliche Ereignisse und den Verbrauch komplexer Änderungen um einen vernünftigen, vom Anbieter genannten Multiplikator. Du brauchst keine Dutzende Szenarien. Du brauchst die wenigen Variablen, die die Entscheidung ändern können.

Betrachte Cashflow und Bindung getrennt von den Stückkosten. Pakete können Flexibilität erhalten. Ein Monatsabo schafft eine vorhersehbare Obergrenze, solange du innerhalb seiner Grenze bleibst. Ein Jahresabo tauscht Flexibilität gegen Rabatt. Quellcode-Export und Snapshots können den Ausstieg aus einem Builder günstiger machen, doch sie machen eine Migration nicht kostenlos. Die exportierte Anwendung braucht weiterhin einen funktionierenden Build, Infrastruktur und jemanden, der sie warten kann.

Ein Gründer mit unsicherer Nutzung sollte das Modell bevorzugen, dessen Nachteil sichtbar ist. Das können Pakete mit langer Übertragbarkeit sein, selbst wenn die erwartete Monatssumme etwas höher liegt. Ein Team mit gleichmäßiger, gemessener Arbeit kann einen Pauschaltarif in der Mitte seines enthaltenen Bereichs wählen. Ein Aufgabentarif passt zu Arbeit, die sich klar akzeptierten Ergebnissen zuordnen lässt und Reparaturarbeit innerhalb der Aufgabe einschließt.

Entscheide nicht aufgrund des Gewinners im Beispiel. Entscheide erst, nachdem du jede hypothetische Rate und jedes Kontingent durch Bedingungen ersetzt hast, auf die du verweisen kannst, und jede Annahme zur Arbeitslast durch eine Beobachtung aus dem Pilotprojekt.

Das Abrechnungsmodell einem Akzeptanztest unterziehen

Ein Preismodell ist entscheidungsreif, wenn eine andere Person die Monatssumme aus dem Protokoll und den Tarifbedingungen nachvollziehen kann. Hängt die Berechnung davon ab, dass ein Verkäufer eine interne Aufgabe nachträglich auslegt, hat das Modell den Test nicht bestanden.

Nutze diese kurze Akzeptanz-Checkliste:

1. Erfasse 100 repräsentative angeforderte Iterationen oder eine kleinere Stichprobe, die jeden wichtigen Arbeitstyp enthält.
2. Kennzeichne Wiederholungen, automatische Wiederholungen, Pläne, Tests, Builds, Bereitstellungen und andere Hintergrundläufe.
3. Ordne jedes Ereignis der Credit-, Aufgaben- oder enthaltenen Kontingentregel des Anbieters zu.
4. Berechne erwartete, ruhige und Release-Monatssummen mit demselben Faktor 4,33.
5. Speichere die Tarifbedingungen und vergleiche die erste echte Rechnung mit der Prognose.

Lege vor dem Pilotprojekt eine Toleranz fest. Du könntest zum Beispiel jede Summe untersuchen, die mehr als 10 Prozent über der Prognose liegt. Der Prozentsatz ist eine Managemententscheidung, kein Branchenstandard. Er soll eine Prüfung erzwingen, solange der Ereignisverlauf noch vorhanden ist.

Wenn die tatsächliche Nutzung die Prognose übersteigt, finde die verantwortliche Zeilenkategorie. Mehr akzeptierte Arbeit ist etwas anderes als mehr Wiederholungen. Mehr geplante Bereitstellungsläufe sind etwas anderes als eine Agentenschleife. Die Lösung kann ein größerer Tarif, eine engere Agentenrichtlinie, klarere Prompts oder eine Abrechnungskorrektur sein. Eine einzelne Gesamtsumme kann das nicht unterscheiden.

Halte das Protokoll in den ersten drei Abrechnungszyklen neben die Rechnung, denn ein ruhiges Pilotprojekt kann Batch-Jobs, Release-Arbeit und automatische Reparaturen übersehen. Das günstigste Modell für 100 wöchentliche Iterationen ist daher an Bedingungen geknüpft, die Entscheidung muss aber nicht vage bleiben. Im klar definierten Beispiel gewinnt das Pauschalabo für 79 US-Dollar. Bei auf erfolgreiche Ergebnisse begrenzter Aufgabenabrechnung kostet dieselbe Arbeit 60,62 US-Dollar und der Aufgabentarif gewinnt. Credit-Pakete gewinnen bei niedrigerer oder sprunghafter Nutzung, wenn die Übertragbarkeit Verschwendung verhindert. Schreibe auf, was zählt, miss die versteckte Arbeit und lass die Rechnung das Versprechen beweisen.