Notion Agents sind unglaublich leistungsstark. Und unglaublich leicht zu überbudgetieren. Mit Notion Credits, die am 4. Mai 2026 live gehen, hat jeder Custom-Agent-Run jetzt ein Preisschild – und wenn du noch Opus für jede einzelne Aufgabe einsetzt, verbrennst du buchstäblich Geld.
Ich betreibe Custom Agents in Kundenprojekten und unseren eigenen internen Workflows seit Monaten. Das sind die drei Prinzipien, die unsere KI-Kosten konstant um 60–80 % gesenkt haben – ohne Abstriche bei der Ausgabequalität. Plus zwei Bonus-Überlegungen, die dir vielleicht noch mehr sparen.
Welches Modell solltest du für deinen Notion Agent verwenden?
Wir haben alle ein Vorschlaghammer-Problem. Als Custom Agents in der Explorationsphase kostenlos waren, gab es keinen Grund, nicht das größte, beste Modell für jeden Job zu nehmen. Opus für alles. Warum nicht?
Weil Opus wahnsinnig teuer ist. Und jetzt, wo wir für Compute zahlen, lohnt es sich zu fragen: Braucht dieser Job wirklich die erfahrenste, bestbezahlte Person im Raum?
Hier ein kurzer Kostenvergleich für typische Agent-Aufgaben:
| Aufgabe | Opus-Kosten | Haiku-Kosten | Ersparnis |
|---|---|---|---|
| 10.000 Support-Tickets (routen & verarbeiten) | ~30 $ | ~6 $ | 80 % |
| Artikel zusammenfassen | Hoch | ~1/5 | 80 % |
| Rechnungsdaten extrahieren | Hoch | ~1/5 | 80 % |
| Klassifizierung & Formatierung | Hoch | ~1/5 | 80 % |
Haiku kostet ein Fünftel von Opus. Pauschal. Für Aufgaben wie Routing, Extrahieren, Klassifizieren und Zusammenfassen ist das eine Kostensenkung von 80 % – allein durch den Modellwechsel.
Natürlich kannst du nicht alles Haiku übergeben. Es ist ein weniger leistungsstarkes Modell. Die Entscheidung hängt davon ab, was der Job tatsächlich verlangt:
- Schweres Reasoning, kreative Komplexität, fortgeschrittene Analyse — Opus. Zahl die Prämie. Es lohnt sich hier.
- Mittleres Reasoning, strukturierte Aufgaben — Sonnet oder GPT 5.4. Deutlich günstiger als Opus. GPT 5.4 ist stark bei Reasoning-Aufgaben, hat aber weniger Persönlichkeit (nicht ideal für einen täglichen Assistenten, aber solide für logiklastige Hintergrundarbeit).
- Einfache Operationen: Formatierung, Klassifizierung, Extraktion, Zusammenfassung — Haiku, Gemini Flash oder Minimax. Perfekt für gezielte, wiederholbare Aufgaben.
Ein konkretes Beispiel: Unser Content-Link-Optimierer läuft jedes Mal, wenn wir einen Blogbeitrag veröffentlichen. Er prüft interne Links, platziert Affiliate-Referenzen und räumt die Formatierung auf. Fünf Runs diesen Monat. Gesamtverbrauch: 72 Credits. Ein einziger Opus-Run für einen Artikel würde mehr kosten als das.
Pro-Tipp: Setze das Modell explizit. Geh zu den Agent-Einstellungen → scrolle zu Erweitert → Modell. Lass es nie auf Auto. Auto bedeutet: der Agent entscheidet selbst, ob er Reasoning einsetzt – und das ist dein Job als Architekt. Entweder die Aufgabe rechtfertigt Opus-Level-Reasoning, oder nicht. Triff die Entscheidung.
Noch etwas zur Modellauswahl: Die Warnungen, die bei kleineren Modellen erscheinen (wie Prompt-Injection-Risiken), sind es wert, gelesen – aber nicht in Panik zu verfallen. Prompt-Injection ist nur dann ein echter Angriffsvektor, wenn dein Agent externe, unkontrollierte Inputs verarbeitet – eingehende E-Mails, Website-Formulare, öffentlich zugängliche Daten. Wenn er interne Sachen verarbeitet (ein Team-Slack-Kanal, eigene Datenbanken), ist das Risiko minimal. Spar das smartere Modell für den nach außen gerichteten Use Case auf.
Warum ein großer Agent mehr kostet als fünf kleine
Das ist die Erkenntnis, die die meisten überrascht. Einen Agent in fünf aufzuteilen reduziert tatsächlich deine Rechnung.
Die Falle: Du baust einen Agent, der einen gesamten Workflow abdeckt. Blog-Post-Erstellung zum Beispiel. Der Agent liest das Transkript, schreibt den Artikel, findet interne Links, generiert Bildkonzepte, schreibt SEO-Metadaten und übersetzt vielleicht auch noch. Weil der Schreib-Schritt fortgeschrittenes Reasoning erfordert, packst du alles auf Opus.
Jetzt läuft jeder Schritt auf Opus. Der Linking-Schritt, den Haiku in Sekunden erledigen würde? Opus. Die Metadaten-Extraktion? Opus. Die Übersetzung? Opus.
In einem monolithischen Agent bestimmt die komplexeste Teilaufgabe das Modell für alles.
Trenn es auf:
- Artikel schreiben → Opus (hier lebt das Reasoning)
- Interne Verlinkung → Haiku (Pattern Matching, einfache Lookups)
- Bildkonzepte → Sonnet (kreativ, aber strukturiert)
- SEO-Metadaten → Haiku (Extraktion und Formatierung)
- Übersetzung → Sonnet oder Haiku (je nach Komplexität)
Fünf Agents. Drei verschiedene Modell-Tiers. Deutlich niedrigere Gesamtkosten – weil vier von fünf Schritten keine Premium-Token mehr verbrennen.
Ja, du kannst solche Multi-Agent-Orchestrierungs-Flows in Notion heute aufbauen. Ich habe kürzlich ein vollständiges Tutorial dazu veröffentlicht.
Das Chaining funktioniert über Datenbank-Trigger: Agent A erledigt seinen Job und aktualisiert eine Property → Agent B triggert auf diese Änderung. Es ist kein direkter Agent-zu-Agent-Handoff – es ist System-Design. Und es funktioniert bemerkenswert gut.
Wie Progressive Context Disclosure deine Token-Rechnung senkt
Ein günstigeres Modell macht jeden Token billiger. Progressive Context Disclosure sorgt dafür, dass du von Anfang an weniger Token verwendest.
Der Standardansatz sieht so aus: Du schreibst einen riesigen Instruktionssatz, der jeden Edge Case, jede Bedingung, jedes Referenzdokument abdeckt. Der Agent liest alles. Dann startet er mit Schritt eins. Wenn er bei Schritt sieben angekommen ist, trägt er dieses enorme Kontext-Window mit sich – und jeder Schritt wird teurer durch das angesammelte Gepäck.
Progressive Context Disclosure dreht das um. Gib dem Modell nur so viel Kontext, wie es für den nächsten spezifischen Schritt braucht.
Drei Dinge passieren:
- Bessere Ausgabe. Der Agent ist fokussierter. Weniger Rauschen, weniger Ablenkungen, genauere Ergebnisse.
- Günstigere frühe Schritte. Wenn der vollständige Kontext z. B. 50.000 Token umfasst, Schritt eins aber nur 5.000 braucht – hast du gerade 90 % der Inputkosten für diesen Schritt gespart.
- Bedingtes Laden. Manche Kontexte sind nur gelegentlich relevant. Warum deine Affiliate-Link-Datenbank in jeden einzelnen Blog-Post-Run laden, wenn die Hälfte deiner Artikel kein externes Tool erwähnt?
Unser Link-Optimierer macht genau das. Schritt drei seiner Anweisungen lautet: Prüf, ob der Artikel irgendwelche Produkte erwähnt. Wenn ja, lade die Affiliate-Referenzseite. Wenn nicht, überspring sie. Die meisten Runs berühren diesen Kontext nie.
Multi-Agent-Architekturen erhalten diesen Vorteil automatisch. In unserer Content-Pipeline wird das Transkript – das mit Abstand längste Dokument – nur vom ersten Agent gelesen. Der Link-Optimierer, der Metadaten-Agent, der Übersetzer – sie lesen nur den fertigen Blogbeitrag. Viel kürzer. Viel günstiger.
Ein monolithischer Agent für denselben Workflow würde das gesamte Transkript durch jeden Schritt schleppen, das Kontext-Window aufblähen und bei jedem Schritt Token verbrennen.
Achte auch auf deine Output-Token
Das wird leicht übersehen. Output-Token sind bei allen Modellen deutlich teurer als Input-Token. Wenn dein Agent einen halbseitigen Bericht schreibt, wo du nur eine Statuszeile brauchst, die bestätigt, dass der Job erledigt ist – zahlst du für Wörter, die niemand liest.
Das kannst du nicht immer kontrollieren – ein Blog-Writing-Agent muss einen Blogbeitrag produzieren. Aber für Routing-Agents, Klassifizierungs-Agents, Datenextraktions-Agents? Sei explizit in deinen Anweisungen über Ausgabeformat und -länge. „Antworte mit dem Namen des zugewiesenen Owners und der Ticket-ID. Nichts weiter.” Diese Präzision summiert sich.
Braucht das überhaupt KI? Der Deterministic-Workflow-Check
Dieses Prinzip könnte deine KI-Rechnung am stärksten senken – weil die Antwort vielleicht lautet: „Gar keine KI.”
Deterministisch bedeutet: der Workflow folgt harten Regeln. Wenn das, dann das. Kein Urteilsvermögen nötig. Das ist kein Job für KI. Das ist ein Job für Code oder No-Code-Automatisierungen.
KI verdient ihren Preis, wenn du sie brauchst, um unordentliche, flexible, mehrdeutige Inputs zu verarbeiten – das weiche Reasoning, das früher einen Menschen erforderte.
Zwei Beispiele aus unseren eigenen Workflows:
Beispiel 1: Kontakt-Matching. Unser Meeting-Notes-Tool überträgt Kontakte nach Notion. Wir müssen jeden Kontakt einem Kunden in unserem CRM zuordnen. Ein Agent könnte das tun. Aber die Logik ist simpel: Prüf die E-Mail-Domain des neuen Kontakts → schau, ob ein Kunde diese Domain hat → wenn ja, verknüpfe sie. Das ist deterministisch. Domain-Matching. Kein Reasoning nötig. Eine einfache Automatisierung erledigt es perfekt.
Beispiel 2: Erinnerungen für Kundenkommunikation. Eines der Dinge, für das Kunden uns regelmäßig loben, ist proaktive Kommunikation. Wir haben das standardisiert: Jeder aktive Kunde hört alle 48 Stunden von uns – Montag, Mittwoch, Freitag. Ein Agent könnte uns erinnern. Aber wenn das Projekt aktiv ist und Montag ist, sollte die Erinnerung auslösen. Kein Urteil nötig. Code.
Das Muster: Wenn du die Entscheidung als If-Statement schreiben kannst, braucht es kein Sprachmodell.
Zwei wichtige Nuancen.
Bei Team-Rollouts: Starte trotzdem mit KI. Wenn du eine KI-Aktivierungskampagne durchführst und Teammitglieder mit Agents vertraut machst, lass sie KI-Flows auch für Dinge bauen, die deterministisch sein könnten. KI lernen hat in dieser Phase Priorität. Kostenoptimierung kommt nach der Vertrautheit.
Nutze KI, um deine deterministischen Flows zu bauen. Das ist der Verhaltens-Shift. KI muss keine KI-Workflows bauen. Beschreib deine Automatisierung in Notion, bitte deinen Agent, einen Automatisierungs-Prompt zu schreiben, füge ihn in ein Tool wie Relay ein – und KI baut den deterministischen Flow für dich. Fünf Minuten. Keine stundenlangen Konfigurationssessions. Die Automatisierung läuft ohne KI-Token. Das Beste aus beiden Welten.
Sollte das ein Skill statt ein Custom Agent sein?
Noch etwas. Vieles, was ich aktuell als Custom Agents gebaut sehe, sollte gar kein Agent sein. Es sollte ein Skill für deinen persönlichen Agent sein.
Die aktuelle Realität: Dein persönlicher Agent – der in deiner Sidebar – ist in deinem Plan inbegriffen. Kostenlos. Du kannst ihn den ganzen Tag auf Opus 4.6 laufen lassen. Custom Agents kosten Credits.
Die entscheidende Frage für jeden Custom Agent lautet also: Muss das ohne mich laufen?
Drei Checks:
| Frage | Ja → Agent | Nein → Skill |
|---|---|---|
| Gibt es einen zuverlässigen, wiederkehrenden Trigger? | E-Mail erhalten, Status geändert, jeden Montag 9 Uhr | Du startest es sowieso manuell aus dem Chat |
| Entfällt deine Aufmerksamkeit vollständig? | Ticket-Routing: niemand überwacht den Kanal mehr | Du musst trotzdem reviewen, copy-pasten oder genehmigen |
| Ermöglicht es Skalierung? | Du kannst jetzt das 10-fache Volumen bewältigen | Du machst dasselbe Volumen, nur etwas schneller |
Mein größtes Red Flag: Jemand baut einen Custom Agent und nutzt ihn dann über das Chat-Interface. Mit sehr wenigen Ausnahmen (Permission-Isolation, team-geteilte Workflows) sollte das ein Skill sein. Du sitzt sowieso schon vor dem Computer. Du triggerst die Aufgabe sowieso. Lass es durch deinen persönlichen Agent auf Opus kostenlos laufen.
Ein echtes Beispiel. Ich ziehe meine LinkedIn-Posts wöchentlich in Notion und habe einen Skill, der sie für Cross-Posting zu Medium umformatiert. Das könnte ein Agent sein – es ist eine regelmäßige Aufgabe. Aber ich muss das Ergebnis trotzdem manuell in Medium einfügen, weil die kein API haben. Ob die Seite vorformatiert ist, wenn ich ankomme, oder ich den Skill starte und 10 Sekunden warte – das ist ein Unterschied von zwei Minuten. Und ich gebe sowieso Aufmerksamkeit.
Wenn es end-to-end ohne mich liefe? Auto-formatiert und auto-veröffentlicht? Jeden Credit wert. Aber bis dieser letzte Schritt automatisiert ist, spart mir der Skill die Token.
Das Crawl-Walk-Run-Prinzip gilt auch hier. Starte mit Skills. Gewöhne dich daran, wie KI deine Workflows bewältigt. Bau Vertrauen in die Ausgabequalität auf. Dann überführe die bewährten, hochvolumigen, wirklich autonomen Flows zu Custom Agents – und zahle für Credits in dem Wissen, was du bekommst.
Ich bin leicht 10-mal produktiver als noch vor einem Jahr. Aber ich merke auch, dass mein menschliches Kontext-Window – die Anzahl paralleler KI-Threads, die ich im Kopf halten kann – seine Grenzen erreicht. Der nächste Produktivitätssprung kommt also nicht von mehr Skills. Er kommt von den richtigen Agents, die die richtigen Jobs autonom erledigen. Starte mit Notion Consulting, um deine eigenen KI-Workflows aufzubauen. Das Schlüsselwort: richtig.
Häufig gestellte Fragen
Wie ändere ich das Modell bei meinem Notion Custom Agent?
Öffne die Einstellungen deines Agents, scrolle ganz nach unten unter Erweitert und wähle Modell. Wähle das spezifische Modell, das zur Aufgabenkomplexität passt. Vermeide die Auto-Einstellung – sie lässt den Agent entscheiden, wann er Reasoning einsetzt, was dir die Kontrolle über Kosten und Verhalten nimmt.
Ist Haiku gut genug für Notion Agents in der Produktion?
Für gezielte, wiederholbare Aufgaben – absolut. Haiku erledigt Klassifizierung, Formatierung, Datenextraktion, Routing und Zusammenfassung zuverlässig. Es kostet ein Fünftel von Opus. Die Faustregel: Wenn die Aufgabe kein kreatives Reasoning oder komplexe mehrstufige Logik erfordert, macht Haiku (oder Gemini Flash oder Minimax) den Job.
Wie funktionieren Notion Credits für Custom Agents?
Notion Credits kosten 10 $ pro 1.000 Credits, werden workspace-weit geteilt und setzen monatlich ohne Übertrag zurück. Der Credit-Verbrauch hängt vom verwendeten Modell, der verarbeiteten Kontextmenge, der Anzahl der Tool-Calls und der Anzahl der Schritte ab. Einfachere Agents auf kleineren Modellen verbrauchen weniger Credits pro Run.
Was ist der Unterschied zwischen einem Notion-Skill und einem Custom Agent?
Ein Skill ist ein wiederverwendbarer Instruktionssatz, der über deinen persönlichen Agent läuft – der in deinem Plan ohne Zusatzkosten inbegriffen ist. Ein Custom Agent läuft autonom auf Triggern und kostet Notion Credits. Nutze Skills für Aufgaben, die du manuell triggerst. Nutze Agents für Aufgaben, die ohne deine Aufmerksamkeit laufen müssen.
Kann ich mehrere Notion Agents miteinander verketten?
Ja. Agents können sich nicht direkt aufrufen, aber du kannst sie über Datenbank-Trigger verketten. Agent A erledigt seine Aufgabe und aktualisiert eine Property oder erstellt eine Seite → Agent B triggert auf diese Änderung. So funktioniert Multi-Agent-Orchestrierung in Notion heute. Hier ist ein vollständiges Walkthrough, wie du das einrichtest.
