Lovable Credits: Neue Limits seit 7. Oktober und warum leeres Guthaben deine Live-App anhält

Am 7. Oktober 2026 hat Lovable Nutzungslimits und Warnungen eingeführt. Das klingt nach Buchhaltung, betrifft aber direkt die Verfügbarkeit deiner App. Denn wer Lovable produktiv nutzt, zahlt Entwicklung und Betrieb mit derselben Währung.

Wofür verbraucht Lovable Credits?

Für zwei Dinge: Bauen und Betreiben. Credits sind die Verrechnungseinheit von Lovable. Die Doku unterscheidet diese Arten:

Lovable Cloud ist dabei das eingebaute Backend, also Datenbank, Login und Dateispeicher, die Lovable für dich betreibt. Laut Plans and credits gibt es jeden Monat 20 Credits zweckgebunden für Cloud und 4 für AI. Danach geht der Verbrauch ans allgemeine Guthaben, zuerst an die Credits, die am frühesten verfallen. Connector-Anfragen laufen von Anfang an über das allgemeine Guthaben.

Zur Größenordnung: Pro startet bei 25 US-Dollar für 100 Credits im Monat, Business bei 50 US-Dollar, jeweils mit Stufen bis 10.000 Credits. Nachkaufen kostet bei Pro 15 US-Dollar und bei Business 30 US-Dollar je 50 Credits. Ein nachgekaufter Credit kostet also je nach Plan 0,30 oder 0,60 US-Dollar, in der Einstiegsstufe mit 100 Credits im Monatsabo sind es 0,25 oder 0,50 US-Dollar. Größere Stufen sind pro Credit günstiger, bei 10.000 Credits im Monatsabo rund 0,23 oder 0,43 US-Dollar.

Was passiert mit der Live-App, wenn die Credits leer sind?

Die Seiten bleiben erreichbar, aber das Backend steht. Laut Lovable pausieren Datenbank und Backend-Dienste kurz nachdem das Guthaben aufgebraucht ist, KI-Funktionen der App gehen aus. Die Daten bleiben erhalten, sind aber bis zum Neustart nicht erreichbar. Je nach Fall musst du das Backend nach dem Aufladen von Hand per "Wake up" wieder starten.

In der Praxis heißt das: Eine App mit Login zeigt noch die Startseite, aber niemand kommt mehr an seine Daten. Ein internes Tool, ein Kundenportal oder ein Formular, das in die Datenbank schreibt, fällt aus. Der Auslöser kann harmlos sein: Ein Teammitglied baut an einem Nachmittag viel um, und der Monatsvorrat ist weg, bevor die nächste Abrechnung kommt.

Was können die neuen Limits genau?

Sie setzen Schwellen pro Workspace, Projekt oder Mitglied, die warnen oder blockieren. Die Details aus der Doku zu Usage limits and alerts:

• Wer: nur Owner und Admins, und nur auf bezahlten Plänen. Limits für Gruppen und API-Zugangsschlüssel gibt es nur in Business und Enterprise.
• Zeitraum: täglich oder monatlich. Der Monat beginnt am 1. um 00:00 UTC, unabhängig vom Abrechnungsdatum.
• Vorwarnung: bei 80 Prozent eines blockierenden Limits.
• Toleranz: Der Verbrauch kann ein hartes Limit leicht überschreiten, bevor der Block greift.
• Kein Freikaufen: Credits nachkaufen oder upgraden hebt einen Block nicht auf. Erst der neue Zeitraum, ein höheres Limit oder das Abschalten des Limits.
• Anfragen: Ein blockiertes Mitglied kann mehr anfragen, ein Admin genehmigt dauerhaft oder bis Periodenende.
• Low-Balance-Warnung: meldet, wenn das Guthaben unter einen Betrag oder Prozentsatz fällt, und blockiert nie.

Ein Detail entscheidet über das richtige Setup: Limits pro Mitglied zählen nur Build-Credits. Den Betrieb rechnet Lovable dem Projekt zu. Wer Cloud- oder AI-Kosten deckeln will, muss das Limit auf Projekt oder Workspace setzen.

Welche Falle steckt in den Limits?

Ein blockierendes Run-Limit legt deine App genauso lahm wie ein leeres Guthaben. Die Option "Pause Cloud" stoppt Datenbank, Speicher und Backend auch in veröffentlichten Apps. Die Seite lädt, die Funktionen sind für deine Nutzer weg. Gespeicherte Dateien kosten in der Pause weiter Credits. Und ein Limit auf alle Credits (General) stoppt Bauen und Betrieb zusammen.

Unsere Einschätzung: Für eine App, mit der Kunden oder Kollegen arbeiten, ist ein harter Deckel auf den Betrieb fast nie die richtige Wahl. Ein plötzlicher Ausfall kostet meist mehr als ein paar Credits zu viel. Hart begrenzen solltest du das Bauen.

Wie richtest du die Limits sinnvoll ein?

So würden wir es heute für einen Workspace mit einer Live-App und mehreren Bauenden aufsetzen:

1. Low-Balance-Warnung setzen. Zum Beispiel bei 25 Prozent des Guthabens. Sie blockiert nichts und verschafft dir Zeit zum Nachkaufen.
2. Build-Limit pro Mitglied als Standard. Monatlich, mit Block. So kann niemand allein den Vorrat leerbauen, und wer mehr braucht, fragt an.
3. Run-Limit fürs Live-Projekt nur als Warnung. Ohne Block. Steigt der Betrieb plötzlich, willst du es wissen, aber nicht abschalten.
4. Prototypen hart deckeln. Für Test- und Demo-Projekte darf das Run-Limit blockieren. Da stört eine Pause niemanden.
5. Zugangsschlüssel begrenzen (Business). Wer Lovable per API oder Automatisierung anspricht, bekommt ein eigenes Token-Limit.

Dazu ein Tipp, der Credits spart: Im Plan Mode kostet eine Nachricht laut Lovable einen Credit, plus eventuelle Recherche durch Subagenten. Größere Umbauten erst planen, dann bauen, verhindert teure Irrwege.

Was hat Lovable am 7. Oktober noch geändert?

Zwei Neuerungen für den Betrieb, beide im Changelog vom 7. Oktober:

• Lastwarnungen: Lovable meldet, wenn die Cloud-Datenbank unter hoher Last steht, schlägt Änderungen an Abfragen oder Code vor und bietet erst danach eine größere Instanz an, mit Anzeige der Credit-Folgen. Eine größere Instanz erhöht also den laufenden Run-Verbrauch.
• Migrationen im Code: Jede Änderung am Datenbankaufbau landet als SQL-Datei unter drizzle/migrations/. Drizzle ist ein Open-Source-Werkzeug für solche Änderungsschritte. Lovable verweigert Änderungen, die die veröffentlichte App brechen könnten, etwa das Löschen einer Spalte, solange du das nicht ausdrücklich in den Cloud-Berechtigungen erlaubst. Lass diese Option für Live-Apps aus.

Was heißt das für dich?

Wenn du eine Lovable-App im Einsatz hast, prüf heute drei Dinge: Wer im Workspace ist Admin, wie viel Guthaben bleibt bis Monatsende, und hängt eine Live-App am selben Topf wie eure Bau-Experimente. Wenn ja, setz die Limits wie oben, bevor es jemand anderes durch einen Ausfall merkt.

Unsere Einschätzung: Bei Kundenprojekten mit echten Geschäftsprozessen lohnt es sich, schon in der Architektur zu entscheiden, ob der Betrieb am selben Guthaben hängen soll wie das Bauen, oder ob ein separat betriebenes Backend besser passt. Wie wir vom Prototyp zum belastbaren MVP kommen, steht in unserem Artikel MVP entwickeln 2026. Wenn du für Abläufe rund um die App eine Automatisierung brauchst, hilft dir der Kostenvergleich Make oder n8n. Und wenn du deine App lieber gemeinsam mit uns aufsetzen willst: Sprich uns an.