Aus dem Maschinenraum
3.800 Dollar mit einem Top-Modell oder über 25.000 Dollar mit einem schwachen Open-Source-Modell – dieselbe Aufgabe. Wie Sie Vibe-Coding-Kosten realistisch überschlagen.
Professionelle Vibe-Coding-Projekte kosten mit einem Top-Modell wie Claude Opus in aller Regel zwischen 3.000 und 15.000 Euro an reinen Tokenkosten – oft deutlich darunter, je erfahrener das steuernde Team ist. Ein konkretes Beispiel: Ein interner Webservice mit sechs Integrationen und Produktionsqualität liegt mit Claude Opus 4.6 bei einer Tokenbudget-Obergrenze von rund 3.800 Dollar. Mit einem schwächeren Open-Source-Modell versiebenfacht sich dasselbe Budget auf über 25.000 Dollar. Die Kernbotschaft dahinter: Der Preis pro Token ist relevant, aber die Zuverlässigkeit des Modells ist der dominante Kostenfaktor.
Das TokenBudgetModel (TBM) übersetzt Projektvariablen – Komplexität, Integrationen, Qualitätsanforderungen, Legacy-Anteil – in eine Tokenschätzung und damit in eine Budgetobergrenze. Es steht in der Tradition etablierter Schätzmodelle wie COCOMO II oder der Function-Point-Analyse, überträgt deren Grundgedanken aber auf die Ökonomie von LLM-generierten Tokens: Statt Personenmonaten steht am Ende ein Tokenbudget, das sich direkt in Euro oder Dollar bewerten lässt.
Ein Projekt, das mit einem Spitzenmodell wie Opus 4.6 oder 4.7 diese Schwelle überschritten hätte, ist in der Praxis bisher nicht aufgetaucht. Zum Vergleich: Ein Senior-Entwickler kostet in Deutschland etwa 800 bis 1.200 Euro pro Tag. Sobald Vibe Coding also mehr als drei bis fünf Entwicklertage einspart – inklusive Reviews, Fixes und Stabilisierung –, trägt sich die Tokenposition wirtschaftlich.
Der Vergleich zeigt die Hebelwirkung der Modellqualität deutlich:
Der Grund liegt nicht im Tokenpreis allein – schwächere Modelle sind pro Million Tokens oft sogar günstiger. Der Grund liegt im sogenannten Rework-Faktor: Wie viel Nacharbeit ein Modell durch fehlerhaften Code erzeugt.
Der wirkungsmächtigste Parameter im TBM ist die Modellrealität – wie gut ein Modell tatsächlich programmieren kann. Objektiviert wird das über Benchmarks wie SWE-Bench verified, eine Sammlung verifizierter Coding-Aufgaben. Ein Modell, das 72 Prozent dieser Aufgaben löst, erhält im TBM einen Wert von p = 0,72.
Aus diesem Wert ergibt sich der Rework-Faktor über die Formel Rework(p) = 10^(4×(1–p)). Diese Formel verläuft logarithmisch, nicht linear: Sinkt die Modellqualität um wenige Prozentpunkte, steigt der Nacharbeitsaufwand zunächst moderat. Unterhalb eines gewissen Schwellenwerts kippt das Verhältnis dramatisch. Der Grund ist strukturell: Schwächere Modelle produzieren nicht einfach etwas mehr fehlerhaften Code – sie erzeugen Fehler, die in Folgeiterationen neue Fehler nach sich ziehen. Jede Korrekturschleife destabilisiert den Kontext weiter und erzwingt zusätzliche Iterationen.
Ab einem Rework-Faktor von etwa 100× (bei p ≈ 0,50) übersteigen die kumulierten Tokenkosten in den meisten Projektszenarien den wirtschaftlichen Nutzen. Erfahrene Teams brechen in der Regel deutlich früher ab.
Zwei Faktoren entscheiden in der Praxis über die Kosten eines Vibe-Coding-Projekts:
Besonders relevant wird das dort, wo aus Datenschutz-, Compliance- oder Air-Gap-Gründen nur Open-Source-Modelle erlaubt sind – etwa im öffentlichen Sektor oder in stark regulierten Branchen. Wer dort auf Open-Source-Pflicht trifft, sollte den KI-Einsatz gezielt limitieren: punktuelle Unterstützung etwa bei einfachen Tests oder Boilerplate-Code anhand konkreter Referenzen, statt das Modell als Hauptautor einzusetzen.
Beim industrietauglichen Vorhaben entscheidet am Ende weniger, ob das Modell Code schreiben kann, sondern ob die Organisation dessen Korrektheit nachweisen kann.
Ein günstiges Modell mit viel Rework wird schnell teurer als ein teures, zuverlässiges Modell – selbst wenn die einzelnen Tokens billig wirken. Das ist der zentrale Denkfehler in vielen Budget-Diskussionen: Man vergleicht Preis pro Million Tokens, statt die tatsächlichen Gesamtkosten inklusive Nacharbeit zu betrachten.
Wer sein eigenes Projekt überschlagen will, findet den TokenBudgetModel-Rechner unter tbm.stefanai.de. Eine Einordnung, wann sich Vibe Coding grundsätzlich lohnt und wo es an Grenzen stößt, liefert der Pillar-Beitrag Vibe Coding: Was es ist und wann es sich lohnt.
Wie viel kostet ein typisches Vibe-Coding-Projekt? Bei professionellen Projekten mit einem Top-Modell liegen die reinen Tokenkosten meist zwischen 3.000 und 15.000 Euro, oft darunter. Ein Projekt, das diese Schwelle überschritten hätte, ist in der Praxis bislang nicht aufgetaucht.
Was ist das TokenBudgetModel (TBM)? Ein Schätzmodell, das Projektvariablen wie Komplexität, Integrationen, Qualitätsanforderungen und Legacy-Anteil in ein Tokenbudget übersetzt – vergleichbar mit COCOMO II oder Function-Point-Analyse, nur angepasst an die Ökonomie von LLM-Tokens.
Warum ist ein Open-Source-Modell trotz niedrigerem Tokenpreis oft teurer? Weil schwächere Modelle mehr fehlerhaften Code produzieren, der aufwendig nachgebessert werden muss. Dieser sogenannte Rework-Faktor steigt nicht linear, sondern kippt ab einem gewissen Qualitätsverlust dramatisch – die Personalkosten für Nacharbeit übersteigen dann schnell die gesparten Tokenkosten.
Ab wann lohnt sich Vibe Coding gegenüber klassischer Entwicklung? Sobald der eingesparte Aufwand mehr als drei bis fünf Entwicklertage entspricht – inklusive Reviews, Fixes und Stabilisierung –, trägt sich die Tokenposition typischerweise.
Kann ich meine eigenen Projektkosten selbst schätzen? Ja, über den TokenBudgetModel-Rechner unter tbm.stefanai.de. Er übersetzt Ihre Projektparameter in eine Tokenbudget-Obergrenze.
"Ich schicke regelmäßig kostenlose Updates zum Thema KI, Sicherheit und Anwendungen."
Wählen Sie direkt einen freien Slot in meinem Kalender.
Schreiben Sie mir Ihr Anliegen — ich melde mich zeitnah.
