Notion Custom Agents: $340/Monat – Kosten deckeln oder neu bauen?

Am 3. Mai kosteten mich meine Notion Custom Agents $0. Am 4. Mai verbrauchten dieselben Agenten plötzlich Credits, abgerechnet mit $10 pro 1,000. Die erste Hochrechnung für mein Client OS lag bei rund $340/Monat – sofern ich nichts änderte.

Als der Zähler anlief

Während der zweiten Hälfte der kostenlosen Beta hatte ich Notion Custom Agents in einem produktiv genutzten Workspace für Kundenprozesse betrieben – dem DVNC Client OS. Ein Triage-Agent las eingehende Briefings, ein täglicher Digest-Agent fasste den Stand aller laufenden Mandate zusammen, und ein Doc-Sync-Agent hielt einige gemeinsam genutzte Wissensdatenbanken mit den maßgeblichen Seiten synchron. Drei ständig aktive Agenten, ergänzt um einige ereignisgesteuerte. Kostenposten: null.

Am 4. Mai 2026 stellte Notion den Zähler an. Aus der kostenlosen Beta der Custom Agents wurde die verbrauchsabhängig abgerechnete General Availability: $10 pro 1,000 Notion Credits, zusätzlich zum Sitzplatzabonnement und ausschließlich in den Tarifen Business und Enterprise. Ein Downgrade, bei dem die Agenten erhalten bleiben, gibt es nicht – Plus und Free boten Custom Agents von Anfang an nicht. Die vermeintliche Option, „für das Feature eine Tarifstufe herunterzugehen“, existiert also nicht. Entweder läuft die nutzungsabhängige Abrechnung unter Business+ oder das Feature entfällt vollständig.

In den ersten 48 Stunden nach der Umstellung ließ ich die Agenten bewusst unverändert weiterlaufen. Ich wollte reale Verbrauchsdaten statt einer Hochrechnung. Ein Operator, dem ich folge, nannte öffentlich einen Wert von rund $337 in einem einzigen Monat bei einem vergleichbaren Setup. Das lag so nah an meiner eigenen 30-Tage-Prognose, dass ein Konfigurationsfehler als Ursache ausschied. Dieser Verbrauch war die neue Untergrenze.

Genau das übersehen die meisten Zusammenfassungen zur Preisänderung. Der 4. Mai brachte keine gewöhnliche Preiserhöhung. Bei einer Preiserhöhung steigt ein Posten etwa von $40 auf $55, und das Budget wird angepasst. Hier wechselte ein kostenloses Angebot in ein Verbrauchsmodell – eine grundsätzlich andere Situation. Sämtliche Kostenannahmen, auf denen Konfiguration, Zeitpläne und Umfang der Agenten beruhten, waren plötzlich falsch, denn alle Entscheidungen waren unter der Prämisse „Credits kosten nichts“ gefallen. Die erste Aufgabe bestand nicht darin, Ausgaben zu kürzen. Der Workflow musste ausgehend von einer Prämisse neu hergeleitet werden, die nicht mehr galt. Auf Entwicklerseite hatte Notion bereits früher im Jahr etwas strukturell Ähnliches getan (siehe den Credit-Einbruch für externe Agenten). Das Muster war also erkennbar – nur bezahlt dieses Wissen noch keine Rechnung.

Wo Notion Custom Agents die meisten Credits verbrauchten

Der erste wirklich hilfreiche Schritt war, den Verbrauch je Agent zu erfassen: Die Notion-Oberfläche zeigt zwar den Credit-Verbrauch auf Workspace-Ebene, liefert standardmäßig aber keine übersichtliche Aufschlüsselung nach Agent. Credits werden im Workspace gemeinsam genutzt und monatlich zurückgesetzt. Das klingt zunächst neutral, bedeutet in der Praxis jedoch, dass ein verschwenderischer Agent unbemerkt jeden anderen KI-Workflow im selben Workspace mitbelastet.

Drei Agenten verursachten rund 70% des Verbrauchs. Nicht fünf, nicht acht. Drei.

Mit deutlichem Abstand am teuersten war der Triage-/Intake-Agent, der eine gemeinsame Eingangsseite abfragte und neue Briefings klassifizierte. Er war darauf eingestellt, alle 15 Minuten zu prüfen – 24/7. In den meisten Läufen gab es nichts Neues, Credits kostete jeder Durchlauf trotzdem. Leere Abfragen unveränderter Daten sind die Falle. Der Agent tat exakt, was ich ihm aufgetragen hatte. Nur war dieser Auftrag ab dem Moment teuer, in dem der Zähler anlief.

Der tägliche Kunden-Digest war der zweitgrößte Posten. Pro aktivem Mandat und Tag lief er einmal; damit vervielfachte sich der Tageslauf über die gesamte Liste aktiver Kunden. Die Kosten eines einzelnen Laufs waren vertretbar, problematisch war die Menge. Ein vernünftiger Wert pro Lauf, multipliziert mit der Zahl der Mandate und 30 Tagen, ergab allein schon mehr als sämtliche Notion-Sitzplätze im Vormonat zusammen.

Der Doc-Sync-Agent belegte Platz drei und war zugleich der interessanteste Fall. Pro Lauf war er der günstigste der drei, ausgelöst wurde er jedoch durch Bearbeitungen. Eine einzige menschliche Sitzung an einer gemeinsam genutzten Seite konnte ihn ein Dutzend Mal starten. Sein Verbrauch war damit faktisch an die Tippgeschwindigkeit eines Menschen gekoppelt – eine Konfiguration, die bei $10 pro 1,000 Credits niemand bewusst wählen würde.

Die grobe Monatsrechnung, rekonstruiert aus den ersten zehn Tagen nach der Umstellung und anschließend hochgerechnet, sah so aus: Triage-Agent bei seiner damaligen Abfragefrequenz: ~$160/Monat. Digest-Agent beim aktuellen Mandatsbestand: ~$95/Monat. Doc-Sync bei der beobachteten Bearbeitungsmenge: ~$45/Monat. Die restlichen ~$40/Monat verteilten sich auf vier kleinere Agenten. Insgesamt ergab sich eine Spanne von $335–$345 – passend zu dem öffentlich genannten Wert eines anderen Operators mit ähnlich aufgebautem Workspace.

Dieser Betrag käme auf einen Operations-Stack obendrauf, über den ich bereits geschrieben habe – siehe die Basis von $387/Monat. Ein zusätzlicher Posten von $340 hätte den gesamten Stack über eine Grenze geschoben, die ich ausdrücklich festgelegt hatte. Das war kein „kleiner Aufpreis, den man eben schluckt“, sondern ein strukturelles Problem.

Drei Optionen: weiterzahlen, begrenzen oder neu bauen

Drei Wege, jeweils mit belastbaren Zahlen – und nur einer passte zu meinem konkreten Workload. Bei anderen Workloads führen dieselben Zahlen zu einer anderen Entscheidung. Genau deshalb lohnt sich die Rechnung mehr als jede pauschale Empfehlung.

Option A – vollständig im Verbrauchsmodell bleiben und nichts ändern. Das ist richtig, wenn wenige Läufe jeweils hohen Wert schaffen und planbare Rechnungen weniger wichtig sind als die absolute Kostenkontrolle. Für einen Workspace mit wenigen, aber wertvollen Agentenläufen pro Tag kann das Verbrauchsmodell gut funktionieren – etwa wenn ein klar abgegrenzter Output einem Menschen eine Stunde Arbeit erspart. Der Preis von $10 pro 1,000 Credits ist nicht das eigentliche Ärgernis. Problematisch sind Agenten, deren Rechnung bei keinem Preis pro Lauf aufgeht. Für diesen Workspace hätte meine Obergrenze bei rund $80/Monat gelegen, gemessen an seinem Nutzen. Die Prognose war viermal so hoch. Option A schied aus.

Option B – begrenzen und neu zuschneiden. Ständige Abfragen abschalten. Agenten statt in festen Intervallen nur durch Ereignisse oder manuell auslösen. Den Digest-Agenten von einem Lauf je Mandat auf einen gebündelten Tageslauf umstellen, der genau eine Gesamtausgabe erzeugt. Den Doc-Sync-Agenten entprellen, sodass er einmal pro Bearbeitungssitzung statt nach jeder Änderung startet. Nach diesem Zuschnitt lag die Prognose bei rund $70–$85/Monat – unterhalb der Obergrenze, mit denselben wesentlichen Ergebnissen, aber einem spürbaren Verlust an „Sofortigkeit“ im Triage-Prozess. Der Triage-Agent läuft nun alle zwei Stunden statt alle fünfzehn Minuten. Diese Verzögerung ist ein echter Produktnachteil, der ehrlich bewertet werden musste.

Option C – auf eigener Infrastruktur neu bauen. Den schwersten Agenten – Triage – aus Notion herauslösen: ein Cloudflare Worker mit Cron-Job, der Claude direkt aufruft und die Ergebnisse über die API auf die Notion-Seite zurückschreibt. Einmaliger Aufwand: rund 6–8 Stunden konzentrierte Arbeit für jemanden, der Systeme dieser Art schon gebaut hat – wie ich. Laufende Kosten: der ohnehin bezahlte Worker-Tarif plus Claude-API-Tokens im niedrigen einstelligen Dollarbereich pro Monat bei diesem Volumen. Gründer betreiben vergleichbare selbst gehostete Agenten-Stacks öffentlich. Sobald die Zahl der Läufe den Break-even überschreitet, geht die Rechnung auf.

Entscheidend ist allein die Break-even-Rechnung. Beim Laufvolumen meines Triage-Agenten kostete Notions Verbrauchsmodell ~$160/Monat. Auf eigener Infrastruktur lagen die laufenden Kosten bei ~$4/Monat. Wird der Bauaufwand über 12 Monate verteilt und die eigene Zeit großzügig mit $150/Stunde angesetzt, kommen im ersten Jahr ~$100/Monat hinzu. Damit kostet der Neubau im ersten Jahr insgesamt ~$104/Monat statt ~$160/Monat im Verbrauchsmodell. Ab dem zweiten Jahr stehen ~$4/Monat und ~$160/Monat gegenüber. Der Neubau amortisiert sich noch im ersten Jahr, danach wächst der Vorteil weiter.

Dieselbe P&L-Disziplin, die ich beim Codex-Angebot angewandt habe, greift auch hier – nur von der anderen Seite betrachtet. Damals ging es darum, ob sich ein Toolwechsel wegen eines kostenlosen Anreizes lohnt. Diesmal war zu entscheiden, ob ein Neubau rund um ein Tool nötig wird, dessen wirtschaftliche Grundlage sich nachträglich verändert hat. Derselbe Rahmen, entgegengesetzte Richtung.

Meine tatsächliche Entscheidung: ein Hybridmodell. Den Triage-Agenten als Worker neu bauen (Option C, nur für den größten Einzelposten). Digest und Doc-Sync begrenzen und neu zuschneiden (Option B für das Mittelfeld). Die vier kleineren Agenten vollständig im Verbrauchsmodell belassen (Option A für den Long Tail).

Die prognostizierten laufenden Monatskosten des Hybridmodells liegen nach Fertigstellung des Neubaus bei $45–$55, hinzu kommt einmalig ein Zeitaufwand von rund 7 Stunden. Gegenüber der unveränderten Prognose von $340 spart das ungefähr $290/Monat – zum Preis eines konzentrierten Arbeitseinsatzes. Die Kostenlinie nach 30/60/90 Tagen: Im ersten Monat fallen die Neubauzeit und ein Teil der Verbrauchskosten an ($110 tatsächliches Kostenäquivalent einschließlich Zeit), im zweiten Monat wird nahezu der stabile Zustand erreicht ($55), im dritten Monat der stabile Zustand ($45).

Was ich heute anders machen würde – und was mir ein wenig unangenehm ist: Ich hätte den Credit-Verbrauch je Agent vom ersten Beta-Tag an messen sollen, nicht erst nach dem Start der Abrechnung. Die Beta war genau das kostenlose Zeitfenster, in dem sich die späteren Kosten jedes Agenten präzise hätten erfassen lassen. Notion hatte die Credit-Sätze lange im Voraus veröffentlicht, trotzdem behandelte ich „kostenlos“ wie „muss nicht gemessen werden“. Die nachträgliche Rekonstruktion des Verbrauchs pro Agent dauerte länger, als eine laufende Messung gekostet hätte. Diese Regel gilt für mich inzwischen überall.

Die Regel vor jeder Notion-Automatisierung mit Dauerbetrieb

Die Lehre lautet nicht: „Notion Custom Agents sind zu teuer.“ Einige meiner Agenten laufen weiterhin als Custom Agents und werden das auch künftig tun. Die engere und nützlichere Erkenntnis ist: Kostenlose Beta-Automatisierung ist ein Risiko im Abhängigkeitsgraphen, kein Feature.

Bietet ein Anbieter in der Beta eine Automatisierung ohne Verbrauchsabrechnung an, entsteht eine kostenlose Option, den eigenen Workflow an ein noch gar nicht vorhandenes Preismodell zu koppeln. Sobald dieses Modell eingeführt wird, bleiben nur zwei Wege: die tatsächlichen Verbrauchskosten akzeptieren oder unter Zeitdruck neu bauen. Günstig ist diese Arbeit vor dem Start des Zählers, nicht danach.

Diesen Test durchläuft bei mir inzwischen jede kostenlose Beta-Automatisierung, bevor sie Teil eines kritischen Prozesses wird:

1. Die Verbrauchsversion kalkulieren, bevor es den Zähler gibt. Hat der Anbieter noch keine Preise veröffentlicht, hilft ein plausibles Modell anhand vergleichbarer Produkte. Dann lässt sich prüfen, ob sich der Agent weiterhin rechnet.
2. Kosten pro Lauf vom ersten Tag an messen. Die kostenlose Phase ist ein Messfenster, kein Freifahrtschein.
3. Den Weg zum Neubau kennen, bevor er gebraucht wird. Es muss klar sein, welche Agenten bei veränderter Wirtschaftlichkeit auf eigener Infrastruktur neu gebaut würden und wie viele Stunden dieser Bau ungefähr kostet.
4. Dauerbetrieb auf das langsamste noch akzeptable Intervall begrenzen. Reicht eine Abfrage alle 2 Stunden, sollte sie nicht nur deshalb alle 15 Minuten laufen, weil es technisch möglich ist. Die Frequenz ist ein Kostenregler: In der Beta lässt er sich kostenlos herunterdrehen. Später wird das teuer, weil Menschen ihre Gewohnheiten dann bereits an das schnellere Tempo angepasst haben.

Das Hybridmodell für das Client OS ist nicht elegant. Drei unterschiedliche Kostenmodelle parallel in einem Workspace bedeuten mehr Konfigurationsaufwand, als ich bei einem Neubau vorsehen würde. Es bildet jedoch die tatsächliche Arbeitsstruktur ab und bringt die Monatskosten wieder unter die Grenze, die für diesen Workspace schon vor dem Start des Zählers feststand. Nur dieser Test zählt.

Kostenlose Beta-Automatisierung ist ein Risiko, kein Feature. Sie sollte kalkuliert werden, bevor sie fest in Abläufe eingebaut wird – andernfalls folgt der Neubau später unter Druck.

Was kosten Notion Custom Agents seit dem 4. Mai 2026?

$10 pro 1,000 Notion Credits, zusätzlich zum Abonnement abgerechnet. Verfügbar ausschließlich in den Tarifen Business und Enterprise – Free und Plus enthielten Custom Agents nie.

Kann ich Custom Agents im Plus-Tarif behalten, um Credits zu vermeiden?

Nein. Custom Agents waren nie Bestandteil von Free oder Plus. Es gibt daher kein Downgrade, bei dem sie erhalten bleiben. Entweder gilt unter Business+ die Verbrauchsabrechnung oder das Feature entfällt.

Was passiert, wenn einem Workspace die Credits ausgehen?

Custom Agents stoppen. Andere Features von Notion AI wie Meeting Notes und der reguläre Notion Agent funktionieren bis zum Fair-Use-Limit des zugrunde liegenden Tarifs weiter.

Ist es günstiger, Agenten auf eigener Infrastruktur neu zu bauen?

Erst ab einem bestimmten Break-even beim Laufvolumen. Darunter ist die Abrechnung nach Credits günstiger als die Stunden für Bau und Wartung. Darüber – besonders bei ständig aktiven Agenten mit vielen Läufen pro Tag – wächst der Vorteil eigener Infrastruktur ab dem zweiten Jahr.