Wer über die Kosten von n8n spricht, vergleicht oft nur den Abopreis und stellt einen Monat nach dem Start fest, dass die Rechnung vor allem aus Modellaufrufen besteht. n8n übernimmt die Ablaufsteuerung; die eigentliche inhaltliche Arbeit leistet meist die Modell-API dahinter. Das eine wird nach Tarif oder Server abgerechnet, das andere nach Tokens oder Anfragen – zwei grundverschiedene Kostenstrukturen.

Dieser Artikel zerlegt die n8n-Kosten in vier rechenbare Blöcke und beschreibt Schätzschritte sowie Steuerungsmöglichkeiten. Konkrete Beträge hängen von Tarif, Modell und Wechselkurs ab; maßgeblich sind die offizielle n8n-Preisseite und die Modellpreise.

Hinweis: n8n ist eine Marke der jeweiligen Rechteinhaber. Dieser Artikel steht in keiner Zugehörigkeit zu n8n und dient ausschließlich der technischen und wirtschaftlichen Betrachtung.

1. Woraus sich die Kosten zusammensetzen

Zuerst eine Kostenlandkarte, damit nicht nur die Softwaregebühr im Blick bleibt.

Kostenblock Abrechnung Leicht übersehen
n8n Cloud-Abo Tarif und monatliche Ausführungen Teamgröße, Mehrverbrauch, Tarifwechsel
Modell-API Input- und Output-Tokens Retries, wiederholter Kontext, lange Ausgaben
Infrastruktur beim Selbstbetrieb Server, Datenbank, Backup, Bandbreite Betriebsaufwand, Monitoring, Upgrades, Sicherheit
Prozessbetrieb Debugging, Wiederholungsläufe, Logspeicher unbeaufsichtigte Wiederholungen

Von diesen vier Blöcken ist das Cloud-Abo am sichtbarsten, die Modell-API am unberechenbarsten, die Infrastruktur beim Selbstbetrieb wird am häufigsten unterschätzt, und der Prozessbetrieb taucht in Budgets oft gar nicht auf. Für die Gesamtrechnung müssen alle vier zusammen betrachtet werden.

2. Cloud und Selbstbetrieb: nicht nur die Softwaregebühr zählen

Der Wert von n8n Cloud liegt darin, dass Deployment, Upgrades, Backups und Verfügbarkeit wegfallen; die Tarife staffeln sich üblicherweise nach Ausführungen, Mehrverbrauch erfordert ein Upgrade oder zusätzliches Kontingent. Das passt zu kleinen Teams ohne eigene Betriebsmannschaft, die schnell live gehen wollen.

Die selbst betriebene Community Edition lässt sich ohne Sitzungsgebühr installieren, aber „kostenlos“ beschreibt nur die Lizenz. Server, PostgreSQL, Redis im Queue-Modus, Objektspeicher, Backups, Monitoring, Logs, Sicherheitspatches und Upgrade-Fenster verursachen echte Kosten. n8n verwendet die Sustainable Use License (Fair-Code-Modell) mit zusätzlichen Einschränkungen für Weitergabe und das Anbieten gehosteter Dienste; vor kommerzieller Nutzung sollte der Lizenztext gelesen werden. Ohne Betriebskompetenz liegt die Gesamtrechnung des Selbstbetriebs häufig über den Erwartungen.

Eine einfache Entscheidungshilfe: Übersteigt der monatliche Zeitwert für die Instanzpflege die Preisdifferenz zum Cloud-Tarif, spricht das für Cloud. Müssen Daten im eigenen Netz bleiben, ist das Volumen hoch und verfügt das Team über Betriebskompetenz, lohnt sich die Prüfung von Selbstbetrieb.

3. Ausführungen: die am häufigsten unterschätzte Größe

n8n-Tarife sind meist um „Ausführungen“ herum aufgebaut. Ein Workflow-Lauf zählt in der Regel als eine Ausführung, doch der tatsächliche Verbrauch wird durch mehrere Faktoren vergrößert:

  • Polling-Trigger: Auch regelmäßige Prüfungen ohne neue Daten können Ausführungen erzeugen; maßgeblich sind die Regeln der aktuellen Version.
  • Schleifen und Sub-Workflows: Die Verarbeitung von Stapeldaten Satz für Satz oder die Auslagerung von Logik in Sub-Workflows erhöht die Läufe.
  • Fehler-Wiederholungen: Node-Retries und erneute Workflow-Läufe werden häufig erneut gezählt.
  • Debug-Läufe: Wiederholtes manuelles Ausführen im Editor verbraucht ebenfalls Kontingent.

Die Gegenmaßnahmen sind direkt: Webhooks statt Polling, Sammelverarbeitung statt Einzelauslösung, Deduplizierung am Eingang, sinnvolle Intervalle für Zeitpläne und zunächst ein einzelner Beispieldatensatz beim Debuggen.

Im Code-Node von n8n lässt sich der Modellverbrauch pro Aufruf mitsammeln, um ihn später abzugleichen:

// Token-Verbrauch eines Laufs sammeln (Feldnamen je nach tatsächlicher Antwort)
const usage = $json.usage ?? {};
const input = usage.prompt_tokens ?? 0;
const output = usage.completion_tokens ?? 0;

return [{ json: {
  input_tokens: input,
  output_tokens: output,
  total_tokens: input + output
  // Preise stehen auf der Preisseite; hier wird nur der Verbrauch erfasst
}}];

4. API-Nutzung nach Verbrauch: wohin die Tokens fließen

Die Rechnung der Modell-API ergibt sich aus Input und Output. Der Input ist nicht nur die Frage des Nutzers, sondern umfasst System-Prompt, Gesprächsverlauf, abgerufene Dokumente, Tool-Definitionen und Formatvorgaben; der Output wird nach generierter Länge abgerechnet. Drei häufige Verstärker:

  1. Wiederholter Kontext: Mehrere Gesprächsrunden tragen jeweils den Verlauf mit; bei langen Dialogen summiert sich der Input.
  2. Lange Dokumente im Prompt: Ein ganzer Vertrag oder eine vollständige Webseite im Prompt ist pro Aufruf teuer, bei Wiederholungen umso mehr.
  3. Retries und Varianten: Erneutes Senden nach einem Fehler oder paralleles Antworten mehrerer Modelle vervielfacht den Verbrauch.

Die übliche Optimierungsreihenfolge: zuerst Modellstufen festlegen – günstige Modelle für Klassifikation, Bereinigung und Zusammenfassung, starke Modelle für komplexe Generierung; dann den Kontext komprimieren und nur notwendige Felder übergeben; anschließend die Ausgabelänge begrenzen und strukturierte, knappe Antworten verlangen; erst zuletzt Caching prüfen. Einige Anbieter bieten Prompt-Caching für wiederkehrende Präfixe; Unterstützung und Rabatt richten sich nach deren Dokumentation.

5. Retries, Cache und versteckte Kosten

Retries sind in der Automatisierung notwendig, haben aber zwei Rechnungsfolgen: mehr Ausführungen und möglicherweise doppelt berechnete Modellanfragen. Ob fehlgeschlagene Anfragen berechnet werden, hängt vom Upstream-Anbieter ab und sollte nicht als kostenlos angenommen werden. Empfohlen sind zwei bis drei Versuche, exponentielles Backoff und Idempotenzprüfungen für Schreibvorgänge, damit Nachrichten oder Buchungen nicht doppelt entstehen.

Caching ist in zwei Ebenen zu betrachten. Auf Workflow-Ebene werden Ergebnisse zwischengespeichert, etwa bereits verarbeitete Datensätze übersprungen; auf Modellebene werden Präfixe gecacht, etwa feste System-Prompts und lange Dokumente. Das eine läuft über Datenbank oder Redis, das andere über den Modellanbieter; sie ersetzen einander nicht.

Häufig übersehen werden außerdem: Ausführungshistorie und Workflow-Logs belegen Datenbankspeicher; Bild-, Audio- und Transkriptionsaufrufe werden separat berechnet; ein Debug-Lauf über den gesamten Datenbestand kann schlagartig viele Ausführungen und Tokens erzeugen.

6. Budgetkontrolle: Limits, Alarme und Auswertung

Grenzen vorab setzen:

  • Pro Projekt oder Workflow eigene API-Keys vergeben, um Zuordnung und Abschaltung zu erleichtern.
  • Im Gateway ein Monatsbudget oder Nutzungslimit setzen und bei Annäherung alarmieren.
  • Die usage jedes Aufrufs in Tabelle oder Datenbank schreiben und nach Workflow aggregieren.
  • Für verbrauchsintensive Abläufe eigene Parallelitäts- und Retry-Grenzen definieren.
  • Monatlich die drei teuersten Workflows prüfen und auf doppelte Aufrufe untersuchen.
  • Eine Reserve für Geschäftswachstum und Preisänderungen einplanen.

Ein einheitliches OpenAI-kompatibles Gateway bündelt Keys, Verbrauch und Limits mehrerer Modellanbieter an einer Stelle; ein Modellwechsel erfordert dann keine Änderung der Workflows. Zum Testen können Sie sich registrieren; Modelle und Preise stehen auf den Modellpreisen.

7. Eine wiederverwendbare Schätzroutine

Nicht aus dem Bauch heraus kalkulieren, sondern in dieser Reihenfolge vorgehen:

  1. Einen repräsentativen Workflow wählen und 20 bis 50 echte Beispiele verwenden, keine künstlichen Testdaten.
  2. Monatliche Auslösungen zählen, einschließlich Zeitplan, Webhook, leerem Polling und manuellen Läufen.
  3. Aus den Antworten Input- und Output-Tokens pro Aufruf erfassen und Mittelwerte bilden.
  4. Mit einem Retry-Faktor multiplizieren, etwa 20 bis 50 Prozent Aufschlag entsprechend der historischen Fehlerquote.
  5. Cloud-Abo oder monatliche Kosten für Server, Datenbank, Backup und Logspeicher addieren.
  6. Den Personalaufwand für Instanzpflege und Fehlersuche in Geld umrechnen und ergänzen.
  7. Jedes Quartal erneut prüfen, da sich Tarifregeln, Modellpreise und Geschäftsprozesse ändern.

Ein Beispiel: Löst ein Workflow monatlich 10.000 Läufe aus, davon 30 Prozent mit Modellaufruf, bei durchschnittlich 2.000 Input- und 500 Output-Tokens, dann ergibt sich aus 3.000 Aufrufen mal 2.500 Tokens ein Volumen von rund 7,5 Millionen Tokens pro Monat. Dieses Volumen wird mit dem aktuellen Preis des gewählten Modells verrechnet. Die Preise stehen auf den Modellpreisen und sollten nicht aus älteren Artikeln übernommen werden.

Häufige Fragen

Wie werden die Ausführungen bei n8n Cloud gezählt?

In der Regel zählt jeder Workflow-Lauf als eine Ausführung; ob Polling, Retries und manuelle Läufe eingerechnet werden, hängt von den aktuellen Tarifregeln ab. Am sichersten ist es, die Verbrauchsseite des Kontos eine Woche zu beobachten und mit der eigenen Auslösefrequenz abzugleichen.

Ist selbst betriebenes n8n wirklich kostenlos?

Die Community Edition erhebt keine Sitzungsgebühr, aber Server, Datenbank, Backups, Monitoring und Betriebspersonal liegen bei Ihnen. Enterprise-Funktionen benötigen eine eigene Lizenz; vor kommerzieller Nutzung sollten außerdem die Einschränkungen der Sustainable Use License geprüft werden.

Warum liegt die Modellrechnung viel höher als geschätzt?

Häufige Ursachen sind wiederholter Kontext, Schleifen mit Einzelaufrufen, Fehler-Wiederholungen und Debug-Läufe über den gesamten Datenbestand. Zuerst das Verhältnis von Input zu Output in den Nutzungsdetails prüfen, dann kontrollieren, ob ein Workflow denselben Datensatz mehrfach verarbeitet.

Werden fehlgeschlagene Retries ebenfalls berechnet?

Die Ausführungen steigen in der Regel; ob die Modellanfrage berechnet wird, richtet sich nach den Regeln des Upstream-Anbieters. Empfohlen sind begrenzte Retries, protokollierte Ergebnisse je Anfrage und idempotente Schreibvorgänge.

Wie setzt man ein Budgetlimit für das Team?

API-Keys nach Projekt trennen, im Gateway Monatslimits und Alarme konfigurieren und die Nutzungslogs in interne Berichte übernehmen. Bei Auffälligkeiten zuerst den betroffenen Key deaktivieren und dann den konkreten Workflow lokalisieren.

Nächste Schritte

Die Kostenoptimierung bei n8n läuft auf zwei Punkte hinaus: unnötige Ausführungen vermeiden und die Tokens pro Modellaufruf begrenzen. Sind beide Größen quantifiziert, fällt die Entscheidung zwischen Cloud und Selbstbetrieb leichter. Für zentrale Verwaltung von Modell-Keys, Verbrauch und Budget können Sie mit der Registrierung im ZSQH AI Gateway beginnen; Preise entnehmen Sie den Modellpreisen.

Weiterlesen: