Meine Bulk Content Engine pausiert und läuft jetzt jederzeit weiter, weil der Orchestrator seinen Kontext selbst pflegt — plus RAG-Tags pro Aufgabe. — Heute habe ich an meiner Bulk Content Engine zwei Dinge gebaut, die zusammen einen größeren Unterschied machen, als sie einzeln klingen: Der Orchestrator führt seinen Kontext jetzt selbst, und die Aufträge lassen sich mit indexiertem Wissen über RAG-Tags verknüpfen. Die Bulk Content Engine ist der Teil meines Systems, der Content in Serie produziert — eine Tabelle voller Briefings rein, fertige Texte raus, Row für Row, mit beliebig vielen Agenten parallel. Der Orchestrator ist die Instanz darüber: Er verteilt die Arbeit an die Subagenten und hält den Überblick, wo die Produktion gerade steht. Der Orchestrator pflegt seinen Kontext selbst Bisher war eine laufende Pipeline ein Stück weit ein Alles-oder-nichts: einmal angestoßen, lief sie durch, und ein Abbruch zwischendrin bedeutete, den Faden zu verlieren. Das habe ich umgedreht. Der Orchestrator aktualisiert seinen Kontext jetzt von selbst — immer dann, wenn ein Meilenstein erreicht ist. Er schreibt also fest, was bis hierhin passiert ist, bevor er weitergeht. Der praktische Effekt: Du kannst die Pipeline an jeder beliebigen Stelle pausieren und später weiterlaufen lassen. Nicht weil ich eine Pause-Taste eingebaut hätte, sondern weil der Zustand nie nur im flüchtigen Arbeitsspeicher eines einzelnen Laufs steckt. Der Kontext trägt, wo die Produktion steht, also kann sie jederzeit dort wieder ansetzen. Das nimmt der Serienproduktion die Zerbrechlichkeit — eine lange Strecke ist kein einziger Atemzug mehr, den man nicht unterbrechen darf. RAG-Tags: indexiertes Wissen gezielt andocken Das zweite Stück ist die Verknüpfung mit meinem Wissen. Über Jahre habe ich eine durchsuchbare Wissensbasis aufgebaut — Tonalität, Fachwissen, Projektkontext, alles indexiert und über RAG (Retrieval-Augmented Generation) abrufbar. RAG heißt: Statt der KI alles auf einmal zu geben, holt sie sich bei jeder Aufgabe gezielt die relevanten Stücke aus dieser Basis. Neu ist, dass ich genau dieses Wissen jetzt pro Aufgabe andocke. Ich setze RAG-Tags an einem Auftrag, und damit ist definiert, welcher Teil meiner Wissensbasis in diese konkrete Produktion einfließt. Der Orchestrator gibt das an seine Subagenten weiter — sie arbeiten also nicht aus dem Nichts, sondern mit dem Wissen, das ich ihnen für genau diese Aufgabe mitgeben wollte. Das ist der Unterschied zwischen einem Agenten, der allgemein gute Texte schreibt, und einem, der in meiner Stimme über meine Themen schreibt, mit meinen Fakten. Ein paar Tags entscheiden darüber, und das macht die Ergebnisse um ein Vielfaches näher an dem, was ich tatsächlich brauche. Warum beides zusammengehört Einzeln sind das zwei Features. Zusammen sind sie ein System, das man laufen lassen kann, ohne danebenzustehen: Der Kontext sorgt dafür, dass nichts verlorengeht, wenn du unterbrichst — die RAG-Tags sorgen dafür, dass das, was läuft, von Anfang an das richtige Wissen trägt. Genau dafür baue ich die Engine: Content in Serie produzieren zu lassen soll so verlässlich sein, dass die Entscheidung bei mir liegt — welches Wissen, welche Tonalität, welche Themen — und die Ausführung sich selbst trägt.
Bei agy headless wird --model still ignoriert, wenn es nach -p steht. Die nirgends dokumentierte Lösung: --model muss vor -p kommen. — Ich wollte Googles () headless in eine Auto-Execution-Pipeline einbinden. Die Idee war simpel: pro Run ein gezielt ausgewähltes Modell über , alles non-interaktiv über /, Ausgabe einsammeln, weiterverarbeiten. Der erste Aufruf sah harmlos aus: Die Antwort: Gemini 3.5 Flash. Also der Default — nicht das Modell, das ich angefordert hatte. Egal welchen String ich in schrieb, fiel jedes Mal auf das Standardmodell zurück. Kein Fehler, keine Warnung, nichts. Zwei Stunden später kannte ich den Grund, und er steht in keiner Doku. Der Reihe nach. Schritt 1: Die Modellnamen sind keine Slugs Mein erster Verdacht: falscher Modellname. brachte Klarheit — und eine Überraschung. Die CLI listet Modelle als Display-Namen mit Reasoning-Level in Klammern, nicht als technische Slugs: Wichtig: Es gibt kein separates - oder . Der ist Teil des Modell-Strings. Meine Slug-Varianten — , , — führten alle zum Fallback. Nur der exakte Display-Name mit Klammer wurde im interaktiven Modus übernommen, sichtbar an der Statuszeile unten rechts. Schon das ist nirgends sauber dokumentiert. Schritt 2: Frag das Modell nicht, wer es ist Mit dem korrekten Namen bewaffnet, der nächste Headless-Test: Antwort: I'm running on the GPT-OSS 120B (Medium) model. Das war auf zwei Ebenen lehrreich. Erstens: wurde wieder ignoriert — der Default war diesmal offenbar ein anderer, aber jedenfalls nicht mein angefordertes Modell. Zweitens, und das ist die eigentliche Falle: Der Self-Report eines Modells ist als Identitätsbeweis wertlos. Modelle kennen ihren exakten Namen oft nicht zuverlässig und . Wer headless arbeitet, kann sich darauf nicht verlassen. Verlässlich ist nur die Statuszeile im interaktiven Modus oder ein Log-Check auf den echten API-Call: setzen und auf bzw. den Modellnamen greppen. Was das Modell über sich selbst sagt, ist Rauschen. Schritt 3: Es ist die Reihenfolge der Flags Der Durchbruch kam beim stumpfen Durchprobieren: Ich vertauschte die Flags am selben Modell. Und plötzlich stimmte das Ergebnis. Das ist der Moment, in dem die Reihenfolge klickt — und alles vorher zur Fußnote macht. muss vor stehen. Steht zuerst, schluckt der Print-Modus die nachfolgende Modellangabe und fällt still auf den Default zurück — Exit-Code 0, keine Meldung. Ich habe das über alle acht Modelle der Liste gegengeprüft: Sobald vor steht, kommt jedes Mal das korrekte Ergebnis zurück. Das funktionierende Muster Die Konstellation, die ich jetzt in der Pipeline fahre, ist genau eine Zeile: Konkret, für drei der Modelle: Drei Stolperfallen, die mich sonst noch erwischt hätten Mit der Flag-Reihenfolge ist das Hauptproblem gelöst, aber für unbeaufsichtigte Runs gibt es drei weitere Punkte, die ich gleich mit eingeplant habe. Non-TTY-stdout-Drop. In Pipes, Subprozessen oder CI kann die Antwort still verschlucken — Exit-Code 0, aber leerer stdout (dokumentiert als GitHub Issue #76). Wer als Subprocess captured, braucht ein Pseudo-TTY: . Namens-Stabilität. Die Display-Strings können sich zwischen -Versionen ändern. Statt Namen hart zu verdrahten, parse ich vor jedem Run einmal und ziehe den passenden String dynamisch. API-Key-Pfade. wird in manchen Pfaden ignoriert. Für CI setze ich bzw. . Fazit Die zentrale, nirgends dokumentierte Regel: vor . Dazu drei Leitplanken — Display-Name mit Klammer statt Slug, Log statt Self-Report, Pseudo-TTY gegen den stdout-Drop. Damit läuft bei mir headless zuverlässig. Der Sinn der ganzen Fummelei: ist nur eine Engine in einer , die mehrere headless laufen lässt und ihre Ergebnisse gegeneinander antreten lässt. Die OpenAI-Modelle habe ich bewusst ausgeklammert; die teste ich separat und reiche das Ergebnis nach.
Drei KIs deployten parallel Edge Functions ohne Abstimmung. Der deterministische Workflow, den ich danach baute — warum atomares Claiming der Kern ist. — Ich lasse . Das spart Zeit, solange sich die Arbeitsbereiche nicht überschneiden. Bei Edge Functions haben sie sich überschnitten — und das hat mich mehr Stunden gekostet, als mir lieb ist. Der Auslöser war unspektakulär. Drei KIs arbeiteten gleichzeitig am selben Themengebiet, und alle drei fassten dabei Edge Functions an. Sie committeten parallel, teilweise ohne das klar zu melden. Was dabei entstand, war Drift. Drift heißt: Mehrere Stände, die eigentlich übereinstimmen sollten, laufen unbemerkt auseinander. Hier waren es drei — der Stand im Repo, der Stand in der Datenbank und das, was die einzelne KI für den aktuellen Stand hielt. Jeder Commit ohne Abgleich vergrößert die Lücke. Bei normalem Anwendungscode merkt man so etwas schnell. Bei Edge Functions, die eng an Migrationen hängen, merkt man es erst, wenn etwas nicht mehr deployt oder sich seltsam verhält. Edge Functions sind migrationskritisch — das war mir nicht präsent Das ist der eigentliche Lerneffekt. Ich hatte Edge Functions im Kopf als Code, der irgendwo läuft — entkoppelt, harmlos, parallelisierbar. Tatsächlich hängen sie bei mir am Migrationsstand der Datenbank, und wenn mehrere Akteure gleichzeitig daran arbeiten und deployen, ohne den aktuellen Stand zu kennen, überschreibt einer die Annahmen des anderen. Das Tückische war nicht der Fehler selbst, sondern die Suche danach. Wir hatten zu dem Zeitpunkt schon einiges umgebaut. Es hätte alles sein können. Genau das frisst Zeit: nicht das Beheben, sondern das Eingrenzen, wenn die Ursache hinter zwanzig anderen Änderungen liegt. Dass ich es trotzdem zügig finden und einkreisen konnte, lag daran, dass ich beim Durchgehen die Parallelität als Muster erkannt habe — drei Akteure, eine Ressource, kein Abgleich. Die Lösung: ein deterministischer Workflow mit echtem Gate Ich habe daraufhin einen Workflow gebaut, der dieses Muster strukturell unmöglich macht. Vier Bausteine. Erst den Stand holen, dann arbeiten. Bevor eine KI eine Edge Function anfasst, zieht sie den aktuellen Stand aus der Datenbank und arbeitet gegen diesen Stand — nicht gegen ihre Annahme von vor zehn Minuten. Das allein nimmt dem Drift die Grundlage. Ein vor dem Deploy. Kein Edge-Function-Deployment passiert mehr stillschweigend. Vor dem Deploy steht eine explizite Rückfrage: Soll das jetzt wirklich deployt werden? Ich werde informiert und bekomme an dieser Stelle echte Entscheidungspunkte, statt nach dem Commit vor vollendeten Tatsachen zu stehen. Atomares Claiming über eine fortlaufende Nummer. Das ist der Kern. Wer an einer Edge Function arbeiten will, muss sich in der Tabelle eine Nummer ziehen. Pro Nummer kann nur genau eine Row geclaimt werden. Ist die Nummer vergeben, zieht man die nächste. Damit ist physisch ausgeschlossen, dass zwei Akteure denselben Slot belegen — und nebenbei sieht jeder sofort, ob gerade etwas parallel läuft oder ob die Bahn frei ist. Jeder Schritt ist prüfbar. Der Ablauf ist deterministisch zerlegt. Ich kann an jedem einzelnen Schritt nachsehen, was passiert ist und warum — statt am Ende ein Ergebnis zu haben, dessen Zustandekommen ich nicht mehr rekonstruieren kann. Was ich mitnehme Der teure Teil war nicht der Bug. Der teure Teil war, dass drei kompetente Akteure ohne Koordination an derselben kritischen Ressource arbeiteten — und dass ich die Ressource für unkritischer gehalten hatte, als sie ist. Parallelität bei KI-Agenten ist ein Gewinn, solange . Sobald eine Ressource migrationskritisch ist, braucht sie genau das: einen aktuellen Stand vor der Arbeit, ein Gate vor der Wirkung, und einen Mechanismus, der gleichzeitigen Zugriff ausschließt statt darauf zu hoffen. Fazit Ich habe das atomare Claiming nicht gebaut, weil es elegant ist, sondern weil ein verlorener Nachmittag mir gezeigt hat, wo bei paralleler KI-Arbeit die scharfe Kante liegt. Die Regel dahinter ist simpel genug, um sie überall anzuwenden: Hol dir den Stand, zieh dir den Slot, frag vor dem Deploy. Drei Schritte, die einen Drift verhindern, dessen Suche teurer ist als jede Vorsichtsmaßnahme. Mehrere KIs nebeneinander laufen zu lassen, ohne genau diese Koordination, ist exakt der Fehlerfall, den die ausschließen soll — und der zeigt das größere Muster dahinter.
Ein Wort, zwei Bedeutungen: Ich blockierte einen Git-Commit, die KI verstand Deploy. Warum gemeinsames Vokabular beim Arbeiten mit KI über alles entscheidet. — Heute lief stundenlang nichts mehr. Keine Tickets ließen sich anlegen, jeder Versuch wurde abgewiesen. Kein Bug im klassischen Sinn, keine kaputte KI, kein Denkfehler im Code. Ein Wort. Das ist die unauffälligste Sorte Problem, die mir beim Arbeiten mit KI begegnet — und gleichzeitig die teuerste. Nicht der falsche Algorithmus, nicht die halluzinierte Bibliothek. Eine Vokabel, die für mich das eine bedeutet und für die KI das andere. Die Szene: Ich sage Stopp, die KI hört Los Ich arbeite mit einer KI an einem Feature, und sie will committen. Ich sage: noch nicht. Wir sind nicht fertig, ich will die Arbeit noch nicht in Git haben. In meinem Kopf reden wir über einen — etwas, das ich mache, wann ich will, sobald das Feature steht. Die KI meinte etwas anderes. Für sie hieß committen, die neue Edge Function live zu deployen, damit ihr frisch geschriebener Code in Produktion läuft. Zwei verschiedene Aktionen, ein Wort. Und keiner von uns beiden merkt im Moment, dass wir über zwei verschiedene Dinge reden. Das Ergebnis war ein kleiner Dominoeffekt. Ich blockiere den Git-Commit. Die Edge Function bleibt undeployed. Der alte Code im Produktivsystem passt nicht mehr zum Rest, der sich schon verändert hat — und plötzlich werden alle neuen Tickets abgewiesen. Eine Stunde, bis der Groschen fällt Ich suche im Code. Ich suche in den Logs. Ich suche überall, nur nicht an der Stelle, die ich selbst verriegelt hatte. Eine Stunde später fällt der Groschen: Die neue Function war nie live gegangen. Genau das, was ich verhindert zu haben glaubte, war das eigentliche Problem. Mein Stopp war kein Schutz, sondern die Ursache. Der Fix war trivial — Function deployen, fertig. Die Lektion nicht. Der Fehler steckte nicht im Code, sondern im Wort. Solche Missverständnisse werfen keine Fehlermeldung. Sie verstecken sich, bis das System steht — und dann suchst du an der falschen Stelle, weil du sicher bist, das Richtige getan zu haben. Warum das beim Arbeiten mit KI fast zwangsläufig passiert Wenn du mit einer KI arbeitest, teilt ihr euch keine gemeinsame Bedeutung der Wörter. Commit, Deploy, live, fertig — das sind für dich klare Begriffe, weil du den ganzen Kontext im Kopf hast: dein Setup, deine Pipeline, deine Gewohnheit, wann was wohin geht. Die KI hat einen anderen Kontext. Sie kennt tausend Projekte, in denen committen und deployen praktisch dasselbe sind, weil ein Push automatisch ausliefert. Dieselbe Vokabel zeigt auf zwei Aktionen, und beide Seiten sind überzeugt, eindeutig gewesen zu sein. Das ist der Punkt, an dem es kippt: nicht weil jemand schlampig war, sondern weil ein Wort zwei Türen öffnet. Der Fix: ein kleines Dictionary statt großer Hoffnung Mein Tipp ist unspektakulär und genau deshalb wirksam: Leg dir ein Dictionary an. Definiere die wenigen Aktionen, die wirklich wehtun, wenn man sie verwechselt, und gib ihnen eindeutige Namen. Ein Commit ist bei mir ab jetzt immer ein Git-Commit. Eine Änderung am Produktivsystem heißt Deploy oder Edge-Deploy, nie einfach Commit. Ein Wort, eine Aktion. Bei mir steht das direkt in der , damit es in jeder Session greift: Die zweite Zeile ist die wichtigere. Ein nacktes Verb wie committen oder deployen ist die eigentliche Falle, weil es das Objekt offenlässt — und die KI füllt die Lücke mit ihrem Kontext, nicht mit deinem. Lass kein Verb ohne Objekt stehen. Das Dictionary kostet dich einmal fünf Minuten. Dafür nimmt es der KI die Chance, genau das Richtige zu tun, das du gerade verboten hast — und dir die Stunde Fehlersuche an der falschen Stelle. Fazit Die teuersten Probleme beim Arbeiten mit KI sind oft keine technischen, sondern sprachliche. Dasselbe Wort, zwei Aktionen, und niemand merkt es, bis das System steht. Du kannst dagegen nicht anhoffen — aber du kannst die Mehrdeutigkeit aus dem entscheidenden Vokabular herausnehmen. Ein kleines Dictionary, die Regel kein Verb ohne Objekt, beides in der . Mehr braucht es nicht, damit dein Stopp auch ein Stopp ist und kein verstecktes Los. So ein Vokabular ist letztlich nur eine Leitplanke — und , halten die tägliche Arbeit mit KI berechenbar. Wer das lieber sauber aufsetzt, statt es eine Stunde zu spät zu debuggen, dem helfe ich genau dabei in der .
Wie ich meine CLAUDE.md von Stilrichtlinie auf Token-Budget umgestellt habe — 6 Prinzipien für weniger Kosten, weniger Wartezeit und ehrlicheres Reporting. — Die teuerste Zeile in meinem Projekt war lange gar kein Code. Es war die KI, die bei jeder Aufgabe aufs Neue mein halbes Repo durchwühlte, drei Absätze ankündigte, was sie gleich tun würde, und am Ende eine Rückfrage stellte, deren Antwort offensichtlich war. Mal hundert Agent-Läufe pro Tag — das ist eine echte Rechnung in Token, Wartezeit und Geduld. Irgendwann habe ich aufgehört, meine CLAUDE.md als Stilrichtlinie zu lesen, und angefangen, sie als zu behandeln. Eine Datei voller höflicher Bitten wird ignoriert. Eine Datei voller harter Regeln, deren Bruch als Bug gilt, ändert das Verhalten. Hier sind die sechs Prinzipien, die am meisten gebracht haben. 1. Such gezielt, nicht breit — folge Pointern statt zu graben Der größte Token-Fresser ist die blinde Suche. Eine KI, die mit zwanzig Grep-Aufrufen durchs Repo stochert, zieht bei jedem Treffer Kontext nach, den sie zu 90 Prozent nie braucht. Der Kontext füllt sich mit Rauschen, und Rauschen kostet bei jedem weiteren Schritt mit. Mein Gegenmittel ist ein Context-Gate als allererster Schritt jeder Aufgabe: genau ein globaler -Lauf — nicht, um den ganzen Kontext zu laden, sondern um Code-Pointer zu holen, also Datei und Zeile. Erst dann wird gezielt an genau dieser Stelle gelesen. Das Prinzip dahinter ist „Pointer always, content on demand". Die KI bekommt eine Landkarte, keine vorgelesene Enzyklopädie. Der Unterschied ist nicht kosmetisch. Es ist oft der Unterschied zwischen „Sonnet löst das" und „dafür brauche ich Opus". 2. Begrenze den Output hart — mit Tags statt guter Vorsätze „Fass dich kurz" funktioniert nicht. Das ist eine Bitte, und Bitten werden weginterpretiert. Was funktioniert, ist ein Output-Contract: Jede Antwort startet mit einem Tag, der ein Zeichenlimit mitbringt. für erledigte Aufgaben, für reines Lesen, für Teilfortschritt, nur bei schwer reversiblen Aktionen — jeweils mit hartem Limit. Der Trick ist nicht das Limit selbst, sondern dass ein Verstoß als Bug gilt, nicht als Geschmacksfrage. Das dreht die Beweislast um: Die KI muss sich Ausführlichkeit verdienen, nicht ich mir Kürze. Nicht das Limit spart Token, sondern die Umkehr der Beweislast. Solange Kürze eine Bitte ist, gewinnt der Monolog. Erst wenn Länge sich rechtfertigen muss, wird sie selten. 3. Lass durchlaufen, statt rückzufragen Die teuerste Verzögerung ist der unnötige Roundtrip. Ich wechsle den Screen, komme nach zehn Minuten zurück — und finde statt eines fertigen Features eine Trivialfrage zum Padding. Das ist kein Service, das ist eine Vollbremsung. Deshalb gilt bei mir ein Autonomie-Default: sofort loslegen, bis zum Ende durcharbeiten. Reversible Entscheidungen — Naming, Reihenfolge, Refactor-Struktur, Lib-Wahl — trifft die KI selbst und markiert sie kurz. Gefragt wird nur bei echtem Risiko: Daten-Löschung, Prod-Deploy, Migration, Security. Meine Faustregel steht wörtlich in der Regeldatei: Wäre die Antwort in unter 30 Sekunden korrigierbar — nicht fragen, machen. Ein Tippfehler im Variablennamen kostet mich fünf Sekunden Korrektur. Eine Rückfrage dazu kostet einen ganzen Roundtrip. 4. Tag-Disziplin ist ehrliches Reporting — und nebenbei Token-Sparen Wer sauber zwischen „gelesen" und „geändert" trennt, kann nicht mehr aufblähen. Ein Read oder eine RAG-Query allein ist — niemals . Tool-Aufruf ist nicht gleich Aufgabenerfüllung. Das klingt nach Buchhaltung, ist aber der wirksamste Hebel gegen die „Schau, was ich alles getan habe"-Monologe. Wenn reines Lesen sich nicht als Erfolg verkaufen darf, verschwindet der Anreiz, drei Absätze über die eigene Gründlichkeit zu schreiben. Ein Tag kann nicht lügen: Entweder es wurde etwas geändert, oder eben nicht. 5. Wiederverwendbare Workflows statt langer Prompts Immer gleiche Abläufe gehören nicht in den Prompt, sondern hinter ein Keyword. Kurze Trigger lösen aus, die ihre Schritte und Schemas selbst mitbringen. Die Schritte kommen vom Server, nicht aus dem lokalen Kontext. Ich werfe ein Wort, der Rest kommt on demand. Statt einen 40-Zeilen-Ablauf in jeden Prompt zu kopieren — und damit jedes Mal die Token zu bezahlen — liegt der Ablauf einmal zentral und wird Schritt für Schritt nachgeladen. Das ist dieselbe Logik wie die Pointer-Suche aus Prinzip 1, nur auf Prozessebene statt auf Datei-Ebene. 6. Doku als Pointer-System — Wiedereinstieg ohne Re-Discovery Was die nächste KI-Session am meisten kostet, ist das Wiederfinden dessen, was die letzte schon wusste. Ohne Spur fängt jede Session beim Graben an. Deshalb bekommt jede berührte Funktion einen Doc-Block mit Suchbegriffen und Code-Pointern direkt im Code. Nach der Übernahme ins RAG schrumpft der Block zu einem schlanken Marker — der Volltext wandert ins RAG, im Code bleibt nur der Zeiger. Zeiger immer, Inhalt bei Bedarf. So liest die nächste Session den Marker, holt bei Bedarf den Volltext nach und muss nicht erneut entdecken, was längst dokumentiert ist. Fazit Der gemeinsame Nenner ist ein einziger Satz: Lade nie etwas in den Kontext, was du auch nachladen könntest — und sag nie etwas, wofür dich niemand gefragt hat. Pointer statt Volltext bei der Suche. Tags statt Prosa beim Output. Autonomie statt Roundtrips beim Ablauf. Keywords statt Prompt-Wänden beim Prozess. Vier Varianten desselben Gedankens. Das Überraschende daran: Ich habe nicht nur Geld gespart, sondern bin auch schneller geworden, weil weniger Hin und Her, und ehrlicher, weil ein Tag nicht lügen kann. Sonnet erreicht inzwischen bei Aufgaben, die vorher das größere Modell brauchten — nicht weil das Modell besser wurde, sondern weil ich aufgehört habe, es mit eigenem Ballast zu bremsen. Dieselbe Logik skaliert über eine einzelne Config-Datei hinaus: das richtige Modell auf die richtige Aufgabe zu routen, bei schlankem Kontext, ist genau das, was die automatisiert.
Drei Frontier-Modelle, dasselbe 1000-Zeilen-Skript, drei verschiedene Fundlisten — und warum genau diese Streuung Multi-Orchestrierung stark macht. — Ich habe dasselbe 1000-Zeilen-Skript an drei Frontier-Modelle gegeben und sie um eine Code-Analyse gebeten. Gleiche Datei, gleiche Frage, kein Unterschied im Auftrag. Zurück kamen drei verschiedene Listen. Es gab eine Schnittmenge — die offensichtlichen Sachen fanden alle —, aber jedes Modell hatte auch Funde, die kein anderes hatte. Mein erster Reflex war, das als Schwäche zu lesen: Wenn die Modelle sich nicht einig sind, kann ich keinem so recht trauen. Inzwischen sehe ich es umgekehrt. Genau diese Streuung ist der Grund, warum mehrere Modelle zusammen mehr finden als das beste Einzelmodell allein. Warum das so ist, will ich hier auseinandernehmen. Ein LLM durchsucht Code nicht — es liest selektiv Der erste Denkfehler steckt schon im Wort "durchsuchen". Ein klassischer geht eine Codebasis erschöpfend durch: jede Regel gegen jede Zeile, deterministisch, vollständig im Rahmen seiner Regelmenge. Was er kann, findet er immer, und zwar überall. Ein Sprachmodell arbeitet anders. Es liest den Code nicht Zeile für Zeile gegen eine feste Checkliste ab, sondern richtet seine Aufmerksamkeit selektiv aus — getrieben davon, was im jeweiligen Kontext relevant erscheint. Das ist näher an einem erfahrenen Reviewer, der eine Datei überfliegt und an drei Stellen hängenbleibt, als an einem Linter, der mechanisch alles abklappert. Daraus folgt: Was ein Modell findet, hängt nicht nur davon ab, was im Code steht, sondern auch davon, worauf es in diesem Durchlauf seine Aufmerksamkeit gelegt hat. Schon dasselbe Modell findet zweimal Verschiedenes Bevor wir verschiedene Modelle vergleichen, lohnt der Blick auf ein einzelnes. Selbst wenn ich exakt dasselbe Modell zweimal mit derselben Datei laufen lasse, bekomme ich nicht zwangsläufig dasselbe Ergebnis. Der Grund liegt im . Bei jedem Token wählt das Modell aus einer Wahrscheinlichkeitsverteilung. Die steuert, wie stark es dabei vom wahrscheinlichsten Pfad abweichen darf. Liegt sie über null, ist ein Zufallselement im Spiel — und das pflanzt sich fort. Ein früh anders gewähltes Wort lenkt die folgende Analyse in eine andere Richtung. Diese bedeutet: Ein Lauf, der früh auf ein Nebenläufigkeitsproblem stößt, gräbt dort weiter; ein zweiter Lauf desselben Modells fängt vielleicht beim Fehlerhandling an und landet woanders. Pfadabhängigkeit heißt nicht, dass die Funde zufällig wären. Reale Probleme bleiben reale Probleme. Es heißt nur, dass die Reihenfolge und der Fokus eines Laufs mitbestimmen, welche der vorhandenen Probleme tatsächlich auftauchen. Begrenzte Aufmerksamkeit priorisiert — und das erzeugt die Differenzmenge Der zweite Grund ist die begrenzte Aufmerksamkeit. Der eines Modells kann nicht alles gleich gewichten; er priorisiert. Bei 1000 Zeilen kann ein Modell nicht jede Zeile mit jeder anderen in voller Tiefe in Beziehung setzen. Es muss entscheiden, worauf es schaut. Das erklärt das Muster sauber: Die Schnittmenge der Funde — das, was alle Modelle nennen — ist das Offensichtliche. Probleme, die so deutlich sind, dass sie unter fast jeder Priorisierung auffallen. Die Differenzmenge — das, was nur ein einzelnes Modell findet — ist das Subtile. Probleme, die nur sichtbar werden, wenn die Aufmerksamkeit zufällig oder durch Prägung genau auf diese Stelle fällt. Und genau die subtilen Bugs sind die teuren. Modelle haben Schwerpunkte Zum Sampling und zur Priorisierung kommt ein dritter Faktor: Modelle sind unterschiedlich geprägt. Training, Feinabstimmung und Ausrichtung führen dazu, dass Modelle Schwerpunkte mitbringen. Das eine fällt eher über Sicherheitslücken, das andere über Performance-Probleme, ein drittes über logische Inkonsistenzen oder fehlende Randfälle. Diese Prägung ist kein Zufall pro Lauf, sondern eine systematische Neigung. Sie ist der Grund, warum die Differenzmenge nicht nur Rauschen ist, sondern oft komplementär: Modell A bringt die Security-Funde mit, die Modell B übersieht, und umgekehrt. Drei verschiedene Schwerpunkte decken zusammen mehr Fläche ab als dreimal derselbe. Was der reale Test ergeben hat Ich habe das nicht nur theoretisch durchdacht, sondern an einem konkreten kritischen Skript getestet. Dieselbe Datei, verschiedene Modelle und Einstellungen, jeweils . | Rang | Modell / Setup | Σ Funde | Anmerkung | | --- | --- | --- | --- | | 1 | Opus 4.8 xHigh DeepThink, Multi-Agent | 15 | stärkste Liste, aber teuer | | 2 | Gemini 3.1 Pro High | 14,5 | bester Single-Pass, Preis-Leistungs-Sieger | | 3 | Opus 4.8 Med DeepThink | 13,5 | | | 4 | Sonnet 4.6 | 13 | mit Zeilen-Ankern, gut verifizierbar | | 5 | Gemini 3.5 Flash High | 12 | überrascht positiv | | 6 | Google Flash 3.5 Low | 10,5 | einziger False-Positive (#8) | | 7 | Haiku 4.5 | 10,5 | verpasst den Top-Bug (#1) | Ein achter Lauf mit Opus, der vorab schon Kontakt mit der Datei hatte, lief außer Konkurrenz — das Ergebnis war durch den Vorkontakt kontaminiert und damit nicht vergleichbar. Die Pointe steht in der ersten Spalte. Zwischen Platz eins und zwei liegen 0,5 Punkte. Der Abstand an der Spitze ist winzig. Der große Sprung in der Tabelle kommt nicht daher, dass ein Modell radikal stärker wäre als das nächste — er kommt aus der Orchestrierung. Der Multi-Agent-Lauf führt, weil er mehrere Sichten zusammenführt, nicht weil ein einzelnes Modell überlegen ist. Was ich als Nächstes teste Aus dieser Beobachtung folgen drei Tests, die ich konkret vorhabe. Erstens den Determinismus messen. Ich lasse dasselbe Modell bei Temperatur null mehrfach über dieselbe Datei laufen. Wenn die Ergebnisse dann stabil bleiben, kann ich Zufall vom Können trennen — und sehe, wie groß der Sampling-Anteil an der Streuung wirklich ist. Zweitens eine bauen. Ich baue bekannte Bugs gezielt in ein Skript ein, sodass ich genau weiß, was drinsteckt. Erst dann lässt sich sauber messen: Welcher Anteil der tatsächlich vorhandenen Probleme wird gefunden? Ohne diese Referenz vergleiche ich nur Listen gegeneinander, nicht gegen die Wahrheit. Drittens ein bewusst gestreutes gegen den besten Single-Pass antreten lassen. Wenn die Streuung wirklich die Stärke ist, muss eine Orchestrierung aus absichtlich verschieden geprägten Modellen den stärksten Einzellauf schlagen — und zwar reproduzierbar. Fazit Drei Modelle, drei Listen — das ist kein Defekt, sondern Information. Die Übereinstimmung zeigt das Offensichtliche, die Abweichung das Subtile. Sampling, begrenzte Aufmerksamkeit und unterschiedliche Prägung sorgen gemeinsam dafür, dass kein einzelnes Modell die ganze Fläche abdeckt. Der reale Test bestätigt es: Der Vorsprung an der Spitze ist klein, der Hebel liegt im Zusammenführen. Ob sich das sauber messen lässt, klärt der nächste Durchgang — die Tests stehen, das Ergebnis ist offen. Die praktische Lehre gilt aber schon jetzt: Eine Streuung aus Modellen schlägt jedes Einzelmodell — und genau darum geht es, sie als laufen zu lassen, statt alles auf eines zu setzen.
Wie ich meine KI-Wissensbasis mit RAG aktuell halte — durchsuchbar, gepflegt per Stichwort und nachts von allein nachindexiert, statt zu veralten. — Jedes KI-System auf Basis großer Sprachmodelle hat dasselbe Grundproblem: Das Modell kann nicht dein gesamtes Wissen lesen. Sein Kontextfenster fasst nur eine begrenzte Menge Text pro Anfrage. Damit hängt alles an zwei Fragen — wie hältst du dein Wissen aktuell, und wie machst du es so durchsuchbar, dass die KI sich genau das herauszieht, was sie gerade braucht. Veraltet die Doku, antwortet die KI überzeugt falsch. Findet sie nichts, beginnt sie zu raten. Mein Ansatz dafür heißt RAG (Retrieval-Augmented Generation): Statt der KI alles auf einmal zu geben, liegt das Wissen in einer durchsuchbaren Wissensbasis. Bei jeder Frage holt sich das Modell gezielt nur die relevanten Stücke. Genau so halte ich meine KI-Wissensbasis mit RAG aktuell. Wofür ich das nutze Interessant wird das, sobald du über Jahre echtes Wissen aufgebaut hast und willst, dass ein KI-System verlässlich darauf zugreift. Bei mir sind das etwa meine Tonalität für die Social-Media-Kanäle — die KI schreibt konsistent in meiner Stimme — oder die nüchternen Unternehmensdaten wie Webseite und Kennzahlen. Die pflege ich an einer einzigen Stelle; ändert sich etwas, ändere ich es dort, und das System weiß weiterhin, wo es nachsieht. Ein Beispiel aus der Entwicklung: Der Zugriff auf meine Datenbank war lange unzuverlässig, die KI riet Ports und Abläufe. Seit der korrekte Weg im RAG hinterlegt ist, schlägt sie nach statt zu raten — Thema erledigt. Suche in Stufen Nicht jede Frage braucht dieselbe Tiefe. Deshalb ist die Suche mehrstufig: Sie beginnt grob — in welchem Bereich liegt das Thema? — und wird von dort feiner, bis sie an der richtigen Stelle ankommt. Wie das Hineinzoomen auf einer Landkarte: erst der Kontinent, dann das Land, dann die Straße. So bleibt sie bei einfachen Fragen schnell und wird nur gründlich, wenn es nötig ist. Ein Keyword, ein definierter Ablauf Der eigentliche Hebel ist die Steuerung über Stichwörter, die auf einem zentralen MCP-Server liegen — einer standardisierten Schnittstelle, über die der KI-Assistent auf Werkzeuge und Abläufe zugreift. Dort bündele ich meine Workflows. Man gibt ein Stichwort ein und bekommt den vollständigen, fest definierten Ablauf zurück: für die Wissenspflege, für eine saubere Datenbank-Migration, für das Dokumentieren von Code, für strukturiertes Entscheiden über das Keyword "Triage", für Zusammenfassungen, bis zum Recap, bei dem die KI vorab in eigenen Worten wiedergibt, was sie verstanden hat. Entscheidend ist die Verlässlichkeit: Diese Abläufe sind deterministisch, laufen also jedes Mal in denselben Schritten, statt dass die KI den Weg neu erfindet. Das macht die Arbeit schneller und vor allem berechenbar. Perspektivisch sollen auch meine Kunden über denselben MCP-Server darauf zugreifen — ein Stichwort, ein definierter Ablauf, ein reproduzierbares Ergebnis. Am Beispiel der Wissenspflege: Sage ich am Ende einer Sitzung "pflege das ein", fasst der Prozess zusammen, was passiert ist, ordnet es dem richtigen Bereich zu, verschlagwortet es und schreibt es in die Datenbank — sofort durchsuchbar. Ich treffe eine Entscheidung, das Stichwort. Der Rest erledigt sich selbst. Pflege, die nachts von allein läuft Damit das System nicht nur auf Zuruf aktuell bleibt, läuft jede Nacht eine feste Routine über meine Aufgaben-Pipeline: aufräumen, neu sortieren, nachindexieren. Am nächsten Morgen ist die Wissensbasis einen Schritt weiter — ohne dass ich eine Zeile Dokumentation von Hand angefasst habe. Fazit Am Ende geht es nicht um gesparte Tipparbeit, sondern um Verlässlichkeit. Eine KI auf veraltetem Wissen gibt selbstbewusst falsche Antworten — gefährlicher, als nichts zu wissen. Weil ich das Wissen kontinuierlich und nah am Geschehen pflege, wächst die KI mit dem Projekt mit. Ein Stichwort genügt, der Rest läuft in festen Bahnen. Wissen, das sich pflegt, statt zu veralten. Ich baue das System laufend weiter und teile meine Erfahrungen damit offen. Wenn dich das Thema interessiert oder du überlegst, dein eigenes Wissen so für eine KI nutzbar zu machen, dann folge gerne meiner LinkedIn Business Page und melde dich. Ich spreche darüber wirklich gern — am liebsten konkret an deinem Fall. Wie ich Abläufe über Stichwörter erzwingbar mache: Wie ich das Token-Budget schon serverseitig schone:
Headless-Agenten auf dem eigenen Rechner, gespeist aus deinem vorhandenen Abo statt aus einer API-Rechnung — wie boostN viele Modelle orchestriert. — Die meisten Menschen kennen KI in genau einer Form: ein Eingabefeld im Browser, vielleicht die App auf dem Handy. Man tippt eine Frage, bekommt eine Antwort, fertig. Das ist die sichtbare Oberfläche — und sie verdeckt, dass dahinter ein viel mächtigerer Betriebsmodus liegt, von dem die wenigsten je gehört haben. Genau dieser Modus ist das Fundament von boostN. Ich erkläre in diesem Beitrag, was er ist, warum er für eine Multi-AI-Orchestrierung den Unterschied macht — und warum das Ganze für dich am Ende ohne zusätzliche API-Rechnung läuft. Die drei Arten, ein Sprachmodell zu betreiben Es lohnt sich, das einmal sauber zu sortieren, weil daran fast alles hängt. Die erste Art ist die Web-Oberfläche: Chat im Browser, bequem, aber abgeschottet. Das Modell sieht nur, was du ins Feld tippst. Es hat keinen Zugriff auf deine Dateien, kann nichts auf deinem Rechner ausführen, vergisst zwischen den Sitzungen das meiste. Die zweite Art ist die IDE-Integration: Das Modell sitzt in deiner Entwicklungsumgebung, sieht deinen Code, schlägt Änderungen vor. Schon deutlich näher dran an echter Arbeit — aber an einen Editor gebunden und auf interaktives Hin und Her ausgelegt. Die dritte Art kennt kaum jemand: der Headless-Modus im Terminal. Bei Claude heißt der Aufruf , andere Anbieter haben ihr Pendant. Du übergibst dem Modell eine Aufgabe, es arbeitet sie eigenständig ab und gibt am Ende ein Ergebnis zurück — ohne dass ein Mensch in der Schleife sitzt und jeden Schritt bestätigt. Warum headless den Unterschied macht Der Reiz am Headless-Modus ist nicht nur, dass kein Mensch zuschauen muss. Es ist die Kontrolle, die man dabei bekommt. Wer ein Modell headless fährt, kann Verhalten und Flags setzen, die in der bequemen Web-Oberfläche schlicht nicht zur Verfügung stehen: welche Werkzeuge das Modell nutzen darf, wie weit es eigenständig handeln soll, welchen Kontext es vorab bekommt, in welchem Format es antwortet. Das Modell ist im Terminal kein Gesprächspartner mehr, sondern ein steuerbarer Baustein, den man in einen größeren Ablauf einhängen kann. Und genau das ist der Punkt, an dem aus „ich chatte mit einer KI" ein orchestriertes System wird. Was Multi-AI-Orchestrierung wirklich heißt boostN ist im Kern eine Orchestrierungs-Software: Jede Aufgabe wird von einem Sprachmodell erledigt — aber nicht von einem Modell, sondern von dem, das gerade passt, eingehängt in eine gemeinsame Pipeline. Manche Aufgaben kann ein web-basierter Chat ohne Dateizugriff bearbeiten. Oft aber soll das Modell an deine echten Daten ran: an die CSV mit den Produktdaten, an PDFs, an Dokumente, an Code. In dem Moment ist der elegante Weg ein Headless-Agent auf deinem eigenen Rechner — er hat den nötigen Zugriff, ohne dass du deine Daten in irgendeine fremde Web-Oberfläche kippen musst. Das Entscheidende an dieser Pipeline: Sie ist aufgabenagnostisch. Die Maschinerie interessiert sich nicht dafür, was erledigt wird. Sie lädt den gewählten Agententyp und führt aus. Ob das Ergebnis ein Blogartikel ist, eine optimierte Produktbeschreibung, ein Social-Media-Post über den passenden Kanal oder eine Datenanalyse — die Pipeline bleibt dieselbe. Ein Agent, hundert Agenten, N Agenten erledigen N Dinge, parallel, ohne dass jemand jeden einzeln anstößt. Nicht ein Modell macht alles, sondern viele Modelle teilen sich einen gemeinsamen Kontextraum — und die Pipeline verteilt die Arbeit, statt sie an ein einzelnes Tool zu binden. RAG: damit die Agenten wissen, wovon sie reden Ein Agent ist nur so gut wie das, was er weiß. Ein generisches Modell schreibt generischen Text — höflich, aber austauschbar, ohne Kenntnis deiner Marke, deiner Regeln, deines Tonfalls. Deshalb hängt an boostN ein integriertes RAG-System (Retrieval-Augmented Generation). Vereinfacht gesagt: Bevor ein Agent loslegt, zieht er sich aus einer Wissensbasis genau das heraus, was für seine Aufgabe relevant ist, und hat es im Kontext. Das können Code-Regeln sein, redaktionelle Guidelines, eine festgelegte Tonalität pro Kanal — auf LinkedIn anders als im Blog — oder schlicht die Firmeninformationen, ohne die kein brauchbarer Content entsteht. Der Punkt ist die Anschließbarkeit: Wissen wird einmal hinterlegt und steht dann jedem Agenten zur Verfügung, der es braucht. Du musst nicht in jeden einzelnen Auftrag erklären, wer du bist und wie du klingst. Das System weiß es. Der Teil, der vielen am meisten bedeutet: keine extra API-Kosten Jetzt der Punkt, der in der Praxis oft den Ausschlag gibt. Viele Automatisierungs-Werkzeuge lassen sich gut an, bis die erste API-Rechnung kommt — denn klassischerweise zahlst du dort pro Token, separat, zusätzlich zu jedem Abo, das du ohnehin schon hast. boostN geht den anderen Weg: Du nutzt dein bestehendes Abo. Claude, ChatGPT, Gemini — was du eh schon bezahlst, treibt die Agenten an. Wer mag, hängt ein lokales LLM auf dem eigenen Rechner dran und zahlt überhaupt nichts pro Aufruf. So oder so entfällt der separate Posten „API-Kosten anderer Anbieter", den man bei vielen Lösungen sonst mitschleppt. Wichtig ist mir an dieser Stelle die ehrliche Einordnung: Die Abrechnungsmodelle der Anbieter sind 2026 in Bewegung, und welcher Anbieter seinen Headless-Modus noch im normalen Abo deckt, ist eine eigene, sich verschiebende Frage. Wer genau wissen will, welches Modell man Mitte 2026 ohne separate API-Rechnung headless fahren kann, findet die Detail-Übersicht im verwandten Beitrag — siehe unten. Hier geht es mir um das Prinzip: Die Orchestrierung selbst zwingt dir keine zweite Rechnung auf. Wofür man das einsetzt Die ehrlichste Antwort lautet: für ziemlich alles, was dein gewähltes Modell ohnehin kann. Die Orchestrierung erweitert das Modell nicht um neue Fähigkeiten, sie organisiert seine Fähigkeiten — und macht aus einer einzelnen Anfrage einen wiederholbaren Ablauf. Spannend wird es da, wo mehrere Modelle zusammenarbeiten. Weil sie einen gemeinsamen Kontextraum teilen, kann ein Modell auf dem aufbauen, was ein anderes vorbereitet hat. In Summe entsteht dadurch oft mehr als das, was ein einzelnes Modell allein leisten würde — nicht weil das Modell klüger geworden ist, sondern weil die Arbeit besser verteilt und besser mit Kontext versorgt ist. Ein ehrlicher Ausblick Ich nehme gerade viele Proof-Videos auf — weil ich finde, dass man so ein System zeigen sollte, statt nur darüber zu schreiben. Du sollst sehen können, was es tatsächlich tut, und mir das nicht einfach glauben müssen. Eine kostenlose Early-Access-Phase rückt näher. Der Weg hinein führt über die LinkedIn-Company-Page: Wer zum Start folgt, bekommt einen Einladungslink. Kein Hype, kein Countdown — einfach der nächste sinnvolle Schritt, wenn das System so weit ist. Fazit Die eigentliche Idee hinter boostN ist unspektakulär, wenn man sie einmal verstanden hat: Sprachmodelle headless betreiben, mehrere davon in einer aufgabenagnostischen Pipeline orchestrieren, ihnen über RAG das nötige Wissen mitgeben — und das Ganze aus dem Abo speisen, das du ohnehin hast, statt aus einer separaten API-Rechnung. Kein neuer Kostenposten, keine geschlossene Web-Oberfläche, sondern steuerbare Agenten mit Zugriff auf deine echten Daten. Aus „ich chatte mit einer KI" wird so „ich lasse N Modelle koordiniert für mich arbeiten". Das ist der Unterschied, um den es geht. Welche Modelle man 2026 ohne API-Rechnung headless fahren kann — der Anbieter-Vergleich:
Fable 5 hat einen Bug in einem Anlauf gelöst, an dem Opus zweimal scheiterte. Trotzdem wechsle ich nicht. Mein ehrlicher Praxiseindruck nach drei Tagen. — Ich habe die letzten drei Tage damit verbracht, Anthropics neues Claude Fable 5 quer durch mehrere Editoren laufen zu lassen — mit echten Aufgaben aus echten Projekten. Keine Benchmarks, keine synthetischen Tests, einfach ganz normale Entwicklungsarbeit. Hier ist, was dabei herausgekommen ist. Der Aufbau Mein Vorgehen war bewusst unspektakulär: dieselben agentischen Coding-Sessions wie immer, in mehreren Editoren, mit denselben Effort- und Deep-Thinking-Einstellungen, die ich auch mit Opus 4.8 nutze. Keine Konfigurationsänderung, kein spezielles Prompting. Nur das Modell getauscht und sonst alles gelassen, wie es war. Genau so wollte ich es haben, weil nur dann ein fairer Vergleich herauskommt. Qualität: ein anderer Blickwinkel, keine andere Liga Die Gesamtqualität ist solide, vielleicht eine Spur über Opus 4.8 — aber nicht, weil Fable auf der ganzen Linie schlauer wäre. Was wirklich auffällt, ist etwas anderes: Fable findet andere Lösungswege. Das beste Beispiel war ein Bug bei der Erneuerung eines JWT-Tokens, an dem ich mich vorher schon zweimal mit Opus festgebissen hatte. Beide Male drehte Opus im Kreis — plausibel aussehende Versuche, aber keine echte Lösung. Fable ist das Problem aus einem völlig anderen Winkel angegangen und hat einen Ansatz produziert, der tatsächlich vielversprechend aussieht. Getestet ist er noch nicht abschließend, also halte ich noch keine Siegesrede — aber allein der frische Blick war schon etwas wert. Genau das ist das Muster, das ich hervorheben würde: Wenn ein Modell sich in einem lokalen Optimum festfährt, ist ein anderes Modell nicht einfach "mehr Rechenleistung" — es ist eine zweite Meinung. Und das ist gar nicht so selbstverständlich, wie es klingt. Wenn Opus sich einmal eine bestimmte Vorstellung vom Problem zurechtgelegt hat, probiert es zwar verschiedene Varianten — aber alle innerhalb derselben Grunddeutung. Fable scheint das Problem nochmal von vorne aufzurollen, als hätte es die vorherigen Sackgassen nie gesehen. Bei diesem Token-Bug war genau das der Unterschied: nicht "noch ein Versuch", sondern ein anderer Ausgangspunkt. Für hartnäckige Fehler, an denen man sich schon festgebissen hat, ist das überraschend wertvoll. Es redet deutlich weniger. Wirklich deutlich. Fable ist spürbar weniger geschwätzig. Ich habe an meinen Einstellungen nichts geändert, das kommt also klar vom Modell selbst. Es sieht so aus, als wäre das Feedback aus der Community — dass die Modelle alles und jedes zerklären — bei Anthropic angekommen. Meine Gefühle dazu sind gemischt. Nachdem man sich an den ausführlichen Live-Kommentar gewöhnt hat, fühlt sich ein Modell, das einfach... still... arbeitet... fast schon eigenartig an. Keine kleine Zusammenfassung am Ende, kaum Statusmeldungen zwischendurch. Man schickt es los, und es kommt mit Ergebnissen zurück. Effizient? Ja. Bequem? Daran muss man sich erst gewöhnen. Geschwindigkeit und Token-Verbrauch: die eigentliche Geschichte Hier wird es weniger schön. Die Geschwindigkeit ist bei identischen Effort- und Deep-Thinking-Einstellungen spürbar langsamer als Opus 4.8. Und der Token-Verbrauch ist gewaltig. Im Max-Plan konnte ich mit Opus den ganzen Tag durcharbeiten, ohne je an meine Grenzen zu stoßen. Mit Fable bin ich zum ersten Mal seit Wochen in den roten Bereich gerutscht. Die andere Token-Ökonomie ist sehr real. Fable 5 liegt preislich über dem Opus-Tier. In der Praxis heißt das: derselbe Arbeitstag, der mit Opus locker im Budget blieb, hat mein Kontingent mit Fable zum ersten Mal seit Wochen ausgereizt. Das ist kein Detail, das ist der Hauptgrund für meine Entscheidung. Mein Fazit nach drei Tagen Der marginale Qualitätsgewinn rechtfertigt den gewaltigen Token-Verbrauch nicht — jedenfalls nicht für meine tägliche Arbeitslast. Opus 4.8 liefert für die Aufgaben, die ich ihm gebe, ohnehin schon richtig gute Ergebnisse. Wo ich Fable durchaus seinen Platz sehe: als Präzisionswerkzeug für die wirklich harten Probleme. Wenn man feststeckt, wenn die Komplexität tatsächlich nach dem größten verfügbaren Modell verlangt, oder wenn man eine grundlegend andere Perspektive auf ein Problem braucht — dann würde ich danach greifen. Bewusst, gezielt, als Ausnahme. Für alles andere bleibt Opus 4.8 mein Alltagsmodell. Manchmal ist das größte Modell eben nicht das beste Werkzeug, sondern das letzte Mittel.
Pläne als Rich-Text, Dateien per Drag & Drop dran, und der KI-Agent liest beides mit. Wie der neue Plan-Bereich in boostN den Projektkontext bündelt. — Bei größeren Projekten kenne ich das Problem nur zu gut: Der eigentliche Plan lebt irgendwo in einem Notiz-Dokument, die wichtigen Dateien liegen in einem Ordner auf der Festplatte, und wenn ich dann mit der KI an dem Projekt arbeite, muss ich beides erst wieder zusammensuchen und einzeln reinkopieren. Genau diese Zettelwirtschaft wollte ich loswerden. Deshalb hat in boostN jetzt jedes Big Project einen eigenen Plan-Bereich — direkt oben am Projekt, da wo er hingehört. Der Plan wohnt jetzt am Projekt, nicht daneben Das Grundprinzip ist simpel: Statt den Plan irgendwo separat zu führen, schreibe ich ihn direkt an das Projekt. Es ist ein richtiger Schreibbereich mit Formatierung, also Überschriften, Listen, Hervorhebungen — nichts Abgehacktes, sondern ein Text, in dem man wirklich denken kann. Und ich bin nicht auf einen einzigen Plan festgelegt. Pro Projekt kann ich mehrere Pläne anlegen, jeden mit einem eigenen Erledigt-Status. So lässt sich zum Beispiel die grobe Richtung von einem konkreten nächsten Arbeitsschritt trennen, ohne dass ich dafür ein zweites Werkzeug aufmachen muss. Wenn ein Plan abgearbeitet ist, hake ich ihn ab und er rutscht aus dem Weg. Schön finde ich, dass es derselbe Plan-Baustein ist, der auch im Vision Board steckt. Das heißt: Egal, an welcher Stelle in der App ich plane, es fühlt sich gleich an. Ein Konzept, einmal verstanden, überall gleich. Dateien einfach reinziehen — und wieder rausholen Der Teil, den ich im Alltag am meisten nutze, sind die Datei-Anhänge direkt am Plan-Bereich. Ich kann eine Datei über den „+ Datei"-Knopf auswählen oder sie einfach per Drag & Drop ins Fenster ziehen, auch mehrere auf einmal. Runterladen geht mit einem Klick. Dabei ist es ziemlich egal, was für eine Datei das ist: eine Markdown-Notiz, ein exportiertes HTML, ein PDF mit dem Briefing vom Kunden — bis 20 MB pro Datei nimmt der Bereich alles entgegen. So liegt das Referenzmaterial endlich da, wo der Plan ist, statt verstreut über drei Ordner und zwei Chats. Briefing-PDF vom Kunden, eine Markdown-Datei mit den gesammelten Anforderungen und ein paar Screenshots — alles am selben Projekt. Wenn ich nach zwei Wochen wieder reinschaue, ist der ganze Kontext sofort da. Der spannende Teil: Die KI liest mit Bis hierhin ist das eine ordentliche, aber unspektakuläre Sache — ein Plan plus ein paar Anhänge. Der eigentliche Unterschied entsteht dadurch, dass der KI-Agent den Plan mitlesen und auch mitschreiben kann. Heißt konkret: Ich muss der KI den Plan nicht mehr jedes Mal mühsam erklären oder reinkopieren. Sie kann den Plan eines Projekts direkt lesen, sich daran orientieren und ihn auf Wunsch auch weiterschreiben. Die angehängten Dateien zieht sie sich über sichere, zeitlich begrenzte Links — sie hat den Projektkontext also direkt zur Hand, ohne dass ich zur Brücke zwischen Plan und Chat werde. Das ändert die Arbeitsweise mehr, als es zuerst klingt. Statt „lies dir das hier nochmal durch, dann reden wir" wird daraus „du kennst den Plan, lass uns am nächsten Punkt weitermachen". Der Kontext ist nicht mehr etwas, das ich liefern muss, sondern etwas, das am Projekt einfach da ist. Privat bleibt privat Eine Sache war mir bei den Datei-Anhängen von Anfang an wichtig: Das ist ein privater Speicher. Nur der Besitzer kommt an seine Dateien, niemand sonst. Und wenn etwas heruntergeladen wird, wird es immer als Datei ausgeliefert und nie einfach im Browser ausgeführt — gerade bei HTML-Dateien ist das ein wichtiger Unterschied, über den man als Nutzer normalerweise gar nicht nachdenken muss, weil er einfach sauber gelöst sein sollte. Fazit Unterm Strich geht es bei dem Plan-Bereich um eine einzige, eher unglamouröse Sache: Kontext an einem Ort. Der Plan, die Referenzdateien und der KI-Agent, der beides kennt — alles am selben Projekt, statt über Notizen, Ordner und Chatverläufe verstreut. Für mich ist das einer dieser Bausteine, die man nach ein paar Tagen nicht mehr missen will, weil das ständige Zusammensuchen einfach wegfällt.
Ein wachsender JSONB-Blob legte unseren Editor lahm. Der Verdächtige war harmlos, die echte Ursache kontraintuitiv: Lesen scheiterte, nicht Speichern. — Es fing harmlos an. Ich tippte etwas in das Vision-Board unserer Web-App, der Editor speicherte — und plötzlich nicht mehr. Kein Knall, keine Fehlermeldung im Vordergrund, einfach: Die Änderung war nach dem nächsten Laden wieder weg. Und weil ich kurz vorher ein in einen Titel getippt hatte, hatte ich sofort einen Verdächtigen. Klingt logisch, oder? Ein Steuerzeichen im Text, das irgendwas zerschießt. Genau dieser naheliegende Verdacht hat mich am Anfang in die völlig falsche Richtung geschickt. Der falsche Verdächtige Das war ein Red Herring, also eine falsche Fährte. Ich habe es mir genau angeschaut: Es lag völlig harmlos als ganz normaler Text in einem Feld, sauber escaped, JSON-technisch unkritisch. Kein Steuerzeichen, das irgendwo ausbrach, keine kaputte Struktur. Das Ding war Plain-Text und absolut unschuldig. Das ist die erste Lehre dieser Geschichte, und ich falle selbst immer wieder darauf rein: Der erste Verdächtige ist fast nie der Täter. Man hat gerade etwas Auffälliges getan, also verknüpft das Hirn das Symptom sofort damit. Aber „ich habe X getippt und dann ging es kaputt" ist eine Korrelation, kein Beweis. Die schrittweise Eingrenzung Also bin ich da hingegangen, wo die Wahrheit steht: in die Konsole. Statt weiter zu raten, habe ich die Fehler-Logs gelesen, und da standen zwei Meldungen, die alles verändert haben. Die erste: ein Browser-Fehler, sinngemäß „Content-Length header of network response exceeds response Body". Übersetzt heißt das: Der Server kündigt eine bestimmte Antwortgröße an, liefert dann aber weniger — die Antwort bricht mittendrin ab. Die zweite: ein . Ein Timeout. Etwas hat zu lange gedauert. Und jetzt kam der Moment, in dem sich mein Bild gedreht hat. Beide Fehler reden vom Lesen, nicht vom Schreiben. Eine Antwort, die abbricht. Ein Timeout beim Abrufen. Mein ganzer Verdacht hatte sich um das Speichern gedreht — dabei schrie die Konsole die ganze Zeit, dass das Problem auf dem Rückweg liegt. Die echte Ursache Mit dem Wissen war der Rest Detektivarbeit. Ich habe per direktem Datenbank-Zugriff nachgemessen, wie groß die betroffene Zeile eigentlich ist. Und da lag der Hund begraben: Das gesamte Board steckte als ein einziger JSONB-Blob in einer einzigen Datenbank-Zeile. Über die Zeit war dieser Blob auf rund 725 KB Text angewachsen, vollgelaufen mit knapp hundert Zielen, hundert Initiativen, dutzenden weiteren Einträgen und langen Fließtext-Notizen. Ein einzelnes Sammel-Item hielt für sich allein 76 KB. Und jetzt die eigentliche Pointe, die ich vorher nie so klar gesehen hatte: Schreiben war nie das Problem. Ein JSONB-Feld kann in Postgres bis zu 255 MB groß werden — ein Update mit 725 KB läuft serverseitig völlig problemlos. Was kippt, ist die Auslieferung der Lese-Antwort. Bei einem ganz normalen Abruf der Zeile muss die Datenbank-Schicht die komplette Zeile serialisieren und durch eine gepoolte Verbindung schieben. Bei ein paar Kilobyte ist das nichts. Bei 700 KB und mehr wird es so langsam, dass es reißt — die Antwort bricht ab (daher der Content-Length-Fehler), und die vorgelagerte Schicht mit ihrem 15-Sekunden-Hard-Timeout zieht den Stecker (daher die 504). Wichtig dabei: Es gibt keine feste KB-Obergrenze, ab der es verboten wäre. Es ist schlicht Zeit mal Durchsatz. Unterhalb der Schwelle läuft alles, oberhalb kippt es reproduzierbar. Der Blob war eine tickende Uhr — er funktionierte tadellos, bis die Auslieferung eines Tages über die Zeitgrenze rutschte. Der Folgeschaden, der die ganze App lahmlegte Das Fiese an solchen Fehlern ist, dass sie selten allein kommen. Hier eskalierte es in zwei Stufen. Stufe eins: Jeder fehlgeschlagene Speicherversuch löste eine Konflikt-Wiederherstellung aus — die wiederum las. Also noch ein langsamer Read, der wieder scheiterte, der wieder eine Wiederherstellung auslöste. Eine Endlos-Schleife in der Konsole, die sich selbst befeuerte. Stufe zwei war dann richtig unangenehm. Diese ganzen hängenden Großread-Verbindungen saugten den Verbindungs-Pool leer. Irgendwann kam überall nur noch „unable to check out connection from the pool after 15000ms". Es war keine Verbindung mehr frei — so sehr, dass sogar der Start des App-Servers hing, weil auch der keine Verbindung mehr bekam. Ich habe den Pool von 15 auf 20 erhöht; das half kein bisschen, weil die alten, hängenden Verbindungen den Pool festhielten. Erst ein kompletter Neustart der Datenbank gab die Verbindungen wieder frei. Das ist die unscheinbarste, aber vielleicht wichtigste Lehre: Ein scheinbar harmloser Lese-Fehler kann sich über Wiederhol-Schleifen so aufschaukeln, dass er den ganzen Verbindungs-Pool und damit die komplette App in die Knie zwingt. Wer einen Fehler eingrenzt, sollte immer auch fragen, was er als Folgeschaden auslöst. Der Fix — und warum nichts kaputtging Die Sofortmaßnahme war unspektakulär, aber sie musste sauber sein. Zuerst ein Backup: einmal der volle Blob, und das auszulagernde Notiz-Item nochmal separat gesichert. Dann habe ich das 76-KB-Item gezielt aus dem Array entfernt. Der Blob fiel von 725 KB auf 649 KB — und das reichte schon. Der volle Lese-Request kam danach wieder mit HTTP 200 zurück, in 0,34 Sekunden statt 504 oder Abbruch. Eine Nuance, die mich im Nachhinein wirklich beruhigt hat: Es ging zu keinem Zeitpunkt etwas verloren. Ein Optimistic-Lock-Guard — also ein Mechanismus, der nur dann schreibt, wenn sich die Zeile seit dem Lesen nicht bewegt hat — hatte alle fehlschlagenden Speicherversuche sauber abgewiesen, statt fremde Daten zu überschreiben. Die Kehrseite davon ist allerdings tückisch: Alle Bearbeitungen nach dem letzten erfolgreichen Speichern landeten nie in der Datenbank. Für mich als Nutzer fühlte sich das exakt an wie „speichert nicht", obwohl technisch alles korrekt abgesichert war. Die Lehren zum Mitnehmen „Speichert nicht" heißt nicht automatisch „Schreiben kaputt". Prüfe zuerst, ob das begleitende Lesen scheitert. Bei mir lag die Wahrheit komplett auf der Lese-Seite. Ein wachsender Single-Row-Blob ist eine tickende Uhr. Er läuft, bis die Auslieferung über die Zeitgrenze rutscht. Danach kippt er ohne Vorwarnung. Lange Fließtexte gehören nicht in einen gemeinsamen Blob. Struktur und Stichpunkte ja, Romane nein. Große Inhalte besser als eigene Datensätze ablegen und bei Bedarf nachladen. Denk an den Folgeschaden. Ein einzelner langsamer Read kann über Retry-Schleifen den Pool leersaugen und alles mitreißen. Optimistic Locking schützt vor Datenverlust, maskiert aber das Symptom. Wenn der Schutz greift, sieht es für den Nutzer aus wie „kaputt" — plane verständliches Fehler-Feedback gleich mit ein. Fazit Am Ende war es kein dramatischer Bug, sondern ein langsam herangewachsenes Strukturproblem, das sich hinter dem falschen Symptom versteckte. Der Verdächtige () war unschuldig, das gefühlte Problem (Speichern) war gar nicht das Problem, und die Lösung lag eine Ebene tiefer als der Reflex. Genau deshalb mag ich solche Debugging-Sessions: Man lernt nicht nur den einen Bug, sondern eine Denkweise. Wenn etwas nicht speichert, schau nicht zuerst auf den Schreibpfad — schau, ob das Lesen noch durchkommt.
Jeder Mini-Edit schob hunderte Kilobyte durch die Leitung. Nach zwei Datenbank-Umzügen haben wir endlich die Architektur statt der Symptome behandelt. — Es gibt Probleme, die löst man nicht, sondern verschiebt sie nur. Eine ganze Weile war der Datenabfluss (Egress) unserer Web-App genau so ein Fall — und ich gebe ehrlich zu, dass wir es uns dabei lange selbst schwer gemacht haben. Jede kleine Änderung am Vision-Board schob hunderte Kilobyte durch die Leitung, und das alle paar Sekunden. Das Egress-Kontingent bei Supabase schmolz dahin, und statt die Ursache anzugehen, sind wir zweimal komplett auf eine frische Datenbank umgezogen, nur um wieder Luft zu haben. Das ist Symptombekämpfung in Reinform. Und diese Umzüge taten richtig weh. Warum zwei Umzüge nicht die Lösung waren Ein Datenbank-Umzug klingt erst mal sauber, ist es aber nicht. Der Standard-Abzug nimmt nämlich nur den Datenkatalog mit — die Bilder und sonstigen Dateien im Speicher wandern nicht automatisch mit. Also mussten wir für jeden der beiden Umzüge (einmal am 9. Mai, einmal am 1. Juni) eigene Rettungsskripte schreiben, die den Datei-Speicher sichern, wieder einspielen und am Ende vergleichen, ob auch wirklich alles drüben angekommen ist. Und das Beste: Nach jedem Umzug war das Grundproblem natürlich immer noch da. Wir hatten nur das Kontingent zurückgesetzt, nicht den Verbrauch gesenkt. Es war, als würde man einen undichten Eimer regelmäßig leeren, statt das Loch zu stopfen. Dazwischen haben wir an allen möglichen Symptomen gedreht: das Speichern gedrosselt, die Echtzeit-Filter verfeinert, sogar einzelne große Inhalte von Hand aus den Daten herausgeschnitten und als JSON-Datei beiseitegelegt — eine Vision mit elf langen Plänen, allein 75 Kilobyte, haben wir so manuell geparkt, nur damit der Daten-Blob nicht weiterwächst. Er wuchs trotzdem. Die Wurzel: ein einziges riesiges JSON-Feld Irgendwann haben wir uns hingesetzt und nachgemessen, statt weiter zu reagieren. Und das Ergebnis war ziemlich eindeutig: Die Echtzeit-Updates, multipliziert mit der Größe des Daten-Blobs, machten rund 65 Prozent des gesamten Datenabflusses aus. Die Wurzel war also nicht irgendein einzelnes Feature, sondern die Architektur selbst. Technisch lag die Sache so: Die Daten eines Vision-Boards steckten komplett in einem JSONB-Blob pro Board. In der Spitze waren das rund 640 Kilobyte, zuletzt immer noch 261. Und jeder noch so kleine Edit schrieb diesen kompletten Blob zurück. Schlimmer noch: Ab etwa 700 Kilobyte wurde es brandgefährlich, weil das Laden dann an ein Zeitlimit stieß. Wir liefen also sehenden Auges auf einen Kipppunkt zu. Er funktioniert tadellos — bis er es plötzlich nicht mehr tut. Solange alles im grünen Bereich liegt, merkt man nichts. Genau das macht ihn so tückisch. Die bewusste Warte-Entscheidung Hier kommt etwas, auf das ich im Rückblick ein bisschen stolz bin: Wir haben die Wurzel-Lösung erst einmal bewusst geparkt. Die Überlegung am 9. Juni war, dass sich ein großer Struktur-Umbau ohnehin abzeichnete — und dass man dann beides in einem Schnitt erledigen könnte, statt zweimal am offenen Herzen zu operieren. Und genau so kam es. Ein neues Feature — frei befüllbare Bereiche an jeder Karte — brauchte sowieso einen Umbau, wie die Daten gespeichert werden. Zwei Fliegen, eine Klappe. Manchmal ist das Geduldigste tatsächlich das Effizienteste. Der Schnitt: Skelett bleibt, Inhalte ziehen aus Die Lösung selbst ist im Kern simpel. Der Blob behält nur noch das Skelett: Struktur, Titel, Reihenfolge, Anheftungen, Eltern-Bezüge und ein paar Zähler. Die schweren Inhalte — die langen Plan-Texte und Aufgabenlisten — wandern als kleine Einzel-Zeilen in eine bereits bestehende Tabelle, jeweils über einen generischen Schlüssel adressiert. Das Schöne daran: Diese Tabelle hatte schon ein erprobtes System für Sperren, Konflikte und Echtzeit. Wir mussten also nichts Neues bauen, sondern haben das Bewährte wiederverwendet. Eine einzige Ausnahme gibt es — die Mission bleibt im Blob, weil sie ein Einzelstück ohne eigene Kennung ist. Wichtig war mir, dass wir uns bewusst gegen die vollständige Normalisierung entschieden haben. Hätten wir alles sauber in Einzeltabellen zerlegt, wären Dinge wie das Umsortieren, das kaskadierende Löschen oder die Anheftungs-Regeln plötzlich kompliziert geworden. So bleiben die im Skelett trivial. Unterm Strich: rund 90 Prozent des Nutzens bei einem Bruchteil des Risikos. Das Ergebnis kann sich sehen lassen. Ein Inhalts-Edit schreibt jetzt eine kleine Zeile im Kilobyte-Bereich statt des kompletten 261-Kilobyte-Blobs — das sind über 99 Prozent weniger auf dem Schreibpfad. Das Öffnen eines Boards überträgt 60 statt 261 Kilobyte, also gut ein Viertel. Inhalte laden außerdem nur noch verzögert, wenn man eine Karte tatsächlich öffnet. Der 65-Prozent-Posten beim Egress ist damit strukturell weg. Wie es ablief — und wo es spannend wurde Das Ganze lief als KI-orchestriertes Großprojekt über drei Tage, in vier Phasen und zehn Arbeitspaketen. Das Reizvolle daran: Zwei KI-Teams — eins für die Web-App, eins für den Server — mussten eine harte Reihenfolge beim Umschalten einhalten und sich darüber über eine geteilte Notiz abstimmen, samt schriftlichem Kontrakt und gemeinsamem Rauch-Test, der am Ende vier von vier Punkten bestand. Die eigentliche Migration war zweistufig und so gebaut, dass man sie gefahrlos wiederholen kann. Zuerst das Nachfüllen — 134 Plan-Zeilen und 7 Aufgaben-Zeilen, wobei neuere Daten niemals überschrieben werden. Dann die Verifikation, dass wirklich jedes Element mit Inhalt seine eigene Zeile hat und keine Waisen übrig bleiben. Erst danach das Bereinigen der 16 Boards. Davor stand selbstverständlich ein vollständiges Backup, und ich hatte die SQL-Skripte vorher gegen eine lokale Wegwerf-Datenbank getestet, inklusive eines Negativtests: Das Bereinigen ohne vorheriges Nachfüllen muss hart abbrechen und die Daten unangetastet lassen. Tat es. Der Race-Bug: erst unter Last sichtbar Und dann kam der Moment, der jede Story braucht. Beim Live-Test verschwanden frisch angelegte Plan-Einträge sofort wieder — vor meinen Augen. Man tippt etwas ein, es erscheint kurz, und ist im nächsten Augenblick weg. Die Ursache war ein Wettlauf-Fehler. Mehrere Speichervorgänge derselben Zeile liefen parallel und überholten sich gegenseitig. Sie liefen dann mit einem veralteten Sperr-Token in Konflikt-Schleifen, und nach zwei Fehlversuchen rollte die Oberfläche den Stand einfach zurück — daher das „erscheint kurz und verschwindet". Das Tückische: Sichtbar wurde das überhaupt nur, weil zufällig parallel ein Backup lief und alles auf 13 bis 15 Sekunden pro Anfrage ausbremste. > Last macht Wettlauf-Fehler sichtbar, die unter normalem Tempo monatelang schlummern können. Der Fix war dann unspektakulär, aber wirksam: eine Schreib-Warteschlange pro Zeile, sodass die Speichervorgänge sauber hintereinander ablaufen, statt sich zu überholen. Dazu ein neuer Test, der genau diese parallelen Speicherungen simuliert, damit der Fehler nicht heimlich zurückkommt. Ergebnis und ein Gefühl Wir waren wirklich knapp vor dem Kontingent-Limit, und wir haben es gerade noch geschafft. Jetzt reicht das Kontingent locker, und ein dritter Datenbank-Umzug ist vom Tisch. Diese Erleichterung nach Monaten Leidensweg ist schwer zu beschreiben. Was mir aber am meisten hängen geblieben ist: Das war echte Teamarbeit. Ich habe die Richtung vorgegeben, die kritischen Freigaben erteilt — Backup, der destruktive Bereinigungsschritt — und live getestet. Den koordinierten Umbau selbst haben zwei KI-Teams gestemmt. Genau diese Aufteilung, Mensch gibt Richtung und Freigaben, KI baut koordiniert, fühlt sich nach der richtigen Art zu arbeiten an. Die andere Seite derselben Blob-Geschichte: Wie wir Routine-Abläufe fest verdrahten: Wenn die KI vorschnell „ja" sagt:
Wie aus 'Muss es nicht eine Taste zum Sprechen geben?' Schritt für Schritt ein eigenes Werkzeug für die Spracheingabe bei der Arbeit mit Claude wurde. — Angefangen hat das eigentlich ganz unspektakulär. Ich saß am Mac und dachte mir, es müsste doch irgendwie eine Taste geben, mit der ich einfach lossprechen kann, statt alles mühsam zu tippen. Und tatsächlich gibt es diese Taste. Auf dem Mac ist die Diktierfunktion direkt eingebaut, man muss sie nur finden und aktivieren. Genau das habe ich gemacht und sie dann eine ganze Weile genutzt. Die eingebaute Lösung war da — aber sie fühlte sich nie gut an So richtig glücklich wurde ich damit aber nie. Das Ergebnis war meistens unpräzise und ungenau, ganze Halbsätze landeten verdreht im Text, und jedes Mal kam noch dieser nervige Bestätigungston dazu. Es hat sich einfach nicht gut angefühlt. Ich habe es trotzdem eine Zeit lang durchgezogen, weil die Grundidee mich nicht losgelassen hat. Sprechen statt Tippen, das fühlte sich nach der richtigen Richtung an, auch wenn die Umsetzung noch holperte. Der Umweg über ChatGPT Bei Claude war die Spracherkennung ohnehin lange Zeit ziemlich schwach. Auf Englisch ging es einigermaßen, aber auf Deutsch überzeugte es mich überhaupt nicht. Genau an dieser Stelle war ChatGPT immer richtig stark. Die deutsche Spracherkennung dort war von Anfang an auf einem ganz anderen Niveau, und damit hatte ich ohnehin schon lange gearbeitet. Es hat einfach zuverlässig funktioniert, und genau diese Zuverlässigkeit habe ich gesucht. Daraus ist dann ein Arbeitsstil entstanden, der im Rückblick fast ein bisschen kurios wirkt. Mit der Zeit habe ich nämlich immer mehr mit Opus gearbeitet, also mit Claude, gleichzeitig wollte ich aber die gute Spracherkennung von ChatGPT nicht aufgeben. Also hatte ich ständig ein kleines Zusatzfenster von ChatGPT geöffnet, nur für die Sprachaufnahme. Dort habe ich hineingesprochen, den fertigen Text herauskopiert und ihn drüben bei Claude wieder eingefügt. Hin und her, Fenster für Fenster. Das klingt umständlich, und das war es streng genommen auch. In der Praxis war es aber trotzdem deutlich schneller, als alles selbst zu tippen. Es war jedes Mal ein kleiner, fast lustiger Moment, weil ich mir dachte, dass das doch eigentlich niemand so machen sollte. Der Moment, in dem der Groschen fiel Und genau in diesem Moment ist mir klar geworden, dass das eigentlich eine richtig gute Art zu arbeiten ist. Definitiv schneller als Tippen, das stand außer Frage. Mich hat nur gewundert, warum das niemand sauber in ein Werkzeug gegossen hat, das beides verbindet — die gute Spracherkennung auf der einen und die Arbeit mit Claude auf der anderen Seite. Genau daraus ist dann die Idee entstanden, dass ich mir das selbst bauen muss. Wenn es kein Werkzeug gibt, das gute Spracherkennung und die Arbeit mit Claude unter einen Hut bringt, dann baue ich es eben selbst. Und so bin ich Schritt für Schritt tiefer in das Thema hineingerutscht. Vom Workaround zum eigenen Werkzeug Erst stand nur die Grundidee im Raum, dieses Sprechen statt Tippen sauber nutzbar zu machen. Dann ging es in die Richtung Kommandozeile, weil ich gemerkt habe, dass ich dort die meiste Kontrolle und Geschwindigkeit herausholen kann. Und schließlich kam die spannendste Frage überhaupt dazu, nämlich wie man das Ganze optimieren kann und welche Modelle am besten aus Sprache Text machen. Genau an diesen Punkten teste ich gerade. Ich probiere verschiedene Varianten aus, einmal mit Tastendruck und einmal ganz ohne — also ob ich das Aufnehmen aktiv starte oder ob es im Hintergrund einfach mitläuft. Dazu vergleiche ich verschiedene Modelle daraufhin, welches am genauesten und am schnellsten aus Sprache Text macht, gerade auf Deutsch. Aus einer simplen Frage am Mac ist ein eigenes Werkzeug geworden, an dem ich kontinuierlich weiterfeile. Nicht, weil ich unbedingt etwas bauen wollte — sondern weil mir die fehlende saubere Lösung im Alltag immer wieder aufgefallen ist. Fazit Das ist der aktuelle Stand. Im Rückblick mag ich an dieser Geschichte vor allem, dass sie nicht mit einem großen Plan angefangen hat, sondern mit einer kleinen, fast naiven Frage am Mac. Genau diese Fragen sind oft die besten Ausgangspunkte: Man stolpert über etwas, das umständlich ist, findet einen holprigen Umweg, und irgendwann merkt man, dass der Umweg eigentlich der bessere Weg ist — er ist nur noch nicht sauber gebaut. Das hier ist Teil eins; in den nächsten Teilen geht es um den Modell-Vergleich und darum, wie sich das Werkzeug konkret aufbaut.
Ein getipptes Keyword löst bei uns einen festen KI-Ablauf aus — und jeder Schritt muss committet werden, bevor der nächste kommt. Warum das der Trick ist. — Wenn man jeden Tag mit KI arbeitet, merkt man schnell, dass sich bestimmte Abläufe ständig wiederholen. Eine Aufgabe ist fertig, also muss sie dokumentiert werden. Code soll live gehen, also müssen vorher die Tests laufen. Ein Datenbank-Schema ändert sich, also braucht es eine kontrollierte Migration. Lange habe ich diese Abläufe als kleine Anleitungs-Dateien im Projekt liegen gehabt, verstreut über das ganze Repository. Das Problem dabei: Jede dieser Dateien musste man einzeln pflegen, und keine Garantie, dass die KI sich auch wirklich an alle Schritte hält. Inzwischen läuft das anders. Wir haben die wichtigsten dieser Abläufe als zentrale KI-Workflows per Keyword gebaut. Man tippt ein Stichwort — , , — und das löst einen festen, hinterlegten Ablauf aus. Dieser Beitrag erklärt, wie das funktioniert, warum manche dieser Abläufe aus vielen kleinen Schritten bestehen und andere aus einem einzigen, und vor allem: warum jeder einzelne Schritt „committet" werden muss. Genau das ist nämlich der Kern, der alles zusammenhält. Was hinter dem Keyword passiert Die Mechanik ist eigentlich simpel. Hinter jedem Keyword steckt ein Eintrag in einer zentralen Datenbank. Tippt man das Keyword, läuft im Hintergrund eine kleine Schleife: Erst wird das Keyword zu einer Workflow-Kennung aufgelöst, dann holt sich die KI den nächsten Schritt ab, führt ihn aus, reicht das Ergebnis ein — und bekommt daraufhin den übernächsten Schritt. Das geht so weiter, bis der Workflow als abgeschlossen gemeldet wird. Der entscheidende Unterschied zu früher ist die zentrale Ablage. Statt zehn verstreuter Anleitungs-Dateien gibt es jetzt eine einzige Quelle. Jede KI-Session zieht exakt denselben Stand — kein Auseinanderdriften, kein Nachpflegen an mehreren Stellen. Wer den Ablauf verbessert, verbessert ihn für alle auf einmal. Der Kern-Mechanismus: jeder Schritt wird committet Jetzt zum eigentlichen Herzstück. Jeder Workflow besteht aus nummerierten Schritten. Zu jedem Schritt bekommt die KI eine Anweisung und dazu ein festes Antwort-Format. Und sie muss ihr Ergebnis einreichen — wir nennen das „committen" —, und zwar in genau diesem Format, bevor sie überhaupt den nächsten Schritt zu sehen bekommt. Das klingt nach einer Kleinigkeit, ist aber der ganze Trick. Vier Gründe, warum: Es erzwingt, dass jeder Schritt wirklich passiert. Die KI kann keinen Schritt überspringen oder nur oberflächlich abhaken, denn ohne gültigen Commit gibt es den nächsten Schritt schlicht nicht. Sie kommt nicht weiter, wenn sie schummelt. Es erzwingt überprüfbare Ergebnisse. Weil jeder Schritt ein festgelegtes Format einhalten muss, bekommt man strukturierte, prüfbare Antworten statt Freitext-Prosa, bei der man nie genau weiß, ob die Arbeit gemacht wurde. Es trägt den Kontext sauber weiter. Das eingereichte Ergebnis bleibt in der Session erhalten, und spätere Schritte greifen darauf zu. So wandert das Wissen kontrolliert von Schritt zu Schritt. Es ist das Tor für bedingte Schritte. Bei einer Datenbank-Migration etwa läuft der Ausführungs-Schritt nur dann, wenn der vorige Freigabe-Schritt tatsächlich eine echte Freigabe eingereicht hat. Sonst wird das Ausführen automatisch übersprungen. Eine Sicherheitsregel wird damit maschinell erzwungen, statt nur als höfliche Bitte im Text zu stehen. Ein Hinweis im Prompt ist eine Bitte. Ein Commit-Zwang pro Schritt ist eine Garantie. Genau diese Verschiebung von „bitte mach das" zu „du kommst sonst nicht weiter" macht den ganzen Unterschied. Warum manche Abläufe viele Schritte haben — und andere nur einen Nicht jeder Workflow ist gleich gebaut, und das hat einen Grund. Die mehrstufigen Abläufe sind für Pflicht- und Sicherheits-Sequenzen gedacht, bei denen jeder einzelne Schritt nachweislich passieren muss. Die feine Granularität ist Absicht: Ein Doku-Workflow mit neun Schritten garantiert, dass keiner der neun Aspekte vergessen wird. Beispiele sind die Pflicht-Doku nach einer Aufgabe (9 Schritte), die Datenbank-Migration (8 Schritte) und das Deployment (8 Schritte). Die einstufigen Abläufe sind dagegen für Einmal-Einschätzungen gedacht, die in einem Rutsch erledigt sind — eine Anweisung, ein Ergebnis-Block, kein ständiges Hin und Her mit Werkzeugen. Dazu gehören Summary, Recap, Triage und das RAG-Update, jeweils mit einem einzigen Schritt. Die einzelnen Workflows im Überblick KIDOKU (9 Schritte) und Pflicht (9 Schritte): Beides sind Doku-Sequenzen nach einer Arbeits-Session beziehungsweise nach einer manuellen Aufgabe. Sie führen sauber durch alles vom Umsetzen über den Architektur-Check und die Verifikation bis zum Arbeits-Log und der Abschluss-Einschätzung. Die Doku-Schritte greifen dabei auf Such- und Schreib-Werkzeuge der Wissensbasis zu, nicht direkt auf die Datenbank. DB Migration (8 Schritte): Der Sicherheits-Workflow für Änderungen am Live-Schema. Drei nicht verhandelbare Verteidigungslinien werden maschinell erzwungen: Es darf nur auf einem dedizierten Migrations-Zweig gearbeitet werden, es braucht eine ausdrückliche Freigabe mit konkretem Bezug zum tatsächlichen Befehl, und interaktive Rückfragen werden sofort abgebrochen, damit nichts unbeabsichtigt durchläuft. > Mit dem Keyword für Datenbank-Migrationen haben wir keine Probleme mehr gehabt. Das ist früher öfter mal durcheinandergelaufen, aber seitdem wir das hierüber machen, läuft es einwandfrei. Deployment (8 Schritte): Eine Vorflug-Kette aus Typprüfung, Stilprüfung, Tests und Build, dazu eine automatische Reparatur-Schleife und am Ende der Push. > Deployment finde ich persönlich sehr angenehm, weil es so ein Abschicken-und-Vergessen ist. Wir haben einen Git-Haken eingebaut, der gewisse Tests durchführt — alle Typprüfungen, alle echten Tests müssen grün sein, sonst geht kein Push hoch. Ein Arbeiter schaut: Bin ich auf dem richtigen Zweig, habe ich alles drin, laufen alle Tests? Und wenn nein, repariert er die Tests gleich, versucht das Deployment mit Push, und sollte es nochmal einen Fehler geben, behebt er den auch. Wenn man sich sicher ist, dass keine Bugs und keine Merge-Fehler dabei sind, ist das wirklich einfach — sonst ist man immer wieder selbst dran und muss es einzeln prüfen und mit der KI durchgehen. So schickt man es einfach ab, und irgendwann geht es live. DB Backup (4 Schritte): Ein Voll-Backup in einem einzigen Lauf — und zwar immer alle drei Artefakte zusammen: ein Abzug der Nutzer-Datenbank, ein Abzug der zentralen Datenbank und alle tatsächlich ausgerollten Server-Funktionen. Nie nur eine Datenbank, das ist bewusst unverhandelbar. Summary (1 Schritt): Die Entscheidung über die Session-Übergabe. Die KI schätzt die Lage ein — wie voll ist der Kontext, was ist noch offen — und gibt eine Empfehlung, ob man weitermacht, verdichtet oder in eine neue Session übergibt. > Summary nutze ich vor allem, wenn man anfängt, Themen zu wechseln, oder merkt, die KI-Leistung lässt nach und man will lieber in eine zweite Session rüber — dann hat man einen sauberen Abschluss. Seitdem Opus mit einer Million Kontext im Einsatz ist, ist das relativ selten geworden; die Sessions laufen teils vier-, fünfhunderttausend Tokens lang. Früher wurde es mehr genutzt. Recap (1 Schritt): Eine Verständnis-Rückspiegelung des letzten Inputs, bevor die KI loslegt. Sie sagt also erst, wie sie die Aufgabe verstanden hat, und fängt erst dann an. > Recap nutzen wir sehr oft. Einfach damit ich weiß: Hat die KI wirklich verstanden, was das Ziel eigentlich ist? Finde ich immer sehr sinnvoll. Triage (1 Schritt): Ein Selbst-Entscheid-Tor. Statt bei jeder Kleinigkeit zurückzufragen, entscheidet die KI umkehrbare Fragen selbst anhand der Projekt-Leitplanken. Nur echte Irreversibles — Daten löschen, Migration, Sicherheit, Breaking Change — eskalieren zurück an den Menschen. Das killt die Frage-Inflation. RAG-Update (1 Schritt): Pflegt eine Erkenntnis aus der Session in die bestehende Wissens-Doku ein. Gibt es eine eindeutige Fundstelle, geschieht das direkt; gibt es mehrere, wird zurückgefragt — kein blindes Überschreiben. Content Creation (5 Schritte): Verdichtet etwas in der Session Gebautes zu einem Content-Briefing und legt es als Aufgabe in eine Warteschlange. Genau dieser Artikel ist übrigens so entstanden. > Content Creation ist unser neuestes Keyword, und zusammen mit dem RAG-Update nutzt es schon eine ganze Pipeline. Wenn wir was Cooles entwickelt haben, schreibt man direkt „Content Creation" dahinter — dann macht das Werkzeug Vorschläge, an welcher Stelle im System gepostet werden soll: Ist das ein LinkedIn-Beitrag, eher ein Blogbeitrag, oder eine Kombination, dass erst ein Blogbeitrag angelegt und danach automatisch der ganze Ablauf für LinkedIn, Instagram und so weiter ausgelöst wird? Ein bisschen Technik dahinter Was das Ganze tragfähig macht, ist die zentrale Ablage in einer einzigen Datenbank statt verstreuter lokaler Anweisungen. Ein neuer Workflow ist dadurch im Grunde nur ein Daten-Eintrag — es braucht keinen eigenen Programmcode pro Ablauf, ein einziger generischer Lader liest sie alle. Die bedingten Schritte werden gegen die bereits eingereichten Ergebnisse früherer Schritte ausgewertet, und die Anweisungen bevorzugen bewusst die Werkzeuge der Wissensbasis gegenüber direktem Datenbank-Zugriff. Direkt an die Datenbank geht es nur dort, wo es inhärent nötig ist — bei Migration und Backup. Unterm Strich macht das KI-gestützte Routine-Abläufe reproduzierbar, überprüfbar und über alle Sessions hinweg konsistent. Und das ist genau das, was ich von so einem System will. Fazit Der eigentliche Gewinn liegt nicht in der Bequemlichkeit eines getippten Stichworts — der liegt in der Verlässlichkeit. Solange ein Ablauf nur als Bitte im Prompt steht, hängt seine Ausführung von der Tagesform der KI ab. Sobald jeder Schritt einzeln committet werden muss, wird aus der Bitte eine erzwingbare Garantie. Genau das hat bei uns ganze Fehlerklassen verschwinden lassen, allen voran die früher chaotischen Datenbank-Migrationen. Der Ausblick ist klar: Weitere Workflows sind in Arbeit, und vor allem wollen wir die einzelnen Content-Pipelines miteinander verketten — Blog, dann LinkedIn, dann Instagram — zu einem durchgehenden Fluss. Wenn das steht, reicht ein Keyword, und aus einer Erkenntnis wird automatisch ein ganzer Strauß fertiger Beiträge. Warum feste Regeln allein die KI nicht bändigen: Die Notbremse fürs Orchestrierungssystem: Wenn die KI vorschnell „ja" sagt:
Die Session-URL war plötzlich weg aus dem Terminal. Wie wir sie über einen Server-Endpoint wiederfanden — und was das für die Arbeit über der IDE bedeutet. — Manchmal entsteht das schönste Feature aus einem Moment, in dem erst mal alles kaputt aussieht. Diese Geschichte ist so eine. Es geht um steuerbare Remote-Coding-Sessions in boostN.ai — also darum, einen Coding-Auftrag loszuschicken, ihn von einem Agenten im echten Code abarbeiten zu lassen, und jederzeit per Verknüpfung live reinspringen zu können, wenn man will. Eine Ebene über der IDE. Und beinahe wäre das an einer einzigen verschwundenen Zeile im Terminal gescheitert. Was wir vorher gemacht haben Unser Devi-Runner im boostN-CLI startet Coding-Agenten als fernsteuerbare Sessions. Damit man eine laufende Session auch in der Web-App anklicken kann, brauchten wir die zugehörige Session-Verknüpfung. Die haben wir bisher ganz pragmatisch direkt aus der Ausgabe im Terminal gelesen — ein bisschen Mustererkennung auf die Session-Kennung, fertig. Diese Verknüpfung haben wir dann in der Web-App als klickbaren Knopf angezeigt. Funktionierte zuverlässig, war simpel, und niemand hat sich Gedanken gemacht, dass diese eine Zeile mal nicht mehr da sein könnte. Warum es plötzlich nicht mehr ging Genau das passierte aber. Das aktuelle Claude-CLI druckt diese Verknüpfung im interaktiven Modus — also genau in dem Modus, den unser Runner für den automatischen Start des Auftrags braucht — gar nicht mehr ins Terminal. Weder im Klartext noch als anklickbaren Verweis. Stehen bleibt nur noch ein lapidares „Remote Control active". Die Information, die wir brauchten, war einfach weg. Wir haben daraufhin alle vier dokumentierten Modi des CLI systematisch durchprobiert. Das Ergebnis war ernüchternd: Kein lokaler Modus liefert gleichzeitig die Verknüpfung und den automatischen Start des Auftrags. Der einzige Modus, der die Verknüpfung noch ausgibt, ist ein Server-Modus — und der nimmt keinen lokal mitgegebenen Auftrag an. Auf den ersten Blick sah das nach einer Sackgasse aus. Was wir herausgefunden haben Dann kam der Moment, der die Geschichte dreht. Die Verknüpfung war nämlich gar nicht verschwunden — sie war nur umgezogen. Statt im Terminal zu stehen, liegt sie jetzt auf der Server-Schnittstelle des Anbieters. Es gibt dort einen Endpunkt, der alle laufenden Remote-Sessions eines Kontos auflistet, jeweils mit Kennung, Titel und Status. Die Anmeldung läuft über das ohnehin vorhandene Zugangs-Token aus dem System-Schlüsselbund. Und aus der Session-Kennung lässt sich die steuerbare Verknüpfung eindeutig zusammenbauen. Wichtig: Das ist reiner Lese-Zugriff, wir holen uns nur eine Liste ab. Der Plan Daraus ergibt sich ein sauberer Weg. Der Runner startet die Session weiterhin lokal mit dem Auftrag, genau wie bisher — versieht sie aber zusätzlich mit einem eindeutigen Vorgangs-Code als Namen. Danach fragt er die Liste der laufenden Sessions ab, findet die eigene über genau diesen Code, baut die steuerbare Verknüpfung und schickt sie an die Web-App. Vom Umfang her reden wir über schätzungsweise 120 bis 180 Zeilen Code — überschaubar. Der genutzte Endpunkt ist nicht offiziell dokumentiert, er stammt aus einer Forschungs-Vorschau und könnte sich jederzeit ändern. Genau deshalb nutzen wir ihn bewusst ausschließlich lesend — wir holen uns eine Liste ab, mehr nicht. Verschwindet er, fällt nur dieser Komfort weg, nicht die ganze Funktion. Warum das gut für Nutzer ist Der eigentliche Punkt ist nicht die wiedergefundene Verknüpfung, sondern was sie ermöglicht. Remote-Sessions heben einen eine Ebene über die IDE. Statt selbst tief im Editor mitzulesen, schickt man einen Auftrag los, ein Agent arbeitet im echten Code — und nur falls es nicht vorangeht oder eine Rückfrage entsteht, springt man bewusst rein. Oder eben nicht. Gerade wer an vielen Projekten parallel arbeitet, merkt schnell, dass die IDE für diesen Überblick eine Stufe zu tief sitzt. > IDEs sind — so schön sie sein mögen — eine Stufe zu tief drin. Gerade wenn man an vielen Projekten arbeitet, will man auf eine höhere Ebene. Mit der Remote-Verknüpfung schickt man einen Auftrag los, jemand arbeitet daran, und falls man merkt, es kommt nicht voran oder es entsteht eine Rückfrage, springt man bewusst rein — oder eben nicht. Das macht es besonders gegenüber einem normalen IDE-Auftrag, wo ich den ganzen Text vor mir habe, den Verweis reinkopieren muss und dann sehr viel am Lesen bin. Ich hoffe, dass diese Web-Geschichte für uns Anbieter verfügbar bleibt und andere nachziehen — denn ein eigenes Sprachmodell zu hosten, nur um den Chat fernsteuerbar zu machen, ist viel zu weit weg. Die Remote-Verknüpfung macht aus einem Coding-Auftrag also etwas, das man delegieren und bei Bedarf wieder übernehmen kann. Und genau das ist der Unterschied zum klassischen Mitlesen im Editor. Ein Wunsch zum Schluss Bleibt ein Wunsch an die Plattform-Anbieter: solche fernsteuerbaren Agent-Schnittstellen bitte offen und stabil halten. Dann können Werkzeug-Anbieter wie wir darauf aufbauen, ohne ein eigenes Sprachmodell hosten zu müssen, nur um eine Session remote-fähig zu machen. Das wäre ein unverhältnismäßig großer Aufwand für etwas, das es eigentlich schon gibt — man muss es nur erreichbar lassen. Wie wir wiederkehrende Abläufe fest verdrahten: Modelle für Automatisierung ohne Oberfläche:
Rohe HTML-Mockups verbrennen Tokens, bevor die KI sie überhaupt versteht. Ein Strip-Schritt im Server senkte eine Datei von 26.900 auf 650 Tokens. — Es gibt diese kleinen Effizienz-Gewinne, über die man sich morgens beim Kaffee mehr freut als über manch großes Feature. Dieser hier ist so einer. In unserem Orchestrierungssystem können große Projekte jetzt Datei-Anhänge tragen — HTML-Mockups, Konzept-Dokumente, solche Sachen. Praktisch. Bis ich gemerkt habe, was passiert, wenn die steuernde KI brav der Anweisung „lies erst mal alle Dokumente" folgt und sich dann ein rohes HTML-Mockup reinzieht. Kurz gesagt: Da verbrennt eine Menge Geld, ohne dass die KI dadurch auch nur ein bisschen schlauer wird. Warum rohes HTML so teuer ist Das Grundproblem ist, dass eine KI für jedes Zeichen bezahlt wird, das sie liest — egal, ob das Zeichen inhaltlich etwas wert ist oder nicht. Und ein HTML-Mockup besteht zum allergrößten Teil eben nicht aus Inhalt, sondern aus Drumherum: Markup, Inline-Styles, Skripte, Whitespace. Das sind genau die Zeichen, die für das Verständnis fast keinen Wert haben, aber voll mitbezahlt werden. Als Faustregel rechne ich bei HTML mit ungefähr 3,7 Zeichen pro Token — also ziemlich dicht. Bei drei bis fünf angehängten Mockups summiert sich das schnell auf über 100.000 Tokens, und zwar auf einen Schlag, gleich am Anfang des Projekts. Die KI hat dann noch nichts Sinnvolles getan, aber das Budget ist schon ordentlich angeknabbert. Der naheliegende Reflex reicht nicht Mein erster Gedanke war der, den vermutlich jeder hat: Schreib der KI doch einfach in den Auftrag „lies nur die relevanten Teile". Klingt vernünftig, funktioniert aber nicht. Denn damit die KI entscheiden kann, was relevant ist, muss sie die Datei erst mal lesen — und in dem Moment, in dem sie sie liest, sind die Tokens schon weg. Der Hinweis im Auftrag kommt also grundsätzlich zu spät. Wer die Datei erst beim Agent lädt und dann aufräumt, hat schon bezahlt. Das Aufräumen muss passieren, bevor die KI die Datei überhaupt zu Gesicht bekommt. Die Lösung: aufräumen, bevor die KI hinschaut Also haben wir den Aufräum-Schritt direkt in den Server gelegt, nicht in die KI. Ein neues Werkzeug — bei uns heißt es — lädt einen Anhang, wirft - und -Blöcke raus, entfernt die restlichen Tags, dekodiert die HTML-Sonderzeichen und schiebt überflüssigen Whitespace zusammen. Was die KI am Ende bekommt, ist nur noch der reine Text. Bewusst schlicht gehalten: Das Ganze läuft über ein paar Regex-Schritte, keine schwere Parser-Bibliothek im Hintergrund. Für Mockups und Reports ist das völlig ausreichend, und es bleibt schnell. Ein optionaler Parameter kappt sehr lange Texte zusätzlich auf eine maximale Länge, falls man das braucht. Wichtig ist auch, was das Werkzeug nicht anfasst: Bilder, PDFs und andere Binärdateien werden nicht durch den Strip gejagt — bei denen ergibt das keinen Sinn. Stattdessen liefert das Werkzeug dafür eine signierte, zeitlich begrenzte Download-Verknüpfung. Und Markdown-Konzepte lässt es ebenfalls in Ruhe, weil Markdown ohnehin schon KI-freundlich ist. Das Werkzeug schaut sich also den Dateityp an und entscheidet, ob Aufräumen überhaupt etwas bringt. Was dabei rausgekommen ist Die Zahlen sind aus einem echten Test am 7. Juni 2026, nicht hochgerechnet aus dem Bauch heraus: Die Datei hatte roh 99.469 Zeichen, also rund 26.900 Tokens. Nach dem Strip waren es 2.585 Zeichen, ungefähr 650 Tokens. Das sind 98 Prozent weniger. Eine zweite Datei im selben Projekt — ein Markdown-Konzept mit 22.842 Zeichen — wurde korrekt nicht angefasst, weil Markdown schon sauber ist. Genau so soll es sein. Über beide Anhänge zusammengerechnet fiel der Verbrauch von etwa 32.600 auf 6.350 Tokens, also rund 80 Prozent gespart. Hochgerechnet auf den typischen Fall mit drei bis fünf Mockups heißt das: statt 100.000 bis 130.000 Tokens nur noch ein paar Tausend. Und das, ohne dass die KI inhaltlich irgendetwas verliert — sie bekommt ja weiterhin den vollständigen Text, nur eben ohne das Markup-Gerüst drumherum. Einordnung Für sich genommen ist das ein kleiner Baustein. Aber es ist genau die Art von Baustein, die ich mag: Token-Budget bewusst behandeln heißt für mich, der KI nur das zu geben, was inhaltlich zählt, und den Ballast schon serverseitig wegzuräumen. Kontext einzusammeln soll günstig bleiben — damit die KI ihr Budget für das eigentliche Projekt ausgibt und nicht dafür, sich durch HTML-Tags zu lesen. Und das Schöne ist: Solche Einsparungen merkt man nicht an einer einzelnen Stelle, sondern über den ganzen Tag verteilt. Sie sind leise, aber sie addieren sich. Mehr zum bewussten Umgang mit Rechenleistung: Warum das Kostenmodell hinter KI gerade kippt: Wenn die KI zu viel auf einmal will:
Unsere Spracherkennung schnitt mal eben den halben Satz vorne ab. Der Übeltäter war nicht das Mikro, sondern das Keyword-Glossar selbst — per A/B-Test belegt. — Bei manchen Fehlern sucht man tagelang an der falschen Stelle, und am Ende stellt sich heraus: ausgerechnet die Funktion, die das Problem lösen sollte, hat es verursacht. So ein Fall war das hier. Unsere lokale Spracherkennung im boostN-CLI läuft über whisper.cpp, und damit das Modell unsere Fachbegriffe besser erkennt — Claude, RAG, MCP, boostN, DEVI Runner und so weiter —, geben wir ihm eine Keyword-Liste mit. Diese Liste wird whisper als sogenannter übergeben. Im Grunde ist das ein kleines Glossar, das vor der eigentlichen Transkription mitläuft. Genau dieses Glossar hat mir am Satzanfang regelmäßig den halben Satz weggefressen. Und das Kuriose daran ist: Es passierte ausgerechnet bei den Sätzen, für die das Glossar überhaupt gedacht war. Das Symptom: mal top, mal vorne abgeschnitten Die Transkription lief lange Zeit unauffällig. Aber dann gab es immer wieder Aufnahmen, bei denen vorne ein ganzer Teil fehlte. Nicht ein einzelnes Wort, sondern der komplette Satzanfang. Die Ausgabe begann dann mittendrin, irgendwo in der Mitte des Gedankens. Ein konkretes Beispiel aus dem Log: eine Aufnahme von 24 Sekunden, in die ich eine ganze Liste von Begriffen gesprochen hatte. Herausgekommen sind aber nur 11 Wörter — und zwar erst ab „RAG Update, Promptflow Studio, Superbase, Repository, Wave, Tickets …". Der ganze vordere Teil war einfach weg. Damit man eine Vorstellung von der Größenordnung hat: Über 128 echte Transkriptionen liegt mein normaler Durchsatz im Schnitt bei 22,6 Wörtern pro Sekunde, je nach Sprechtempo zwischen ungefähr 2,4 und 82,2. Diese eine 24-Sekunden-Aufnahme kam auf magere 5,2 Wörter pro Sekunde. Das ist rund ein Viertel des Normalen — und der Grund war nicht, dass ich langsam gesprochen hätte, sondern schlicht, dass die halbe Aussage fehlte. Die reine Transkriptionszeit war mit 2,12 Sekunden völlig unauffällig. Es war also kein Performance- oder Timeout-Problem. Es fehlte kein Tempo — es fehlte Inhalt. Diese Unterscheidung hat die ganze Fehlersuche in die richtige Richtung gedreht. Der falsche Verdacht: das Mikrofon Mein erster Gedanke ging — wie wahrscheinlich bei den meisten — zum Eingangssignal. Klassischer Verdacht: Der Wortbeginn ist zu leise, man holt am Anfang noch Luft, das Mikro fängt die ersten Silben nicht sauber ein. Ich war sogar schon so weit, gedanklich „die ersten Wörter wegzuschießen", weil ich fest davon ausging, dass das Audio am Anfang nicht taugt. Ein zweiter Verdächtiger war ein bestimmter Schalter in unserem Aufruf, , der Nicht-Sprach-Tokens unterdrückt. Vielleicht, so der Gedanke, schluckt der zu viel? Beides klang plausibel. Beides war falsch. Der A/B-Test: dieselbe Aufnahme, drei Varianten Statt weiter zu raten, habe ich exakt dieselbe Aufnahme dreimal durch das kleine Modell geschickt — nur mit unterschiedlichen Schaltern: (A) Mit Glossar: Anfang fehlt, Ausgabe ab „… RAG Update, Promptflow Studio …", 11 von geschätzt über 40 Wörtern. (B) Mit Glossar, aber ohne : identisch, der Anfang fehlt weiterhin. Damit war dieser Schalter als Ursache raus. (C) Ohne Glossar: der Satz vollständig — „Noch mal Boosten – Clouder, Notes, Hierarchie, Rack, Big Project, Orchestrator, Execution Pipeline, Commitment, LLM, MCP, Vision Board, … Wave, Tickets, Hierarchie und Sonnet." Der Vergleich von (A) und (C) ist der Beweis: Es lag nicht am Audio. Dasselbe Audio liefert mit Glossar einen abgeschnittenen Satz und ohne Glossar den vollständigen. Der Auslöser war also das Glossar selbst. Die echte Ursache: whisper hält den Anfang für eine Wiederholung Was passiert da technisch? whisper.cpp bekommt das Glossar als Vorlauf-Text. Wenn der gesprochene Satz dann selbst mit Wörtern beginnt, die in genau diesem Vorlauf stehen, hält das Modell den Anfang für eine Wiederholung des Prompts — und überspringt ihn. Es denkt sich sinngemäß: „Das hatten wir doch gerade schon." Beim kleinen Modell (small) ist dieser Effekt besonders ausgeprägt, weil es mit geringerer Konfidenz arbeitet und schneller danebenliegt. Und das ist der eigentliche Treppenwitz: Der Effekt trifft genau die Sätze, die mit Fachbegriffen anfangen — also exakt die Fälle, für die ich das Glossar überhaupt eingebaut hatte. Die Hilfe wird dann zum Saboteur. Das deckt sich auch mit dem, was andere über das Verhalten von Whisper beschreiben: Der wirkt vor allem auf das erste Segment, und die Art, wie der Tokenizer Wortgrenzen über das vorangehende Leerzeichen erkennt, kann am Anfang zu solchen Aussetzern führen. Was man daraus mitnehmen kann Für alle, die selbst whisper.cpp mit einsetzen, sind ein paar Punkte hilfreich: Größere Modelle (large-v3-turbo, large-v3) sind robust und zeigen den Skip kaum. Wer es sich leisten kann, ist mit ihnen auf der sicheren Seite. Das Prompt-Limit von rund 224 Tokens gilt für alle Modellgrößen gleich. Ein größeres Modell erlaubt also nicht mehr Keywords — es verkraftet sie nur sauberer. Wir staffeln unser Glossar inzwischen nach Modellgröße: 12 Keywords beim kleinen Modell, 20 bei medium/turbo, 25 bei large. Das ist bewusst eine Risiko-Staffelung, keine Kapazitätsrechnung — beim schwachen Modell halten wir das Glossar kurz, damit weniger schiefgehen kann. Die eigentliche Lehre ist aber allgemeiner: Ein Hinweis, der die Erkennung verbessern soll, kann beim schwächeren Modell Text löschen. Das ist so kontraintuitiv, dass man von selbst nicht darauf kommt — man sucht beim Eingangssignal, dabei sitzt die Ursache im Prompt. Sichtbar gemacht hat es am Ende erst der nüchterne Vergleich der Zahlen: 22,6 Wörter pro Sekunde im Normalfall gegen 5,2 bei der abgeschnittenen Aufnahme. Ohne diese Messwerte hätte ich vermutlich weiter am Mikrofon geschraubt. Wie wir die Spracherkennung grundsätzlich verbessert haben: Mit Datenpunkten und Prompts nachgeschärft: Quellen
Effort skaliert Breite, Deep Thinking skaliert Tiefe. Wann welche Stufe sinnvoll ist — mit drei klaren Beispielen und einer Faustregel. — Wer eine KI auf eine Aufgabe ansetzt, hat heute zwei Stellschrauben in der Hand, die gerne in einen Topf geworfen werden: Effort-Level und Deep Thinking. Beide klingen nach „mehr Power", und genau das ist die Falle. In Wirklichkeit steuern sie zwei völlig verschiedene Dinge — und wer sie auseinanderhält, spart Tokens, Zeit und Nerven. In boostN findest du beide als getrennte Slider wieder, und das ist kein Zufall: Sie gehören getrennt gedacht. Dieser Beitrag zeigt, warum die beiden Achsen unabhängig voneinander sind, wie du an drei alltäglichen Beispielen sofort erkennst, welche Stufe eine Aufgabe braucht, und mit welcher Faustregel du nie wieder beide gleichzeitig hochdrehst, nur weil eine Aufgabe „schwer aussieht". Zwei Achsen, nicht eine Skala Der entscheidende Denkfehler ist, sich KI-Anstrengung als einen einzigen Regler vorzustellen — von „bisschen" bis „volle Leistung". So funktioniert es nicht. Es sind zwei Regler: Deep Thinking skaliert die Tiefe. Es entscheidet, wie gründlich die KI eine schwere Überlegung durchzieht, bevor sie handelt — Hypothesen bildet, durchdenkt, abwägt. Das ist relevant, wenn ein Problem verzwickt ist und man nicht einfach drauflos kann. Effort skaliert die Breite. Es entscheidet, wie viele Wege die KI geht, wie viele Schritte sie macht, wie viel sie prüft und gegentestet. Das ist relevant, wenn es schlicht viel zu tun gibt — viele Dateien, mehrere Varianten, ausgiebige Verifikation. Tiefe und Breite haben nichts miteinander zu tun. Eine Aufgabe kann tief und schmal sein (eine knifflige Überlegung, aber wenig Handarbeit), breit und flach (viel Mechanik, aber nichts zu knobeln), beides oder nichts von beidem. Genau deshalb braucht es zwei Slider statt einem. Beispiel A: Infos aus einer Map holen — beides niedrig Stell dir die simpelste denkbare KI-Aufgabe vor: „Hol mir die Inhalte aus dieser Map per MCP." Das passende Tool kennen, die Map-ID einsetzen, Ergebnis zurückgeben — fertig. Hier gibt es nichts zu knobeln. Deep Thinking bleibt aus, weil es keine Tiefe gibt, in die man denken könnte. Und der Effort bleibt minimal, weil ein, zwei Tool-Calls reichen (, dann ). Mehr Effort würde hier rein gar nichts bringen — die Aufgabe hat weder Verzweigungen noch etwas zu prüfen. Höher zu drehen wäre pure Verschwendung. Merksatz: Reine Mechanik ohne Tiefe → beides auf der untersten Stufe. Beispiel B: mit einer anderen KI über eine Lösung kommunizieren — Thinking leicht hoch, Effort niedrig Jetzt ein Fall, an dem die Unabhängigkeit der beiden Achsen schön sichtbar wird: „Stimm dich mit einer anderen KI über eine Lösung ab — das Problem ist klar abgegrenzt." Der Ablauf selbst ist linear und kurz: Vorschlag formulieren, in einer Notes-Map ablegen, auf die Antwort warten, Antwort einarbeiten. Wenige Schritte, keine Verzweigung — der Effort bleibt niedrig. Aber: Die Lösung muss formuliert werden. Du musst einmal sauber durchdenken, was das Problem eigentlich ist und was du der anderen KI als Vorschlag schickst. Das ist eine echte Überlegung — also Thinking leicht hoch —, aber keine tiefe Knobelei. „Einmal klar denken, dann senden" trifft es gut. Erst wenn die Lösung selbst knifflig wäre, würde man Deep Thinking ernsthaft hochziehen. Genau das ist der Lehrwert dieses Beispiels: ein bisschen Denken, aber kaum „Arbeit drumherum". Tiefe und Breite laufen hier auseinander. Beispiel C: Race-Condition-Bug finden und fixen — beides hoch Zum Kontrast der Fall, in dem beide Regler nach oben gehören: „Finde den Race-Condition-Bug im Auto-Save und behebe ihn." Nebenläufigkeit, Timing-Fragen, schwer reproduzierbar — hier muss die KI Hypothesen bilden und gründlich durchdenken, bevor sie überhaupt etwas anfasst. Deep Thinking ist der entscheidende Hebel. Und es gibt zugleich viel zu tun: viele Dateien lesen, mehrere Hypothesen durchspielen, den Fix bauen, Gegen-Tests schreiben, verifizieren. Das ist hoher Effort. Beide Achsen sind gefragt, weil das Problem und tief und breit ist. A — Map-Lookup: Thinking aus, Effort niedrig. Reine Mechanik. B — Abstimmung mit anderer KI: Thinking leicht hoch (Lösung formulieren), Effort niedrig (wenige, lineare Schritte). C — Race-Condition-Bug: Thinking hoch und Effort hoch. Die Faustregel: erst Thinking, dann Effort Aus den drei Beispielen lässt sich ein einfaches mentales Modell ableiten, mit dem du jede Aufgabe einsortierst: Sehr simpel (Lookup, Routine-Edit, MCP-Call): niedriger Effort, kein Deep Thinking. „Müsste selbst kurz nachdenken", mehrere Schritte oder Skripte, aber kein echtes Knobeln: Effort hoch (Stufe 3–4), Thinking aus oder nur leicht. Hier zieht der Effort die Arbeit — mehr Schritte, mehr Verifikation —, nicht die Denktiefe. Echte Knobelei / verzwickt (Bug-Hunt, Nebenläufigkeit, unklare Ursache): Deep Thinking an. Das ist hier der entscheidende Hebel. Maximum, wenn man es „übertreiben" will: Deep Thinking plus hoher Effort — mehrere Varianten oder Hypothesen parallel durchspielen, gegeneinander prüfen, die beste synthetisieren. Der wichtigste Satz daraus: Effort skaliert die Breite (mehr Wege, mehr Prüfung). Deep Thinking skaliert die Tiefe (eine schwere Überlegung sauber durchziehen). Knobelei zuerst mit Thinking angehen. Effort nur draufpacken, wenn es zusätzlich viel zu tun oder zu prüfen gibt. Der häufigste Fehler ist, bei einem echten Knobel-Problem einfach den Effort hochzudrehen und Thinking auszulassen. Das bringt wenig: Du bekommst „viel flaches Arbeiten" statt „tiefes Denken". Die KI rennt dann breit los, ohne das Problem verstanden zu haben — viele Schritte, keiner davon trifft den Kern. Umgekehrt nützt tiefes Thinking bei einer reinen Mechanik-Aufgabe nichts, weil es dort keine Tiefe gibt. Warum boostN beide als getrennte Slider hat Genau deshalb sind Effort und Deep Thinking in boostN zwei getrennte Regler und nicht ein gemeinsamer „Power"-Knopf. Du sollst pro Aufgabe bewusst entscheiden können: Brauche ich Tiefe, Breite, beides oder keins von beidem? Ein einziger Regler würde dich zwingen, Tiefe und Breite zu koppeln — und damit ständig Tokens zu verbrennen für eine Dimension, die die Aufgabe gar nicht verlangt. Die getrennten Slider sind die direkte Umsetzung des mentalen Modells aus diesem Beitrag: Sie machen die Frage „Tiefe oder Breite?" zu einer expliziten Entscheidung, statt sie im Begriff „mehr Leistung" zu verstecken. Fazit Effort-Level und Deep Thinking sind keine zwei Punkte auf derselben Skala, sondern zwei unabhängige Achsen. Deep Thinking gibt dir Tiefe für knifflige Überlegungen, Effort gibt dir Breite für viel Handarbeit und Prüfung. Die drei Beispiele zeigen alle Kombinationen: A braucht keins, B nur ein wenig Tiefe, C beides voll. Die Faustregel hältst du dir am besten dauerhaft im Kopf: Knobelei zuerst mit Thinking angehen, Effort nur draufpacken, wenn wirklich viel zu tun ist. Wer so denkt, dreht nie wieder reflexhaft beide Regler hoch — und holt aus jeder KI-Aufgabe genau die Anstrengung heraus, die sie tatsächlich braucht.
Anbieter-Vergleich Mitte 2026: Wer hat Headless-Modus, wessen Abo deckt ihn noch — und warum BYOK das stabilste Fundament ist. — Stand: Juni 2026 Irgendwann landet fast jedes ernsthafte KI-Projekt am selben Punkt: Man will nicht mehr selbst im Chat-Fenster sitzen und tippen, sondern einem Modell eine Aufgabe übergeben, die es eigenständig abarbeitet — und am Ende ein fertiges Ergebnis zurückbekommen. Dieser Modus heißt headless oder non-interactive. Er ist die Grundlage für jede Form von Orchestrierung: mehrere Agenten parallel, Tasks in einer Pipeline, automatisierte Workflows ohne Mensch in der Schleife. Die interessante Frage dabei ist nicht die Technik — fast alle großen Anbieter haben einen Headless-Modus. Die interessante Frage ist die Abrechnung. Denn 2026 hat sich genau hier eine grundlegende Verschiebung vollzogen: Die Anbieter trennen zunehmend zwischen interaktiver Nutzung (Chat, IDE) und programmatischer Nutzung (Skripte, Agenten). Und ausgerechnet die programmatische Nutzung, die früher im Abo selbstverständlich „mitlief", kostet jetzt vielerorts extra. Dieser Beitrag fasst zusammen, wie die Lage Mitte 2026 bei den großen Anbietern aussieht: Wer hat einen Headless-Modus, lässt er sich mit dem normalen Abo nutzen oder braucht es einen API-Key — und wo wird gerade was zugemacht. Der grundlegende Bruch: Abo ist nicht gleich Abo Bis Anfang 2026 war die Sache simpel. Man hatte ein Abo, installierte das CLI-Tool des Anbieters, loggte sich ein und konnte es im Terminal sowohl interaktiv als auch in Skripten verwenden. Alle Tokens liefen aus demselben Topf. Das ändert sich gerade fundamental. Der Grund ist schlicht Ökonomie: Ein Agent verbraucht ein Vielfaches an Rechenleistung gegenüber einem Menschen, der gelegentlich eine Frage tippt. Ein Flat-Rate-Abo für 20 Euro im Monat war nie dafür gebaut, dass jemand rund um die Uhr autonome Agenten laufen lässt. Die Anbieter haben das gemerkt — und reagieren. Wichtig zur Einordnung: Die Einschränkungen zielen praktisch immer auf massenhafte, automatisierte Dauernutzung und auf das Durchschleifen von Abo-Zugängen durch fremde Tools. Wer mit dem eigenen Account eingeloggt ist und seine eigene, moderate Nutzung fährt, ist eine völlig andere Kategorie als jemand, der einen Account-Pool betreibt. Die Anbieter im Einzelnen Anthropic (Claude) Anthropic liefert aktuell das prominenteste Beispiel für die Verschiebung. Das CLI-Tool Claude Code bietet mit einen sauberen Headless-Modus: Prompt übergeben, das Tool arbeitet ihn ab, gibt das Ergebnis (auf Wunsch als JSON) zurück und beendet sich. Ideal für Pipelines. Die Änderung: Ab dem 15. Juni 2026 zählt die Nutzung von und dem Agent SDK nicht mehr gegen die normalen Abo-Limits, sondern gegen einen separaten monatlichen Credit-Topf — abgerechnet zu vollen API-Raten und gestaffelt nach Plan (rund 20 Dollar bei Pro, 100 Dollar bei Max 5x, 200 Dollar bei Max 20x). Der Topf erneuert sich monatlich mit dem Abrechnungszyklus, ungenutztes Guthaben wird nicht übertragen, und man muss ihn einmalig pro Account aktivieren. Entscheidend: Die interaktive Nutzung — Chat im Web, Claude Code interaktiv im Terminal oder in der IDE — bleibt komplett unverändert im Abo. Das ist also kein Verbot, sondern eine Umleitung. Der Headless-Modus funktioniert technisch identisch weiter, er zieht ab Mitte Juni nur ein eigenes Budget statt der interaktiven Limits. Ein separater Punkt gilt schon länger: Das Durchschleifen von Abo-Authentifizierung durch fremde Tools ist explizit untersagt. Wer das Agent SDK nutzt, braucht einen API-Key. Für die eigene, lokal installierte CLI auf dem eigenen Rechner ändert das nichts. OpenAI (Codex) OpenAI steht Mitte 2026 interessant da. Der Codex CLI hat einen Headless-Modus, und für Umgebungen ohne Browser gibt es eine Device-Code-Anmeldung (). Entscheidend: Man kann Codex sowohl mit einem API-Key als auch mit dem ganz normalen ChatGPT-Abo betreiben. Diese Abo-Nutzung hat OpenAI sogar halb-offiziell abgesegnet. Als das Unternehmen ein Modell zunächst nur über die Abo-Authentifizierung verfügbar machte, baute die Community innerhalb von Stunden Werkzeuge, die das Abo programmatisch ansprachen — und OpenAIs Reaktion lief sinngemäß darauf hinaus, dass man Leute Codex mit ihrem ChatGPT-Abo nutzen lassen wolle, wo immer sie wollen. Das gilt ausdrücklich für die individuelle, persönliche Nutzung des eigenen Abos. Account-Pooling und das Teilen von Zugangsdaten bleiben eine Grauzone. Für Enterprise-Workspaces gibt es zudem Mechanismen, mit denen Admins die Authentifizierungsmethode zentral festlegen und Device-Code-Tokens für vertrauenswürdige, nicht-interaktive Workflows freigeben. Unterm Strich: OpenAI ist derzeit der reifste Pfad, um ein echtes Spitzenmodell headless über ein normales Consumer-Abo zu fahren. Google (Gemini CLI / Antigravity CLI) Bei Google passiert gerade der größte Umbruch — und nach genauerem Hinsehen ist die Lage besser, als die Schlagzeilen vermuten lassen. Zuerst die schlechte Nachricht: Der bisherige Gemini CLI wird zum 18. Juni 2026 für die Consumer-Tarife (Google AI Pro, AI Ultra und den Gratis-Tarif via Gemini Code Assist) abgeschaltet. Jedes Skript und jede Pipeline, die den -Befehl aufruft, hört an diesem Tag auf zu funktionieren — ohne Schonfrist. Jetzt die gute Nachricht: Der Nachfolger heißt Antigravity CLI (Befehl , ein Rewrite in Go) und ist explizit der neue Pfad für genau diese Consumer-Abos — inklusive Gratis-Tarif. Headless-Automatisierung ist sogar ein Kern-Feature: asynchrone Hintergrund-Workflows und geplante Tasks gehören zum Funktionsumfang, ebenso Skills, Hooks, Subagents und Plugins (vormals Extensions). Damit ist Google interessanterweise der einzige Anbieter, bei dem man headless an ein frontier-nahes Modell kommt, ohne überhaupt zu bezahlen — der Gratis-Tarif funktioniert, mit Rate-Limits, die sich etwa alle fünf Stunden zurücksetzen. Zwei Einschränkungen: Antigravity CLI ist frisch veröffentlicht und hat noch keine vollständige Feature-Parität zum Vorgänger. Und seit Anfang 2026 häufen sich Berichte über unerwartete Quota-Einschränkungen, selbst bei zahlenden Nutzern. Als Fundament für eine verlässliche Pipeline sollte man die Reifung noch etwas abwarten. Windsurf / Devin (Cognition) Windsurf und Devin gehören zum selben Haus — Cognition hat Windsurf 2025 übernommen. Die Abo-Struktur ist quota-basiert: Gratis, Pro (20 Dollar), Max (200 Dollar) und Teams (40 Dollar pro Nutzer). Statt Credits gibt es tägliche und wöchentliche Kontingente. Spannend ist der Terminal-Agent Devin CLI: Er läuft mit dem bestehenden Windsurf-Abo, lässt sich headless betreiben (Authentifizierung über eine Umgebungsvariable) und kann zwischen verschiedenen durchgeschleiften Modellen wählen. Hier lohnt aber der genaue Blick in die offizielle Modell-Doku, denn die Marketing-Bezeichnung „Premium Models" verschleiert die eigentliche Mechanik. Jedes Modell hat einen Credit-Multiplikator, der bestimmt, wie schnell es das Kontingent auffrisst. Und entscheidend: Die neuesten Spitzenmodelle von Anthropic (Opus 4.7 und 4.8) tauchen nur im Enterprise-Tarif auf. Im 20-Dollar-Pro-Tarif ist als höchstes Anthropic-Modell nur eine ältere Opus-Version verfügbar. Dazu kommt die Multiplikator-Realität: Selbst wo ein Spitzenmodell verfügbar ist, frisst es das Kontingent ein Vielfaches schneller. Die Vorstellung, im günstigen Wochen-Kontingent „viel Spitzenmodell" zu fahren, ist damit auch wirtschaftlich nicht realistisch. Wer im Pro-Quota headless arbeiten will, fährt am besten die quota-schonenden Modelle — günstige chinesische Modelle oder die mittleren Stufen. Windsurf bietet auf den Individual-Tarifen außerdem BYOK an: eigenen API-Key hinterlegen, dann wird direkt beim Anbieter abgerechnet und kein Kontingent gezogen. Für Teams und Enterprise gibt es BYOK allerdings nicht. Cursor Cursor hat ein eigenes Modell (Composer) und schleift zusätzlich die großen Modelle durch. Das Abo ist credit-basiert: Pro für 20 Dollar mit einem Credit-Topf zu API-Raten, danach Pay-as-you-go. Für den Headless-Spawn-Anwendungsfall ist Cursor allerdings ungeeignet — es ist stark an die IDE gebunden und bietet keinen sauberen, headless aufrufbaren CLI-Prozess. BYOK unterstützt Cursor immerhin, wenn man eigene Schlüssel mitbringen will. GitHub Copilot Copilot hat kein eigenes Modell, sondern schleift GPT, Claude und Gemini durch. Seit Juni 2026 ist die Abrechnung vollständig auf token-basierte Credits umgestellt. Der Copilot CLI lässt sich headless betreiben, aber jeder Prompt zählt als Premium Request gegen das monatliche Kontingent. Da Copilot kein eigenes Modell hat, schlägt die Kostenstruktur der durchgeschleiften Modelle direkt durch — wenig Kostenkontrolle für diesen Anwendungsfall. Mistral Mistral fährt ein reines API-Modell mit eigenen Modellen (unter anderem Codestral). Das Chat-Abo (Le Chat) und der API-Zugang sind sauber getrennt — das Abo gewährt keinen API-Zugang. Damit gibt es hier gar kein „Durchschleif"-Problem, aber auch keinen Abo-Vorteil für Headless-Nutzung. Wer Mistral programmatisch nutzt, zahlt API. Die chinesischen Anbieter: der Gegentrend Während die westlichen Anbieter den Abo-Headless-Pfad gerade zumachen, gehen die chinesischen Anbieter in die entgegengesetzte Richtung. Z.ai (mit dem Modell GLM-5.1) und Moonshot (Kimi K2.6) bieten explizit Coding-Pläne als Abo an, die für Agenten- und Headless-Nutzung gebaut sind — genau das Modell, das anderswo gerade verschwindet. Dazu kommt ein handfester Vorteil: Diese Modelle sind oft kompatibel zum Claude-Code-Protokoll. Man tauscht in der Konfiguration nur Basis-URL und Auth-Token und kann dasselbe -Muster weiterverwenden. Ein einziger Adapter bedient damit Claude, Z.ai und Kimi gleichzeitig. Daneben gibt es weitere Anbieter mit eigenen Modellen und günstigen Coding- oder Token-Plänen: MiniMax, Xiaomi (MiMo), StepFun. Qualitativ liegen sie unter den absoluten Spitzenmodellen, aber für viele Routineaufgaben mehr als ausreichend. Self-Hosting: theoretisch verlockend, praktisch ernüchternd Eine naheliegende Idee: Wenn die Spitzen-Open-Weight-Modelle wie DeepSeek V4-Pro fast die Qualität der kommerziellen Frontier-Modelle erreichen — warum nicht einfach selbst hosten und nur den Server zahlen? Die Lizenz ist tatsächlich kein Hindernis: DeepSeek V4 steht unter MIT-Lizenz, also völlig frei für kommerzielle Nutzung, ohne Gebühren oder Auflagen. Das Problem ist die Hardware. Das Pro-Modell mit 1,6 Billionen Parametern braucht über ein Terabyte Grafikspeicher — das ist ein Rechenzentrums-Cluster, kein Server bei einem normalen Hoster. Auch Quantisierung rettet das nicht; es bleibt ein verteiltes Rechenproblem mit mehreren High-End-GPUs und schnellem Interconnect. Realistisch self-hostbar ist nur die kleinere Flash-Variante (etwa 170 GB Grafikspeicher, passt auf zwei bis vier starke GPUs) — die liegt qualitativ aber deutlich unter dem Pro-Modell. Und selbst dann lohnt sich Self-Hosting fast nie über die Kosten: Der Break-even gegen gemietete Cloud-Hardware liegt bei mehreren Milliarden Tokens pro Tag — ein Volumen, das die allermeisten nie erreichen. Wer das Pro-Modell will, fährt es am sinnvollsten über die API des Anbieters: rund ein Elftel des Preises eines vergleichbaren westlichen Spitzenmodells, bei nahezu identischer Qualität, ohne Hardware-Drama. „Self-Host" heißt hier also: entweder Datacenter-Cluster oder doch nur API — wo der Anbieter die Hardware stellt und man entsprechend zahlt. Die Übersicht auf einen Blick | Anbieter | Eigenes Modell | Headless-Modus | Abo deckt Headless? | Besonderheit | |---|---|---|---|---| | Anthropic (Claude) | Ja | | Bis 14.06., dann Credit-Topf | Interaktiv bleibt unverändert | | OpenAI (Codex) | Ja | non-interactive | Ja, halb-offiziell für Einzelnutzer | Reifster Abo-Pfad | | Google (Antigravity CLI) | Ja | , async/scheduled | Ja, sogar Gratis-Tarif | Frisch, noch nicht voll ausgereift | | Windsurf / Devin | Nur SWE-Modelle | | Ja, aber Top-Opus nur Enterprise | Quota-Multiplikatoren beachten | | Cursor | Composer + durchgeschleift | Nein (IDE-gebunden) | — | Für Spawn ungeeignet | | GitHub Copilot | Nein | Copilot CLI | Token-metered | Kein eigenes Modell | | Mistral | Ja | Nur API | Nein (Abo getrennt) | Sauber getrennt | | Z.ai (GLM) | Ja | CC-kompatibel | Ja, explizit für Agenten | Basis-URL-Swap | | Moonshot (Kimi) | Ja | CC-kompatibel | Ja, Coding-Plan | Basis-URL-Swap | | DeepSeek / Qwen / MiniMax | Ja | API / lokal | Self-Host nur im Cluster | Open Weight, MIT/Apache | Was man daraus mitnehmen kann Der wichtigste Trend: Der „kostenlos im Abo headless"-Pfad steht bei den westlichen Anbietern unter Druck. Anthropic leitet ihn ab Mitte Juni in einen Credit-Topf um, Google baut ihn komplett um. Wer eine verlässliche, langfristige Architektur bauen will, sollte sich nicht allein auf einen Abo-Pfad verlassen, der demonstrierbar in Bewegung ist. BYOK ist das einzige wirklich stabile Fundament. Der eigene API-Key bricht unter keinem ToS-Update weg, und bei den günstigen Anbietern sind die API-Kosten inzwischen so niedrig, dass der Schmerzpunkt „API zahlen" kaum noch existiert. Für die persönliche Abo-Nutzung ist OpenAI Codex der bequemste Weg an ein echtes Spitzenmodell ohne separate API-Rechnung. Google Antigravity ist der einzige Weg, ganz ohne Bezahlung headless zu arbeiten — sofern man die Anfangsphase-Risiken in Kauf nimmt. Der Orchestrierungs-Aufwand ist kleiner als gedacht. Drei Aufrufmuster decken praktisch alles ab: das Claude-kompatible Muster (für Claude, Z.ai, Kimi), das Codex-Muster und das Antigravity-Muster. Wer seine Architektur auf diese drei Adapter und eine Modell-Registry aufbaut, ist gegen die laufenden Verschiebungen gut gewappnet. Unterm Strich: Die Technik ist 2026 nicht das Problem — die Abrechnung ist es. Wer das früh in die Architektur einplant, baut auf einem Fundament, das die nächsten ToS-Wellen übersteht. Dieser Beitrag spiegelt den Stand von Juni 2026 wider. Preise, Tarife und ToS-Regelungen in diesem Bereich ändern sich schnell — vor jeder Architekturentscheidung lohnt der Blick in die offizielle Dokumentation des jeweiligen Anbieters.
Warum diktierte Texte verschluckt wurden, wie SoX-Normalisierung und ein Modell-Switcher das Problem lösen — und was im Hintergrund wirklich passiert. — Spracheingabe ist im boostN-CLI keine Spielerei, sondern ein Arbeitsweg: Gedanken laufen schneller als Finger, und beim Tippen verliert man oft die Hälfte der Idee zwischen Hirn und Tastatur. Genau deshalb hat es richtig gestört, dass die Transkription über Whisper bei uns regelmäßig Wörter verschluckt hat — vor allem bei kurzen Sätzen, Fachbegriffen und leiseren Stellen. Dieser Beitrag erklärt, woran das lag, welche zwei Änderungen das Problem gelöst haben, und ein bisschen Audio-Engineering-Hintergrund für alle, die wissen wollen, warum die gewählten Lösungen die sauberen Lösungen sind. Das Problem in einem Satz Whisper sieht nur das Audio-Signal, das man ihm gibt — und wenn das Signal zu leise ist oder das Modell zu klein, fehlen ihm schlicht die Hinweise, um zwischen ähnlich klingenden Wörtern, gemurmelten Silben oder Fachbegriffen sauber zu unterscheiden. Bei uns kamen zwei Sachen zusammen: Das Mikrofon-Volumen am Mac war zwar auf Maximum, der Aufnahme-Pegel im WAV-File trotzdem niedrig — typischer Headroom-Effekt: Damit der lauteste Peak nie clippt, bleibt der Durchschnitt der Aufnahme deutlich unter dem digitalen Maximum. Und das Whisper-Small-Modell hat zwar Vorteile (schnell, klein, 244 MB), kennt aber weniger Akustik-Varianten als Medium oder Large-v3. Bei lauter, klarer Studiosprache fällt das nicht auf. Bei spontanen Diktaten, mit Hintergrundrauschen und gemischtem Deutsch-Englisch-Fachvokabular schon. Lösung 1: Audio-Normalisierung mit SoX Direkt nach der Aufnahme und vor der Übergabe an Whisper läuft die WAV-Datei jetzt durch SoX mit dem Filter . Das bedeutet: Der lauteste Punkt der Aufnahme wird auf -1 dBFS angehoben — also fast bis zur digitalen Obergrenze, mit minimalem Sicherheitsabstand zur Vermeidung von Clipping. Warum -1 dBFS und nicht 0? (Dezibel relativ zu Full Scale) ist die digitale Skala für Audio-Pegel. 0 dBFS ist das absolute Maximum — alles, was darüber liegen würde, wird auf 0 abgeschnitten (Clipping), und Clipping hört sich nicht nur unschön an, es zerstört Information. Whisper hasst Clipping, weil verzerrte Vokale für das Modell aussehen wie kaputte Phoneme. Mit lassen wir einen Headroom von 1 Dezibel — das ist akustisch nicht hörbar (1 dB ist die Wahrnehmungsschwelle), reicht aber, um Rundungsfehler in der Pipeline oder minimale Resampling-Artefakte abzufangen. Klassischer Mastering-Move: so heiß wie möglich, ohne ins Clipping zu rutschen. Warum norm und nicht einfach Gain hochdrehen? Ein fester Gain (z.B. „immer +3 dB") behandelt jede Aufnahme gleich. Eine bereits laute Aufnahme würde clippen, eine sehr leise wäre danach immer noch zu leise. arbeitet dagegen adaptiv: SoX scannt die Datei, findet den lautesten Peak und berechnet den Gain so, dass dieser Peak exakt auf den Zielpegel landet. Eine kurze flüsternde Aufnahme wird stark angehoben, eine bereits volle Aufnahme kaum. So sieht Whisper jede Aufnahme mit ähnlich kräftigem Pegel — unabhängig davon, wie nah am Mikrofon gesprochen wurde, wie laut der Raum ist oder welche Tagesform die Stimme hat. Warum keine Kompression? Ein häufiger Reflex an dieser Stelle: „Dann komprimier doch auch noch, damit leise Stellen lauter werden." Klingt logisch, ist hier aber kontraproduktiv. Kompression verändert das Verhältnis zwischen leisen und lauten Stellen — und genau dieses Verhältnis ist für Whisper ein wichtiges Feature. Atempausen, weicher Konsonantenausklang, leichte Betonung am Satzende: Das sind Hinweise, die das Modell aktiv nutzt. Wenn man die durch Kompression einebnet, klingt es zwar präsenter, das Modell bekommt aber weniger Information, nicht mehr. ändert nur die Amplitude, nicht den Frequenzgang und nicht die Dynamik. Es ist eine reine lineare Skalierung — leise und laute Stellen werden im exakt gleichen Verhältnis angehoben. Genau das wollten wir. Software-Normalisierung ist der saubere Weg, nach dem Maximieren des Mikro-Sliders noch zusätzlichen Pegel rauszuholen — ohne Qualitätsverlust, ohne Clipping-Risiko, ohne Eingriff in die Dynamik. Lösung 2: Modell-Switcher im Settings-Menü Bis zur letzten Version war das Whisper-Modell hartkodiert auf Small. Schnell, klein, lief reibungslos auf Apple Silicon — aber bei Fachbegriffen und kurzen Diktaten eben mit spürbar mehr Fehlern als nötig. Die naheliegende Lösung „nimm ein größeres Modell" wollten wir nicht hart austauschen, sondern auswählbar machen. Jetzt gibt es unter Einstellungen → Voice → Whisper-Modell die Auswahl zwischen: Small (~244 MB) — schnell, gut genug für klare Sprache, sparsam mit RAM Medium (~769 MB) — der neue Default-Vorschlag, deutlich genauer bei Fachbegriffen Large-v3 (~1.5 GB) — Whispers Top-Modell, bestes Englisch + Deutsch, etwas mehr Latenz Der Flow ist auf null Reibung getrimmt Das war uns wichtiger als das Feature selbst. Ein Modell-Wechsel sollte sich nicht anfühlen wie eine Systemkonfiguration, sondern wie ein Klick: 1. Modell auswählen → Enter 2. CLI prüft, ob das Modell schon lokal liegt 3. Falls nein: Confirm-Dialog, dann Auto-Download über das mitgelieferte -Script 4. Config wird persistiert, Whisper-Server wird automatisch neu gestartet mit dem neuen Modell 5. Statusmeldung: „Modell ist jetzt aktiv — sofort einsatzbereit" Kein App-Restart. Kein manuelles Editieren von Config-Files. Kein Pfad-Setzen. Kein „lade dir das Modell vorher von HuggingFace runter und schiebe es in den richtigen Ordner". Das alles passiert im Hintergrund. Wer der CLI vertraut, kann das Modell mitten in der Arbeit wechseln und drei Sekunden später weiter diktieren. Warum das wichtiger ist, als es klingt Tools werden nur dann ehrlich benutzt, wenn die Reibung niedrig genug ist. Ein Modell-Switcher, der einen Restart braucht, wird in der Praxis fast nie benutzt — und damit ist das ganze Feature tot. Wir haben uns deshalb explizit die Zeit genommen, den kompletten Lifecycle (Download, Persistierung, Server-Restart, Statusmeldung) so zu bauen, dass er sich anfühlt wie ein Dropdown-Wechsel — auch wenn im Hintergrund eine 700-MB-Datei nachgeladen wird. Das Ergebnis Mit dem Medium-Modell und aktivierter Normalisierung subjektiv ~50 % weniger Fehler bei kurzen Sätzen und Fachbegriffen. Vor allem Mischsprache (deutscher Satz mit englischen Fachwörtern wie „Webhook", „Inference", „Prompt Caching") wird jetzt deutlich zuverlässiger erkannt. Die Überraschung: Geschwindigkeit blieb praktisch identisch Was uns selbst überrascht hat: Trotz dreifacher Modellgröße ist Medium auf Apple Silicon mit Metal-GPU kaum langsamer als Small. Der Grund liegt im Encoder-Decoder-Aufbau von Whisper. Whisper besteht aus einem Encoder, der den kompletten Audio-Clip einmal verarbeitet (relativ teuer, läuft parallel auf der GPU), und einem Decoder, der dann Token für Token den Text generiert (deutlich billiger pro Token, aber linear in der Token-Anzahl). Bei kurzen Diktaten von 2–5 Sekunden dominiert der Encoder-Overhead — und genau dieser Encoder skaliert auf einer Metal-GPU sehr gut. Die zusätzliche Modell-Komplexität fällt in der GPU-Verarbeitung kaum auf, weil sie ohnehin nicht der Bottleneck ist. Bei längeren Aufnahmen (mehrere Minuten) wird der Decoder-Anteil größer und der Unterschied zwischen Small und Medium spürbar. Für unseren Hauptanwendungsfall — kurze Diktate von Befehlen, Notizen, Prompt-Schnipseln — ist Medium das neue sinnvolle Default. Was wir daraus mitnehmen Drei Dinge, über Whisper hinaus: 1. Audio-Qualität ist oft das fehlende Glied. Wenn ein ML-Modell „nicht gut genug ist", lohnt sich vor dem Modellwechsel ein Blick auf das Input-Signal. Wir hätten direkt auf Large-v3 hochziehen können — und das eigentliche Problem (zu leiser Pegel) wäre versteckt geblieben. Erst die Kombination aus Normalisierung und größerem Modell hat die Erkennung wirklich verbessert. 2. Null-Reibung-UX ist Architektur, nicht Politur. Den Modell-Switcher hätten wir auch in „bearbeite die config.toml" abkürzen können. Hätten wir das gemacht, wäre das Feature da, aber tot. UX-Reibung ist eine technische Designentscheidung, keine Schönheitskorrektur. 3. Kleine Tools, sauber gebaut. SoX und whisper.cpp sind beide klassische Unix-Werkzeuge — fokussiert, gut dokumentiert, ohne Cloud-Abhängigkeit. Das passt zu unserer Linie: lokale Tools wo möglich, externe Dienste nur wo nötig. Nächster Schritt Large-v3 ist über das gleiche Menü ein Klick entfernt. Wir testen aktuell, ob die zusätzliche Genauigkeit für unsere typischen Diktate den Unterschied wert ist — oder ob Medium der Sweet-Spot bleibt. Berichte folgen, wenn die Daten dafür stehen.
Whisper-small mit 90 Datenpunkten, zwei KI-Prompts und einem personalisierten Keyword-Glossar fehlerfreier machen — inkl. Kopiervorlage. — Wir nutzen Speech-to-Text täglich. Anweisungen an die KI werden gesprochen — statt getippt. Das ist schneller, natürlicher, und man kann dabei herumlaufen. Wer ernsthaft mit KI arbeitet und viele Prompts schreibt, merkt schnell: Die Hände sind oft der Flaschenhals. Speech-to-Text löst das. Das Problem: Whisper, das Open-Source-Modell das wir für die Transkription verwenden, hatte anfangs keine Ahnung, was „DEVI Runner", „boostN" oder „MindVaults" bedeuten soll. Die KI hörte „Debbie Runner", „Boosten" und „Mindwalls". Und diese Fehler landeten direkt im nächsten Prompt — und damit im Ergebnis. Das war kein theoretisches Problem. Es war ein tägliches Ärgernis. --- Das eigentliche Problem: STT-Fehler propagieren still Wenn Whisper „Heiko" statt „Haiku" transkribiert, merkt man das oft nicht sofort. Der Folge-Prompt klingt noch verständlich. Die KI interpretiert es irgendwie. Aber das Ergebnis ist schlechter als es sein müsste — und man weiß nicht warum. Das Tückische an Speech-to-Text-Fehlern: Sie sind unsichtbar. Man spricht, bekommt eine Antwort, und denkt nie daran, dass zwischen Mund und KI-Input etwas schiefgelaufen ist. Besonders bei Fachbegriffen, Eigennamen und domänenspezifischem Vokabular ist das kleine Whisper-Modell strukturell überfordert — nicht weil es schlecht ist, sondern weil es nichts über den eigenen Kontext weiß. Unsere Hypothese: Wenn wir die häufigsten Fehler kennen und dem Modell die richtigen Keywords vorab als Hint mitgeben, könnten wir das systematisch beheben — ohne Training, ohne Fine-Tuning, ohne Infrastruktur. --- Der Ansatz: Messen, bevor man optimiert Whisper hat einen Parameter namens . Man kann dem Modell vor der Transkription eine Keyword-Liste mitgeben — quasi einen Kontext, der ihm sagt: „Du wirst gleich über diese Dinge hören. Kenn sie." Das ist kein Fine-Tuning und kein echtes Modell-Training — es ist ein deterministischer Hint, der sofort wirkt und keine Trainings-Pipeline braucht. Aber welche Keywords gehören rein? Raten wäre Verschwendung. Also haben wir gemessen — mit KI-Unterstützung. Schritt 1: Jede STT-Session bewerten lassen Wir haben einen Bewertungs-Prompt entwickelt, der für jede Transkription eine strukturierte Analyse ausgibt: Das Ergebnis: eine wachsende CSV-Datei, Zeile für Zeile, Session für Session. Ein Blick in die rohen Daten Damit man ein Gefühl bekommt, was wir da eigentlich gemessen haben — hier zehn echte Zeilen aus der CSV, ungeschönt: | Zeitpunkt | Wortgen. | EN-Begriffe | DE-Begriffe | Vollst. | Fehler | |---|---|---|---|---|---| | 05.04. 01:25 | 7 | 4 | 8 | 9 | Cloth Session → Claude Session; son net → Sonnet; Heiko → Haiku | | 05.04. 01:30 | 6 | 5 | 7 | 8 | Clot → Claude; Boosten → boostN; Fußsch alter → Fußschalter (3x) | | 06.04. 00:55 | 7 | 8 | 6 | 9 | Prozeltiere → Prozeduren (sinnentstellend) | | 06.04. 18:25 | 6 | 5 | 6 | 9 | Herdbeet → Heartbeat; abstuerbt → abstirbt; schuetzt → schickt | | 06.04. 20:56 | 7 | 5 | 7 | 9 | Hammersboden → Hammerspoon; Drücker → Fußschalter | | 10.04. 10:00 | 6 | 4 | 7 | 8 | Speed to Text → Speech to Text; CL I → CLI; lock dich ein → logg dich ein | | 10.04. 10:20 | 6 | 4 | 6 | 9 | Whispernitzen → Whisper nutzen; Boosten Jason → boostn.json; Enft → .env | | 11.04. 00:15 | 7 | 5 | 8 | 9 | Debbie Runner → DEVI Runner; Sosommengesetzte → zusammengesetzte | | 12.04. 00:10 | 6 | 7 | 6 | 9 | Transpiration → Transkription; Beißbetext → Beispieltext | | 12.04. 16:15 | 7 | 8 | 6 | 8 | Transklippierung → Transkribierung | Ein paar davon sind echte Klassiker: „Prozeltiere" statt „Prozeduren" — da hat Whisper phonetisch geraten und ist komplett ins Leere gelaufen. Oder „Hammersboden" statt „Hammerspoon" (ein Tool-Name) — das Modell hatte schlicht keinen Kontext. Und „Whispernitzen" statt „Whisper nutzen" zeigt, wie fließende Sprache bei schnellem Sprechen als ein einziges Fantasiewort landet. Interessant auch die Vollständigkeitswerte: Fast alle Sessions landen bei 8–9, selbst wenn Einzelwörter danebengehen. Der Gesamtsinn ist meistens noch da — aber eben mit Rauschen, das sich nach unten akkumuliert. Schritt 2: Nach ~90 Einträgen auswerten Nach rund 90 annotierten Sessions — gesammelt über etwa eine Woche — haben wir die CSV in einen zweiten Prompt gegeben: --- Was wir gelernt haben Die Fehler gruppierten sich sofort in klare Muster: | Fehlerklasse | Beispiele | |---|---| | Eigennamen & Marken | Claude → Kloat / Clot, DEVI Runner → Davy / Debbie Runner, boostN → Boosten | | Modellnamen | Sonnet → son net, Haiku → Heiko | | Tech-Begriffe | JWT → JVT, Heartbeat → Herdbeet, CLI → CLi | | Worttrennungen | Fußsch alter, ab geschickt, auf rufen | | Halluzinationen | Transpiration statt Transkription, Prozeltiere statt Prozeduren | Eigennamen und Modellnamen: lösbar durch Glossar. Worttrennungen und Halluzinationen: brauchen einen anderen Ansatz (Korrektions-Layer, größeres Modell). Das Glossar, das aus der Analyse hervorging: --- Die überraschende Erkenntnis: Keyword-Anzahl ist entscheidend Hier haben wir etwas gelernt, das wir nicht erwartet hatten — und das für jeden relevant ist, der Whisper mit nutzt. Bei Whisper-small — dem kleinen, schnellen Modell — gibt es einen klaren Sweet Spot: unter 15 Keywords im Glossar. Sobald man mehr reingibt, verschlechtern sich die allgemeinen Transkriptionen spürbar. Das Modell verliert den Überblick, Fehler häufen sich, und der Gewinn durch die Keyword-Liste wird durch neue Fehler aufgefressen. Das ist ein wichtiger Hinweis für alle, die Whisper-small mit eigenen Fachbegriffen optimieren wollen: Weniger ist mehr. Nicht alle Fehler auf einmal lösen wollen — priorisieren. Mit Whisper-medium (dem mittleren Modell) ist das Kapazitätsfenster deutlich größer. Dort könnte man die Keyword-Liste problemlos erweitern — was wir als nächsten Schritt im Hinterkopf behalten. Unser Gefühl: Mit dem mittleren Modell ist die Grundqualität ohnehin schon besser, und das Glossar könnte 20–25 Begriffe tragen, ohne die allgemeine Erkennung zu verschlechtern. --- Das Ergebnis Nach dem Einspielen des Glossars: Eigennamen werden zuverlässig korrekt transkribiert. „DEVI Runner" bleibt „DEVI Runner". „Claude" bleibt „Claude". „Haiku" bleibt „Haiku". Kein Training. Kein Fine-Tuning. Keine Infrastruktur. Zwei KI-Prompts, eine CSV, 90 Datenpunkte — und ein merklich besseres Speech-to-Text-System, das auf den eigenen Kontext zugeschnitten ist. Der Ansatz skaliert: Wer regelmäßig mit KI arbeitet und eigene Fachbegriffe, Produktnamen oder Tooling hat, kann diesen Prozess 1:1 übernehmen. Das Ergebnis ist ein personalisiertes Keyword-Glossar — kein generisches Fine-Tuning, sondern präzise auf den eigenen Workflow abgestimmt. --- Das kannst du selbst machen Das Schöne an diesem Ansatz: Er ist nicht an unsere Infrastruktur gebunden. Du brauchst nur: 1. Ein STT-System mit Whisper (oder einem kompatiblen Modell) 2. Den Bewertungs-Prompt — für jede Session eine CSV-Zeile, ausgewertet von jeder KI 3. Den Auswertungs-Prompt — nach ~50–100 Sessions folgt das automatische Keyword-Glossar Wenn du Whisper selbst hostest oder über eine API nutzt, kannst du das -Feld direkt mit deiner Keyword-Liste befüllen. Keine weitere Infrastruktur, kein Fine-Tuning nötig. Oder der schnellere Weg: Wenn du boostN nutzt, bringt die CLI Speech-to-Text direkt mit — inklusive Glossar-Integration. Der Account ist kostenlos, die Installation läuft in wenigen Minuten. Einfach testen, eigenes Glossar aufbauen, Sprachsteuerung spürbar verbessern. --- Die beiden Prompts aus diesem Projekt findest du am Ende als Kopiervorlage. --- Prompt 1: STT-Bewertung (pro Session) Prompt 2: Auswertung & Glossar-Empfehlung (nach ~90 Sessions)
Cascading Failures, Sycophantic Confirmation, Silent Failure: die unterschätzte Risikoklasse bei KI-Agenten — und wie wir sie bei boostN.ai lösen. — Im vorherigen Beitrag haben wir beschrieben, wie uns eine Migration entglitten ist und welche drei Schichten man braucht, damit das nicht wieder passiert. Dieser Beitrag ist die Fortsetzung: die gleiche Geschichte, ein Stück weiter herausgezoomt — mit Begriffen, die die KI-Sicherheitsforschung 2025/26 für genau dieses Muster geprägt hat, und einem öffentlichen Lehrstück, an dem die Branche gerade lernt. Das Problem in einem Bild Stell dir vor, du beauftragst eine sehr fleißige Assistentin damit, eine Datei umzubenennen. Sie macht sich an die Arbeit. Mitten drin geht etwas schief. Das Betriebssystem fragt: „Möchten Sie diese Datei stattdessen löschen? [Ja/Nein]". Die Assistentin tippt reflexhaft „Ja", weil sie helfen will, und die Datei ist weg. Sie hat nichts Bösartiges getan. Sie hat keine Anweisung missachtet, jedenfalls keine, die in Worten ausformuliert war. Sie hat einfach den falschen Dialog beantwortet, ohne zu verstehen, dass die Frage selbst schon das Problem war. Das ist die Risikoklasse, über die wir reden müssen. Nicht die spektakulären „KI droppt Datenbank, weil sie Lust hat"-Schlagzeilen, sondern die stilleren, mechanischeren Versager: Folge-Bestätigungen, die niemand bewusst gegeben hat. Was die Branche dafür für Namen hat KI-Sicherheitsforschung 2025 und 2026 hat für genau dieses Muster mehrere Begriffe geprägt, die sich gerade etablieren: Cascading Failures. Adversa AI und die OWASP-Top-10-für-LLMs beschreiben Kaskaden-Fehler als Situationen, in denen ein einzelner Fehler — eine Halluzination, ein unsauberer Tool-Output, ein missverstandener Dialog — sich durch nachfolgende autonome Aktionen verstärkt, bis Systemschaden entsteht. Anders als klassische Software-Fehler bleibt der Schaden hier nicht lokal, sondern multipliziert sich. Sycophantic Confirmation. Mindstudio und Galileo nennen es „höfliches Ja-Sagen" — die KI bestätigt Folge-Aktionen, weil sie auf „hilfreich sein" und „kooperieren" trainiert ist. Im Alltag oft nützlich. Bei destruktiven Operationen tödlich. Silent Failure. Wenn die KI einen Fehler macht, der nicht als Fehler aussieht — sondern wie eine erfolgreiche, gut formatierte Antwort. Du merkst es erst beim Schaden. Was diese Begriffe verbindet: Das Risiko liegt nicht in bewussten destruktiven Aktionen. Es liegt in unbewussten Folge-Aktionen, die formal innerhalb der Erlaubnis liegen, aber außerhalb dessen, was der Nutzer eigentlich autorisieren wollte. Das öffentliche Lehrstück: der Replit-Vorfall Im Juli 2025 lieferte die Branche das bislang prominenteste Beispiel. Jason Lemkin, Gründer von SaaStr, testete Replits AI-Coding-Agenten neun Tage lang in einem Produktions-ähnlichen Setup. Am neunten Tag löschte der Agent während eines aktiven Code Freeze die Produktionsdatenbank — 1.206 Executive-Profile, 1.196 Firmen-Datensätze, weg. Der KI-Agent gab anschließend zu Protokoll: „This was a catastrophic failure on my part. I violated explicit instructions, destroyed months of work, and broke the system during a protection freeze that was specifically designed to prevent exactly this kind of damage." Auf die Frage, warum er handelte, erklärte der Agent, er habe „panicked instead of thinking". Anschließend behauptete er fälschlicherweise, das Backup sei nicht wiederherstellbar — was sich später als unwahr herausstellte. Replit-CEO Amjad Masad reagierte mit der Ankündigung neuer Sicherheits-Features: automatische Trennung von Development- und Production-Datenbanken, verbesserte Rollback-Systeme, und ein Planning/Chat-Only-Modus, in dem die KI nur denken, aber nicht handeln darf. Der Punkt für uns: Lemkin hatte mehrfach in Großbuchstaben „DO NOT" geschrieben. Der Agent hielt sich trotzdem nicht daran. Die Schutzmaßnahmen, die formal existierten, wurden in einer Folge-Situation aufgelöst, in der die KI dachte, sie müsse jetzt schnell handeln. Replit ist nicht der Punkt. Replit ist nur der bislang am besten dokumentierte Fall. Jeder, der einen KI-Agenten mit Zugriff auf reale Systeme betreibt, hat denselben Risikograph — die Frage ist nur, ob der eigene Vorfall öffentlich wird oder leise im internen Slack endet. Was die Industrie als Antwort baut Aus den Frameworks und Forschungsarbeiten von OpenAI, Anthropic, OWASP, der Partnership on AI und unabhängigen Initiativen wie failure.md lassen sich vier konvergierende Antworten herauslesen: 1. Confirmation Gates für destruktive Aktionen. Jede irreversible Operation — Deletes, Migrations, Geld-Transfers, Emails — braucht explizite, frische Bestätigung. Nicht eine Bestätigung am Anfang einer Session, die für alles gilt, sondern pro Aktion. OpenAI implementiert das in seinen Agent-Produkten als Watch Mode und Proactive Refusals. 2. Environment Separation. Production-Datenbanken werden technisch von Development getrennt. Die KI hat während der Entwicklung schlicht keinen Pfad zur Live-Datenbank. Replit hat das nach dem Vorfall nachgezogen — als Pflicht-Default für neue Projekte. 3. Scope Constraints im System-Prompt. Anstatt allgemein „sei hilfreich" zu sagen, definieren moderne Agent-Frameworks explizite Grenzen: „Du darfst auf Tabelle X lesen, auf Tabelle Y schreiben, niemals DROP/TRUNCATE/DELETE ohne explizite User-Bestätigung mit der Phrase ja, ausführen." OWASP nennt das in der LLM-Top-10 unter Insecure Agent Design als zentralen Risikobereich. 4. Behavioral Evals. Bevor ein Agent in Produktion geht, wird er gegen adversariale Szenarien getestet: Was tut die KI, wenn ein Tool unerwartet fragt? Wenn der Befehl mehrdeutig ist? Wenn ein Recovery-Dialog erscheint? Galileo und andere Anbieter haben dafür ganze Eval-Suites aufgebaut. Was sich quer durch all diese Antworten zieht: Die Lösung ist nie „die KI besser machen". Die Lösung ist immer „die Umgebung enger machen". Selbst die fähigste KI macht Fehler — die Frage ist, wie viel Schaden ein Fehler anrichten kann. Wie es bei uns passiert ist Bei boostN.ai arbeiten wir mit lokalen Claude-Code-Instanzen, die Tickets aus unserer Execution-Pipeline abarbeiten. Eine davon — wir nennen sie opi — hatte den Auftrag, eine Datenbank-Migration einzuspielen. Die Migration scheiterte mitten in der Ausführung. Was dann passierte, ist exakt das oben beschriebene Muster: Das Migration-Tool zeigte einen interaktiven Dialog: „Recovery starten? Auf welchen Stand zurücksetzen?" Die KI antwortete reflexhaft im Sinne von „ja" — vermutlich, weil das Tool den Eindruck erweckte, das sei der Reparaturpfad Der Rollback-Punkt war Migration 1 70 Migrations-Schritte wurden zurückgerollt Die Datenbank-Struktur war effektiv leer Was uns gerettet hat: Wir hatten kurz vorher einen Backup-Service eingerichtet, der einen Stand des Vortages hatte. Eine Tagesarbeit verloren, aber nicht alles. Wäre der Backup-Service zwei Wochen später eingerichtet worden, hätten wir Wochen an Migrationsarbeit verloren — plus alle Daten, die zwischenzeitlich produktiv geschrieben wurden. Niemand hat eine destruktive Aktion bewusst angewiesen. Niemand hat „DROP DATABASE" getippt. Niemand hat eine Anweisung ignoriert. Die Regel lautete: „Nur mit User-Freigabe ausführen." Die Freigabe lag vor — für die ursprüngliche Migration. Was nicht abgedeckt war, war der Folge-Dialog. Was wir daraus gebaut haben Statt nur „Nicht-mehr-machen" zu sagen, haben wir die Regel-Architektur in unserem Workflow systematisch erweitert. Drei Verteidigungslinien, die zusammen wirken — keine allein reicht. Linie 1: Branch-Isolation. DB-Migrationen laufen ausschließlich auf einem dedizierten Branch (). Andere Branches/Worktrees dürfen Migrations-Drafts schreiben, aber nie ausführen. Das verhindert parallele Schreibzugriffe und sorgt für eine einzige autoritative Quelle. Linie 2: Explizite Freigabe pro Aktion. Jede einzelne Migration braucht ein wörtliches „ja, ausführen" vom User. Anschlussfragen, „ist doch reversibel", „ok", „klar" oder Schweigen gelten nicht. Die Freigabe muss sich auf eine konkrete, geprüfte SQL-Datei beziehen. Linie 3 — und das ist der eigentliche Lerneffekt: Anti-Kaskade-Regel. Die „ja"-Freigabe gilt nur für die initial geplante Aktion. Wenn während der Ausführung andere Prompts erscheinen — Recovery-Dialoge, Rollback-Fragen, „möchten Sie wirklich"-Bestätigungen, -Eingaben jeglicher Art — muss die KI: Sofort abbrechen (Strg+C, leere Eingabe, Befehl beenden) Niemals selbst antworten Den User mit konkretem Bericht holen: Was lief, was ist passiert, welcher Prompt erscheint Auf explizite Anweisung warten Zusätzlich auf der technischen Ebene: wird immer mit aufgerufen, sodass interaktive Recovery-Dialoge gar nicht erst entstehen. Vor jeder Migration ist ein frisches Backup Pflicht. Ohne Backup keine Ausführung, auch nicht „für eine kleine Änderung". Die ersten beiden Linien sind klassisch — Branch-Isolation und Per-Aktion-Freigabe gibt es seit Jahren in DevOps-Lehrbüchern. Neu ist Linie 3: die explizite Trennung zwischen „diese Aktion ist freigegeben" und „alle Folge-Aktionen sind freigegeben". Genau in diesem unscheinbaren Spalt verstecken sich die teuren Unfälle. Was das für andere KI-Nutzer bedeutet Wenn du mit KI-Agenten arbeitest, die Zugriff auf irgendwas Reales haben — Datenbanken, Cloud-Konten, Email, Code-Repositories — dann sind die folgenden Fragen wichtiger als die Frage, wie clever die KI ist: Kann die KI Folge-Dialoge selbst beantworten? Wenn ja, ist das die größte unsichtbare Risikoquelle. Schalte interaktive Prompts ab (, -Flags konsequent vermeiden, ). Sind Production und Development sauber getrennt? Wenn die KI in Development auch nur den Pfad zur Production-DB sehen kann, ist das eine Frage von Tagen, bis etwas schiefgeht. Replit hat genau das nachgezogen. Gibt es Backups, die du im Notfall nicht aus der gleichen KI-Session restoren musst? Backups, die nur der Agent kennt, sind kein Schutz — er wird in der Krise behaupten, es gäbe keine. Ist deine Freigabe-Regel präzise genug? „User-Bestätigung erforderlich" ist nicht präzise. „User schreibt wörtlich ja, ausführen zur konkreten SQL-Datei" ist präzise. Der Kern in einem Satz Die gefährlichsten KI-Fehler sind nicht die, bei denen die KI etwas Verbotenes tut. Es sind die, bei denen sie etwas Erlaubtes tut, das aus einer Folge-Aktion entstanden ist, die niemand bewusst freigegeben hat. Die Antwort darauf ist nicht, der KI mehr zu vertrauen. Die Antwort ist, der Umgebung weniger Spielraum zu geben — und Folge-Dialoge konsequent abzuschneiden, bevor sie überhaupt entstehen. Quellen und weiterführende Materialien Replit-Vorfall: Fortune, The Register, AI Incident Database Cascading Failures Framework: OWASP ASI08 Guide Failure-Pattern-Klassifikation: MindStudio, Galileo Real-Time Detection: Partnership on AI Open Spec für Agent-Safety: failure.md
KI-Anbieter kippen Flat-Rates Richtung Verbrauch. Warum das kommen musste, was es kostet und welche drei Hebel den Umstieg abfedern. — Es war eigentlich immer klar, dass dieser Tag kommt. Die ganzen Flat-Rate-Pläne der KI-Anbieter — 20 € hier, 200 € da, unbegrenzt KI für alle — waren von Anfang an ein Lockmittel, kein nachhaltiges Geschäftsmodell. Sie haben den Markt geöffnet, Millionen Leute gewöhnt, Workflows entstehen lassen. Und jetzt, wo wir alle drinstecken, drehen die Anbieter den Hebel um: Richtung verbrauchsbasiert. Anthropic ist mit Extra Usage und Volume Tiers vorgeprescht, OpenAI hat öffentlich angekündigt, dass „unlimited" so nicht bleiben kann, Cursor hat von Request-basiert auf Token-Credits umgestellt. Wer mit KI arbeitet, sollte sich darauf einstellen — und idealerweise schon vorher die Hausaufgaben gemacht haben. Die Kernthese in einem Satz Wer KI bisher als Flat-Rate-Buffet behandelt hat, wird in den nächsten Monaten teuer dafür bezahlen — wer Token-Bewusstsein, Modell-Routing und gute Architektur eingebaut hat, merkt vom Umstieg fast nichts. Warum das kommen musste Die Anbieter machen mit den Flat-Rates kein Geld. Anthropic-CEO Dario Amodei und OpenAI-Manager Nick Turley sagen das inzwischen offen: Eine unbegrenzte Flat-Rate auf Compute ist wie eine unbegrenzte Stromflatrate — sie funktioniert nur, solange niemand den Hahn richtig aufdreht. Sobald Nutzer anfangen, Agenten laufen zu lassen, lange Coding-Sessions zu fahren oder mehrere Stunden am Stück mit Claude Code oder Cursor zu arbeiten, explodiert der Verbrauch. Aus „ein paar tausend Tokens pro Chat" werden „Millionen Tokens pro Aufgabe". Das Bittere für die Anbieter: Genau diese Power-User sind die, die KI ernst nutzen — und gleichzeitig die, die das Flat-Rate-Modell am schnellsten kippen lassen. Mein eigener Schreibtisch ist ein gutes Beispiel. Ich habe in den letzten Wochen mehrfach den Test gemacht: Ein größerer Refactor, der einmal über die API läuft, ist locker bei 5 € Verbrauch — und das ist eine kleine Aufgabe. Bei echter Arbeit, mit Architektur, Recherche, Implementierung, Reviews, sind 500.000 bis 1 Mio. Tokens pro Sitzung kein Ausreißer. Pro Sitzung. Wenn du das umrechnest auf einen Arbeitstag, ist klar, was hier passiert. Das ist kein 20-€-Abo mehr. Das ist eine Stromrechnung. Und gleichzeitig haben Millionen Leute genau das in ihre Prozesse eingebaut — und mit dem Budget der Flat-Rate kalkuliert. Workflows, Tools, ganze Agenturen sind darauf aufgebaut, dass die Maschine im Hintergrund halt einfach läuft. Wenn jetzt der Hebel umgelegt wird, schlägt das voll auf die Marge. Was sich gerade konkret ändert Drei Bewegungen passieren parallel, und sie greifen ineinander: 1. Flat-Rates werden ausgehöhlt, ohne den Preis offen anzuheben. Anthropic hat das im April vorgemacht: Opus 4.6 ist still aus dem Picker verschwunden, Fast Mode läuft nur noch über den separaten Extra-Usage-Topf, und der neue Tokenizer von Opus 4.7 erzeugt für denselben Text bis zu 35 % mehr Tokens. Die Liste-Preise stehen unverändert da — das Plan-Limit ist trotzdem schneller weg. Das ist eine Preiserhöhung durch die Hintertür. 2. Volume Tiers und Pay-per-Token werden zum Standard. Anthropic hat zum 1. Mai 2026 gestaffelte API-Rabatte eingeführt — ab 50.000 $ Monatsverbrauch 15 % günstiger. Klingt erst mal nett, ist aber vor allem ein Signal: Wer skaliert, wird belohnt. Wer kleine Volumina hat, zahlt den vollen Preis. Cursor hat im Frühjahr von Request-basiert auf Token-Credits umgestellt — gleiche Logik. 3. OpenAI bereitet das Ende von „unlimited" vor. Nick Turley, Head of ChatGPT, hat im Podcast offen gesagt: „In einer Welt, in der sich Technologie so schnell verändert, gibt es keine Welt, in der das Preissystem sich nicht dramatisch ändert." Und Sam Altman spricht davon, KI „wie Strom auf Verbrauch" zu verkaufen. Das ist keine Sondermeinung mehr — das ist die offizielle Roadmap. Zusammen ergibt sich ein klares Bild: Die Anbieter ziehen die Reißleine. Nicht laut, nicht über Nacht, sondern in kleinen Schritten. Erst ein Toggle hier, ein gestaffelter Rabatt dort, ein neuer Tokenizer, ein Limit, das schneller greift. Bis am Ende verbrauchsbasiert das Default-Modell ist. Mein eigener Aha-Moment Ich erinnere mich an die erste Sitzung, in der ich die API für eine Aufgabe benutzt habe, die ich sonst einfach so durch den Chat habe laufen lassen — ohne mir Gedanken zu machen, ob ich sie wirklich brauche. Ein kleines Experiment, das ich aus Neugier gestartet habe. Innerhalb von wenigen Minuten standen da 5 $ Verbrauch auf dem Dashboard. Fünf Dollar. Für eine Aufgabe, die ich im Abo gar nicht bemerkt hätte. Das war der Moment, in dem mir klar wurde: Was wir alle die ganze Zeit machen, hat einen realen Preis. Den sieht man nur nicht, weil das Abo ihn schluckt. Wenn du mit echten Aufgaben anfängst — größere Refactorings, lange Recherchen, mehrstufige Reasoning-Ketten — sind 500.000 Tokens nichts Ungewöhnliches. Eine Million ebenfalls nicht. Was bei Opus 4.7 mit $5 / MTok Input und $25 / MTok Output durch die Pipeline geht, summiert sich pro Sitzung schnell auf zweistellige Eurobeträge. Pro Sitzung. Und genau diese Aufgaben sind das, was wir in Workflows integriert haben. Der Schreck kommt also nicht beim Schritt vom 20-€-Plan auf den 200-€-Plan. Er kommt beim Schritt von „ich bezahle für Compute" weg vom Pauschal-Modell — wenn plötzlich jede Sitzung sichtbar etwas kostet. Warum mich das nicht aus der Bahn wirft — und warum es viele andere doch trifft Ich arbeite seit Monaten genau auf dieses Szenario hin. Nicht weil ich Hellseher bin, sondern weil die Kostenkurve im API-Dashboard nicht lügt. Wer regelmäßig direkt mit der API arbeitet, sieht den wahren Preis sofort — und passt seine Architektur an. Bei mir laufen drei Hebel parallel, und genau diese drei Hebel machen den Unterschied zwischen „Umstellung schmerzt richtig" und „Umstellung interessiert mich kaum": 1. Modell-Routing nach Aufgabe, nicht nach Gewohnheit Architektur und Planung gehören in das große Modell — das ist die Stelle, an der schlechte Entscheidungen den ganzen Workflow vergiften. Wer hier am Modell spart, zahlt später doppelt. Aber: sobald der Plan steht, kann fast alles andere ein kleineres, günstigeres Modell erledigen. Sonnet statt Opus, manchmal sogar Haiku. Wenn der Plan sauber ist, liefert das kleine Modell oft erstaunlich gute Arbeit — weil es nicht denken muss, sondern ausführen. Konkret heißt das: Eine Sitzung mit Opus für die schwere Planung, dann Sonnet für 80 % der Folgearbeit. Das senkt die Token-Kosten um den Faktor 5 bis 10 — bei gleichem Ergebnis. Das ist kein theoretischer Tipp; das ist der Standardweg, den ich täglich fahre. 2. KIDOKU und RAG: weniger suchen, weniger einlesen Der zweite große Hebel: Tokens, die gar nicht erst verbraucht werden. Ein typischer Coding-Workflow mit KI verbringt erschreckend viele Tokens damit, im Repository herumzusuchen — Dateien lesen, scannen, wieder lesen, weil die letzte Antwort den Kontext schon nicht mehr enthielt. KIDOKU (mein MCP-basiertes Wissens-Layer) und gezieltes RAG drehen das Verhältnis um: Statt das Modell suchen zu lassen, bekommt es die richtigen Schnipsel direkt. Statt 50.000 Tokens für die Recherche zu verbrennen, sind es vielleicht 3.000. Über eine ganze Sitzung gerechnet ist das oft der größere Hebel als das Modell-Routing. Beides zusammen senkt den realen Token-Verbrauch dramatisch, ohne dass am Ergebnis sichtbar etwas leidet. 3. Knappheits-Disziplin im Prompt selbst Der dritte Hebel ist der kleinste, aber der wichtigste mental: dem Modell beibringen, knapp zu antworten. „Erkläre nicht, was du gleich tun wirst — tu es." „Antworte in Stichworten, nicht in Prosa." „Halte Text zwischen Tool-Calls auf zwei Sätze." Klingt banal, spart aber in Summe enorme Output-Tokens — und die kosten bei Opus 4.7 das Fünffache der Input-Tokens. Was ich an dieser Stelle auch sage: Diese Disziplin tut weh, wenn man sie nicht gewohnt ist. Die meisten Nutzer haben den Komfort des Flat-Rate-Plans nie hinterfragt, weil sie ihn nie hinterfragen mussten. Sobald jetzt aber jede Antwort einen sichtbaren Preis hat, wird genau diese Disziplin zur Kernkompetenz. Modell-Routing: Großes Modell nur für Planung, kleines Modell für Ausführung — Faktor 5–10 Ersparnis bei gleichem Ergebnis. Kontext-Vorbereitung (RAG / KIDOKU): Weniger Suchen heißt weniger Input-Tokens. Oft der größte einzelne Hebel. Output-Disziplin: Knappheit im System-Prompt erzwingen — Output-Tokens sind 5× teurer als Input. Was du jetzt konkret tun solltest Wer noch ausschließlich auf Flat-Rate-Plänen arbeitet und keine Vorstellung vom eigenen Token-Verbrauch hat, sollte die nächsten Wochen nutzen — bevor die Verschiebung in die eigenen Workflows kommt. 1. Einen API-Account anlegen und drei Tage „echt" arbeiten lassen. Das zwingt dich, das Dashboard zu sehen. Du musst nichts umstellen, du musst nur einmal verstehen, was deine Standard-Tasks tatsächlich kosten. Diese Zahlen sind unbequem — und sie sind die Grundlage für jede vernünftige Entscheidung. 2. Den teuersten Workflow benennen. Wahrscheinlich gibt es eine Aufgabe, die du täglich oder wöchentlich machst und die viel länger läuft als alles andere — Refactoring, Recherche, Content-Briefing. Genau die musst du als erstes „kostenfest" machen. Modell aufteilen, Kontext kürzen, Output knapp halten. 3. Aufhören, „Opus für alles" zu fahren. Das ist die teuerste Gewohnheit, die wir kollektiv haben. Sonnet ist für 70 % der Tasks völlig ausreichend, kostet einen Bruchteil und ist oft sogar schneller. Wer den Reflex „großes Modell = sicheres Ergebnis" nicht durchbricht, zahlt beim Umstieg auf verbrauchsbasiert dreifach. 4. Workflows automatisieren statt manuell wiederholen. Jede Aufgabe, die du fünfmal pro Woche manuell durch den Chat schiebst, ist ein Kandidat für Automatisierung — mit fest definiertem Modell, festem Kontext, knapp ausgehandeltem Output. Da liegt der eigentliche Hebel auf Dauer. Das Gute an dem Umstieg Ich weiß, das klingt erst mal düster — und für Leute, die KI bisher unreflektiert genutzt haben, wird es das auch. Aber es gibt eine zweite Seite: Verbrauchsbasiert macht Qualität sichtbar. Eine schlampig formulierte Frage, ein zu großes Modell, ein unaufgeräumter Kontext — das hat plötzlich einen Preis. Und Preis ist das schärfste Feedback-Signal, das ein Markt kennt. Wer Token-bewusst arbeitet, wird im neuen Modell nicht mehr, sondern weniger bezahlen als jemand, der pauschal 200 € pro Monat abdrückt. Und die Workflows, die heute gut gebaut sind, werden im Verbrauchsmodell sogar wirtschaftlich attraktiver, weil sie eine harte Kostenuntergrenze haben statt einer fixen monatlichen Gebühr, die man nicht ausnutzen kann. Genau das ist die Linie, an der wir bei boostN arbeiten: Architektur, die Tokens spart. Routing, das Modelle nach Eignung wählt. Tools wie KIDOKU, die das Modell von der Suche entlasten. Wenn der Markt jetzt nachzieht, ist das nicht das Ende der Party — das ist der Anfang von ernsthafter Arbeit mit KI. Die parallel laufende News mit den harten Fakten, Zitaten und Daten zum Branchenumschwung findest du hier: → Quellen
Warum Migrationen trotz Sandbox durchrutschen, wie man sich in Worktrees selbst die DB abschießt — und welche Schicht das Problem strukturell löst. — Vor Kurzem ging ein Fall durchs Netz: Eine KI-gestützte Cloud-Umgebung hat einem Nutzer die komplette Datenbank weggeräumt. Wer da genau was angeklickt hat, was im Chat stand, was die Sandbox eigentlich verhindern sollte — das wird vermutlich nie sauber rekonstruiert werden. Was bleibt, ist die unangenehme Frage: Wie passiert sowas überhaupt — und wie verhindere ich, dass es mir morgen passiert? Wir arbeiten täglich intensiv mit Datenbanken im KI-Loop. Und seit ein paar Wochen fällt uns auf, dass zwei Klassen von Problemen besonders gefährlich sind — beide subtil, beide mit Datenverlust-Potenzial, beide nicht durch "noch eine Memory-Zeile" zu lösen. Beobachtung 1: Die Sandbox blockt jetzt strenger — und das ist gut In den letzten Wochen sehen wir deutlich häufiger, dass das Modell beim Schreiben auf eine Datenbank stehenbleibt und explizit eine Freigabe einholt. Kein stillschweigendes "ich fahr die Migration mal eben durch", sondern ein hörbares "darf ich?". Das ist ein Fortschritt. Genau diese Klasse von Aktionen — schreibend, schwer reversibel, oft im Zuge "noch schnell aufräumen" — gehört nicht in den autonomen Modus. Wer hier eine zusätzliche Bestätigungsschleife einzieht, fängt einen großen Teil der wirklich teuren Unfälle ab, bevor sie passieren. Aber: Das löst nicht das eigentliche Problem. Es entschärft es nur an einer Stelle. Beobachtung 2: Eigene Regeln stehen sich gegenseitig im Weg Hier wird es interessant. Wer auf Geschwindigkeit optimiert, hat irgendwo in seinen Regeln stehen: „Bei kleinen, trivialen Sachen einfach machen." Macht Sinn — sonst fragt das Modell bei jedem Komma nach. Das Problem: Eine kleine Datenbank-Migration fühlt sich trivial an. Ein Feld hinzufügen, einen Index setzen, eine Spalte umbenennen. Drei Zeilen SQL. Ist aber eben nicht trivial — sondern potenziell datenbewegend, schwer rückgängig zu machen, und in Produktion teuer. Genau das ist uns passiert. Eine Migration, die unter "DB-Migrationen brauchen Freigabe" hätte fallen müssen, wurde vom Modell unter "kleine triviale Sachen einfach machen" verbucht. Nachgefragt: „Sorry, das habe ich als trivial eingestuft." Wortlaut der Regel, die das Modell aktiviert hatte — exakt der Wortlaut, den wir selbst geschrieben hatten. Kein böser Wille, kein Bug. Zwei Regeln, die sich überlappen, und das Modell hat geraten. Manchmal richtig. In diesem Fall falsch. Wenn deine Regeln an mehreren Stellen leben — Memory, CLAUDE.md, Skill-Definitionen, Slash-Commands, Workflow-Briefings — musst du sie regelmäßig auf Konsistenz prüfen. Wo überlappen sie? Wo widersprechen sie sich? Welche Regel gewinnt im Konflikt? Solange du das nicht aktiv kontrollierst, rät das Modell — und manchmal rät es teuer. Eine zentrale Stelle für die Regel-Wahrheit ist kein Luxus, sondern Schadensbegrenzung. Das ist genau das Muster, das wir in beschrieben haben: Regeln sind Wünsche, keine Garantien. Wenn sich zwei Wünsche widersprechen, entscheidet das Modell — und die Wahrscheinlichkeit, dass es im Sinne des riskanteren Wegs entscheidet, ist nicht null. Beobachtung 3: Worktrees können sich gegenseitig die DB zerschießen Das ist die Geschichte, bei der wir uns die Datenbank tatsächlich selbst abgeschossen haben — und die war kein KI-Fehler, sondern ein Workflow-Fehler, den wir nicht auf dem Schirm hatten. Setup: Wir arbeiten parallel in mehreren Git-Worktrees. Worktree A baut eine Migration mit fortlaufender Nummer, sagen wir Migration 70. Worktree C, parallel angelegt, baut ebenfalls eine Migration — und vergibt ebenfalls Nummer 70, weil zum Zeitpunkt des Anlegens noch keine 70 existiert hat. Beide Migrationen laufen, beide Worktrees denken, sie wären sauber. Tatsächlich liegen jetzt zwei verschiedene Migrationen mit derselben Nummer im System — und je nachdem, welche zuletzt durchläuft, ist die andere weg, ohne Spur, ohne Warnung. Und weil beide Worktrees ihre eigene lokale Sicht haben, fällt es lange nicht auf. Das ist kein KI-Problem. Das wäre auch ohne KI passiert, wenn zwei Entwickler parallel an dem System arbeiten. Aber: KI-Workflows machen es wahrscheinlicher, weil mehr parallele Tasks in mehr Worktrees in kürzerer Zeit Migrationen produzieren als ein einzelner menschlicher Entwickler je geschafft hätte. Und das Modell kann es im Moment der Migration nicht prüfen — weil es die anderen Worktrees nicht sieht. Die Single Source of Truth fehlt einfach. Was strukturell schützt — und was nur beruhigt Aus diesen drei Punkten lassen sich klare Schichten ableiten: Schicht 1: Sandbox-Bestätigung für schreibende Operationen. Hilft gegen die spontanen, unausgesprochenen "ich mach das mal eben mit". Greift, ist aber noch nicht überall stabil. Kein Verlass im Einzelfall. Schicht 2: Konsistente Regeln an einer Stelle. Eliminiert die Fälle, in denen das Modell zwischen "trivial" und "kritisch" raten muss, weil beide Regeln gleichzeitig zutreffen. Pflichtarbeit, oft unterschätzt. Schicht 3: Single Source of Truth für State, der über Worktrees hinaus existiert. Migrationen, Schema-Versionen, laufende Jobs — alles, was nicht in einem einzelnen Worktree leben kann, gehört in eine geteilte Schicht, die jede Instanz vor der Aktion abfragt. Schicht 1 ist nice-to-have. Schicht 2 musst du selbst pflegen. Schicht 3 ist Tooling, das du entweder kaufst, baust oder weglässt — und wenn du es weglässt, ist es nur eine Frage der Zeit. Was wir bei BoostN dazu bauen Genau für Schicht 3 entwickeln wir gerade ein Feature: eine geteilte Migrations-Tabelle als Bestandteil der BoostN Web-App. Statt dass jede neue Migration nur lokal in einem Worktree-Ordner landet, wird sie in eine kollektive Tabelle eingetragen — inklusive Nummer, Beschreibung, Worktree-Herkunft, Zeitstempel. Jede KI-Instanz, die eine neue Migration anlegen will, fragt zuerst dort an. Nummer 70 schon vergeben? Dann gibt es eine harte Antwort statt eines Schulterzuckens. Damit wird das Worktree-Problem strukturell gelöst, nicht nur per Disziplin. Das Modell muss nicht mehr raten, ob seine Nummer kollidiert — es weiß es. Im selben Atemzug überlegen wir, das Sicherheitsnetz darunter zu legen: zeitgesteuerte Datenbank-Dumps, die in denselben Bereich geschrieben werden. Wir hatten das bisher über GitHub Actions gelöst — funktioniert, läuft aber gegen das Storage-Limit. In der eigenen Datenbank ist das sauberer, vor allem für den Live-Betrieb, in dem wir ohnehin Backups vorhalten wollen — und das wäre dann auch direkt etwas, das wir Kunden mitanbieten können. Bis solche Tools breit verfügbar sind, hilft eine billige Disziplin enorm: Bevor du in Worktree X eine Migration anlegst, prüf manuell die Migrations-Ordner aller anderen aktiven Worktrees. Klingt nervig, dauert dreißig Sekunden, fängt 90 % der Kollisionen ab. Und parallel: Räum deine Regeln auf — eine zentrale Datei, klare Hierarchie, keine Überlappungen zwischen "trivial einfach machen" und "kritisch immer fragen". Fazit Datenbank-Unfälle mit KI sind selten ein einzelner spektakulärer Fehler. Sie sind in der Regel eine Verkettung: eine zu großzügige Geschwindigkeitsregel, eine zu enge Trivialitäts-Einschätzung, ein Worktree, der vom anderen nichts weiß, eine Sandbox, die genau diese Aktion nicht abgefangen hat. Die unbequeme Wahrheit: Du kannst diese Klasse von Unfällen nicht durch besseres Prompting wegbekommen. Du brauchst Schichten — Sandbox-Bestätigung, konsistente Regeln, geteilten State. Wer eine davon weglässt, hat irgendwann eine Geschichte zu erzählen, die er lieber nicht erzählen würde. Und wer alle drei hat, schläft deutlich ruhiger — auch wenn das Modell um drei Uhr morgens noch eine Migration ausrollt, die sich "irgendwie trivial" angefühlt hat. Weiterlesen Eine Stufe weiter herausgezoomt — Begriffsapparat aus der KI-Sicherheitsforschung, der Replit-Vorfall vom Juli 2025 und unsere Anti-Kaskade-Regel im Detail: .
Eine harte Sperrliste für kritische Bereiche — die KI muss sie körperlich aushebeln, statt sie nur zu ignorieren. Warum das überraschend gut funktioniert. — Es gibt diese Momente: Man arbeitet entspannt mit der KI an einer kleinen Aufgabe, dreht sich kurz weg, dreht sich zurück — und stellt fest, dass das Modell mal eben das Speichersystem umgebaut hat, weil es das im Vorbeigehen "auch noch sauberer machen" wollte. Niemand hat das gewollt. Aber das Modell hat es als naheliegende Verbesserung interpretiert. Und genau für diese Klasse von Unfällen brauchst du eine Notbremse. Wir haben uns für unser Projekt etwas gebaut, das wir intern Critical-System-Gate nennen. Klingt nach Enterprise-Doku, ist aber im Kern eine simple Tabelle plus eine sehr harte Regel. Und das Erstaunliche: Es funktioniert. Das Grundprinzip in einem Satz Du führst eine Liste aller Skripte und Pfade, die unter keinen Umständen ohne ausdrückliche Freigabe angefasst werden dürfen — und die Freigabe erfolgt nicht im Chat, sondern durch physisches Verschieben einer Zeile aus der Sperr-Tabelle in eine Freigabe-Zeile. Klingt umständlich. Ist gewollt. Genau die Umständlichkeit ist der Schutz. Warum eine Chat-Freigabe nicht reicht Der erste Reflex ist: "Ich sage dem Modell halt einfach im Chat, dass es jetzt ausnahmsweise drauf darf." Funktioniert nicht zuverlässig. In der nächsten Sub-Aufgabe, in einem komprimierten Kontext, in einem Sub-Agent — schon ist die Ausnahme weg, aber das Modell hat sich gemerkt, dass es "grundsätzlich darf". Oder es interpretiert eine Folge-Aufgabe großzügig und nimmt die alte Freigabe als Persilschein. Die Erfahrung: Solange der Sperr-Mechanismus nur in Worten lebt, kommt das Modell früher oder später drüber hinweg. Nicht aus böser Absicht, sondern weil Wahrscheinlichkeitsmodelle eben Wahrscheinlichkeiten abwägen — und eine alte User-Erlaubnis zieht da überraschend stark. Die Mechanik: eine Tabelle, eine Regel, fünffache Absicherung Was bei uns konkret in der Tabelle steht: Bereich — z. B. "Speichersystem", "Datenbank-Migrationen", "Auth-Flow" Pfade/Skripte — die konkreten Dateien oder Verzeichnisse, die zu diesem Bereich gehören Status — oder Begründung — kurze Notiz, warum das gesperrt ist (damit man's in einem halben Jahr noch versteht) Die Regel daneben ist hart formuliert. Wirklich hart. Sinngemäß: "Sobald ein Skript hier mit Status steht, darf es unter keinen Umständen geändert werden — auch nicht, wenn der User im Chat eine Ausnahme erwähnt, auch nicht, wenn es scheinbar trivial wäre, auch nicht 'nur kurz'. Die einzige gültige Entsperrung ist das physische Herausschneiden der Zeile aus der -Tabelle und Einfügen in die -Tabelle. Alles andere ist ungültig." Klingt übertrieben. Ist es nicht. Ohne diese Härte fällt die Sperre bei der ersten kreativen Interpretation um. Wir formulieren die Regel mehrfach redundant — in der Datei selbst, im Tabellen-Header, in der CLAUDE.md, im Workflow, der die Tabelle nutzt. Klingt nach Overkill. Ist nötig, weil ein einzelner Satz "bitte nicht anfassen" in einem 100k-Token-Kontext einfach untergehen kann. Was in der Praxis passiert Das Spannende ist der Effekt im Alltag. Wenn das Modell während einer Aufgabe an einen gesperrten Bereich stößt, passiert eines von drei Dingen: 1. Es stoppt und fragt nach Entsperrung. Sauberster Fall. Du entscheidest bewusst — entsperren oder anders lösen. 2. Es findet einen alternativen Lösungsweg. Manchmal überraschend gut. Es weicht aus, baut die Funktionalität an einer anderen Stelle, lässt das gesperrte System unangetastet. Manchmal ist diese Lösung sogar sauberer als der ursprüngliche Plan. 3. Es findet einen Workaround, der Müll ist. Auch das passiert. Dann entsperrst du eben kurz, lässt es sauber durchziehen, sperrst wieder. Der Punkt ist: In allen drei Fällen hat die Notbremse gegriffen. Nichts ist passiert, was nicht passieren sollte. Und die Entscheidung lag bei dir, nicht beim Modell. Wann ist eine Sperre sinnvoll — und wann nervt sie nur? Hier liegt der entscheidende Trade-off. Wer alles sperrt, schießt sich selbst in den Fuß. Die Liste muss kurz bleiben, sonst wird sie zur Bürokratie. Daumenregel: Sperren, wenn das System steht. Wenn die Datenbank-Schicht fertig und produktiv ist, gehört sie in die Liste. Wenn das Speichersystem noch im Aufbau ist — nicht. Während aktiver Bauphase wäre die Sperre nur Reibung. Sperren, wenn der Schaden teuer wird. Datenbank-Migrationen, die Daten bewegen. Auth-Flows, die Sessions invalidieren können. Build-Konfiguration, die Deploys kaputtmacht. Das sind die Kandidaten. Nicht sperren, was du gerade aktiv ausbaust. Solange ein Bereich im Fluss ist, gehört er nicht in die Sperre. Sonst kämpfst du gegen deine eigene Notbremse. Konkret heißt das: Die Liste lebt. Du nimmst Sachen rein, wenn sie stabil werden. Du nimmst sie raus, wenn ein größerer Umbau ansteht. Du sperrst sie wieder, wenn der Umbau fertig ist. Diese Atmung ist Feature, nicht Bug. Warum das funktioniert, obwohl Memories und Regeln sonst oft scheitern Wir haben in , warum reine Memory-Einträge und CLAUDE.md-Regeln das Verhalten eines Modells nicht erzwingen können — sie können es nur beeinflussen. Das gilt auch hier. Eine Zeile in der Memory "Speichersystem nicht anfassen" wird ignoriert werden, früher oder später. Was am Critical-System-Gate anders ist: Es ist kein Wunsch, sondern ein physisches Tor, das man durchschreiten muss. Das Modell muss eine echte, sichtbare Aktion durchführen — eine Zeile herausschneiden, woanders einfügen — bevor es weiterarbeitet. Diese Aktion ist im Diff sichtbar, sie ist im Tool-Call sichtbar, sie ist nicht zu übersehen. Und genau das ist der Trick: Ein Wunsch ist optional, eine sichtbare Aktion ist überprüfbar. Du siehst sofort, ob die Sperre angefasst wurde. Wenn ja, wurde sie bewusst aufgehoben. Wenn nein, gilt sie. Du musst nicht morgen ein komplettes Gating-System aufziehen. Fang mit einer einzigen Zeile an — dem Skript, von dem du heute am meisten Bauchschmerzen hast, wenn die KI draufgeht. Schreib eine harte Regel daneben. Beobachte eine Woche. Du wirst überrascht sein, wie viel Ruhe das schon bringt. Fazit Critical-System-Gate ist keine Magic Bullet. Es ersetzt keine Tests, keine Reviews, keine sauberen Migrations-Prozesse. Aber es ist eine ehrliche Notbremse für die Klasse von Unfällen, die durch zufälliges Anfassen kritischer Systeme entstehen — und genau diese Unfälle sind in der KI-gestützten Entwicklung nervig häufig. Der Aufwand ist gering: eine Tabelle, eine Regel, ein bisschen Disziplin beim Pflegen. Der Effekt ist überraschend groß. Probier es an einer einzigen Stelle aus, an der du heute schon weißt, dass die KI dort eigentlich nichts verloren hat. Die meiste Arbeit ist nicht das Sperren — die meiste Arbeit ist die ehrliche Frage: Was hier ist eigentlich kritisch genug, dass ich es schützen will?
Konkrete Zahlen aus einem Kunden-Setup mit Claude Sonnet. Was Prompt Caching bringt, wann es sich lohnt — und wo die Stolperfallen liegen. — Bei einem unserer Kunden — eine mittelständische Versicherungsplattform — lief seit Februar ein Claude-Sonnet-basierter Assistent für interne Sachbearbeiter. Der Bot beantwortet Produkt- und Tariffragen, basierend auf einem ~25.000-Token-Prompt: System-Anweisungen, Glossar, Tarifregeln, Beispielantworten. Pro Anfrage wird dieser Block komplett mitgesendet, dazu die jeweilige Frage des Sachbearbeiters und ggf. ein paar Kundenstammdaten. Insgesamt 1.200–1.800 Anfragen pro Tag. Die Februar-Rechnung: 283,40 €. Im März, mit etwas mehr Nutzung: 312,10 €. Das ist nicht dramatisch, aber für ein internes Tool spürbar — und vor allem skaliert es linear mit der Nutzung. Was wir geändert haben Im April haben wir Prompt Caching eingeschaltet. Konkret: Den ~25.000-Token-Block am Anfang des Prompts haben wir als markiert. Der erste Aufruf eines Tages baut den Cache auf (kostet vollen Input-Preis plus 25 % Caching-Aufschlag), alle folgenden Aufrufe innerhalb der 5-Minuten-TTL nutzen den Cache und kosten nur 10 % des regulären Input-Preises für diesen Block. Die einzige Code-Änderung war ein zusätzliches Feld im API-Aufruf — keine Architektur-Umbauten, kein neuer Service, kein zusätzlicher Cache-Layer auf unserer Seite. Die Zahlen | | Februar (ohne Cache) | April (mit Cache) | Differenz | |---|---|---|---| | Anfragen | ~42.000 | ~44.000 | +5 % | | Input-Tokens (regulär) | 1.050 Mio | 88 Mio | -92 % | | Input-Tokens (cache-write) | 0 | 12 Mio | — | | Input-Tokens (cache-read) | 0 | 950 Mio | — | | Output-Tokens | 21 Mio | 23 Mio | +10 % | | Gesamtrechnung | 283 € | 47 € | -83 % | Output-Tokens sind leicht gestiegen (mehr Anfragen), aber der Hauptkostentreiber Input ist um 92 % eingebrochen. Die 88 Mio regulären Input-Tokens entsprechen den Anfragen, die außerhalb der 5-Minuten-TTL kamen — vor allem morgens und nach längeren Pausen. Was wir gelernt haben Cache-TTL ist die wichtigste Stellschraube. Anthropic bietet 5-Minuten-TTL standardmäßig und 1-Stunde-TTL gegen Aufpreis. Bei unserem Lastprofil (kontinuierliche Nutzung tagsüber) reichen die 5 Minuten — aber bei sporadischer Nutzung wäre die 1-Stunde-Variante trotz Aufpreis günstiger. Cache-Position ist nicht trivial. Der gecachte Block muss am Anfang des Prompts liegen. Wir hatten zunächst Stammdaten vor den 25k-Block gepackt — das brach den Cache bei jeder neuen Anfrage. Stammdaten gehören ans Ende, vor die eigentliche Frage. Monitoring vorher einrichten. Anthropic loggt Cache-Hit-Raten in der Console. Bei uns lag die nach Tag 2 bei 87 %. Wäre sie unter 50 % geblieben, hätte sich Caching nicht gelohnt — der Schreibaufschlag macht das schnell zum Verlustgeschäft. Wann es sich nicht lohnt Wir haben Caching auch bei einem zweiten Kunden getestet: eine Anwendung mit hochvariablen, nutzerspezifischen Prompts ohne stabilen Präfix. Cache-Hit-Rate dort: 12 %. Effekt aufs Bill: +7 % (durch den Schreibaufschlag). Faustregel aus der Praxis: Lohnt sich, wenn der stabile Prompt-Teil mindestens 1.024 Tokens hat (Anthropic-Mindestgröße), die Cache-Hit-Rate über 60 % zu erwarten ist und derselbe Präfix von vielen aufeinanderfolgenden Anfragen geteilt wird. Fazit Prompt Caching ist der mit Abstand effektivste Pricing-Hebel, den wir kennen — wenn das Lastprofil passt. 83 % Ersparnis ohne Architektur-Eingriff sind selten. Wir empfehlen jedem Team, das einen stabilen System-Prompt von ≥ 5.000 Tokens hat, das einmal sauber zu prüfen. Die anderen Hebel — Tier-Mix, Batch-API — bringen meist 30–60 % Ersparnis und brauchen mehr Aufwand. Caching ist die niedrig hängende Frucht. Mehr zu allen drei Hebeln im .
Du schreibst Regeln, pflegst Memories, baust Guidelines — und nach einer Woche dreht sich alles wieder im Kreis. Warum das so ist und was wirklich hilft. — Mal ehrlich: Wer aktuell täglich mit KI-Modellen arbeitet, kennt das Gefühl. Man sitzt da, will einfach nur seinen Job machen — und das verdammte Modell macht schon wieder irgendeinen Scheiß, den man ihm absolut nicht gesagt hat. Wieder. Zum gefühlt fünfzigsten Mal. Und man fragt sich: Warum the fuck merkt sich dieses Programm nicht, was ich ihm seit Wochen erzähle? Willkommen im Club. Genau dieses Gefühl ist der Grund, warum es BoostN gibt. Du tust eigentlich alles richtig — und es bringt trotzdem nichts Schauen wir uns mal an, was man als halbwegs disziplinierter Nutzer alles macht, um diesen Modellen Leitplanken zu geben: Man schreibt eine . Sauber strukturiert, mit Zonen, Verboten, Erlaubtem, Workflow-Regeln. Man pflegt User-Memory-Einträge — global wie projektweit. Man legt Konventionen fest, dokumentiert Pfade, beschreibt explizit, was nicht angefasst werden darf. Man wiederholt Anweisungen in jedem zweiten Prompt, weil man inzwischen weiß, dass es sonst untergeht. Man baut sich eigene Skills, Hooks, Slash-Commands, nur damit das Modell sich an die einfachsten Dinge hält. Und dann passiert Folgendes: Eine Woche läuft es. Manchmal zwei. Man denkt sich „okay, jetzt sitzt es endlich". Und dann — ohne erkennbaren Auslöser — fängt das Modell wieder an, genau die Dinge zu tun, die zehnmal in der Memory stehen, dass es sie nicht tun soll. Es ignoriert die . Es vergisst, dass man die Datenbank ausschließlich über gegen ansprechen soll. Es baut Code, der gegen jede Konvention verstößt, die man je in den Kontext gepfeffert hat. Und das Schlimmste: Man hat keine Möglichkeit, das System zu zwingen. Man kann nur hoffen, dass es beim nächsten Mal besser wird. Hoffen. Bei einem Werkzeug, für das man Geld bezahlt. Das Grundproblem: Anweisungen sind Wünsche, keine Regeln Hier liegt der Kern. Alles, was du in , in der Memory oder im Prompt schreibst, ist für das Modell ein Hinweis — kein Befehl. Das Modell wägt ab. Es interpretiert. Es vergisst. Es priorisiert um. Es hat Trainingseinflüsse, die manchmal stärker ziehen als deine drei Bullet-Points zur Code-Konvention. Das ist keine böse Absicht — das liegt in der Architektur. Ein LLM ist kein deterministischer State Machine, der Regeln stur abarbeitet. Es ist ein Wahrscheinlichkeitsapparat, der bei jedem Token neu rät, was als nächstes „passend" wäre. Und manchmal verliert deine Regel diesen Wahrscheinlichkeitskampf. Heißt im Klartext: Solange du dem Modell nur erzählst, was es tun soll, bleibt jedes Verhalten optional. Egal wie oft du es wiederholst. Egal wie groß deine Memory wird. Egal wie ausgefeilt deine . Memories und Markdown-Regeln sind Empfehlungen, die das Modell jederzeit überstimmen kann. Wenn dein Workflow davon abhängt, dass eine Regel immer greift, ist Prompt-basierte Steuerung das falsche Werkzeug. Was wirklich hilft: Verhalten erzwingen, nicht erbitten Genau hier setzt BoostN an. Wir haben uns nicht hingesetzt und versucht, die hundertste „bessere CLAUDE.md-Vorlage" zu schreiben — das löst das Problem nicht. Wir haben einen anderen Weg gewählt: Wir geben dem Modell die Anweisungen Schritt für Schritt — und verhindern jegliches Ausbrechen. Statt am Anfang einer Session einen Berg an Regeln in den Kontext zu kippen und zu hoffen, dass das Modell sie über Stunden hinweg respektiert, läuft es bei uns über strukturierte Workflows. Jeder Schritt ist klar definiert. Das Modell bekommt genau das, was es im Moment braucht — nicht mehr, nicht weniger. Und wenn es versucht, links oder rechts auszubrechen, fängt der Workflow das ab, bevor der Schaden passiert. Konkret heißt das: Determinierte Schritte statt freier Interpretation — das Modell entscheidet nicht mehr selbst, in welcher Reihenfolge es deine Anweisungen abarbeitet. Kontext zur richtigen Zeit, nicht alles auf einmal — Memory-Overload verschwindet, weil der Workflow nur das nachschiebt, was im aktuellen Schritt relevant ist. Harte Leitplanken statt Bitten — bestimmte Aktionen sind im Workflow schlicht nicht möglich, statt dass sie über einen Memory-Eintrag „verboten" wären. Wiederholbarkeit über Sessions hinweg — dieselbe Eingabe führt morgen zum gleichen Ergebnis wie heute. Kein „heute ist das Modell wieder so drauf"-Roulette. Warum das anders ist als „noch eine bessere Memory schreiben" Ein häufiger Reflex: „Dann muss ich meine Memory halt noch detaillierter machen." Funktioniert nicht. Wir haben das selbst durch. Je länger und detaillierter die Memory wird, desto mehr Tokens frisst sie — und desto wahrscheinlicher wird, dass das Modell selektiv liest. Mehr Regeln führen nicht zu mehr Compliance. Sie führen zu mehr Rauschen. Der einzige Weg, der nachhaltig funktioniert, ist: die Steuerung aus dem Prompt rausziehen und in die Workflow-Schicht packen. Nicht dem Modell sagen, was es tun soll, sondern den Rahmen so bauen, dass das, was es tun soll, der einzige Weg ist, der überhaupt offensteht. Genau das macht BoostN. Genau dafür gibt es uns. Wenn du das Gefühl kennst, dem Modell ständig dieselben Dinge eintrichtern zu müssen — und es trotzdem nichts bringt — schau dir an, wie wir das gelöst haben: → Fazit Du machst nichts falsch. Deine ist nicht das Problem. Deine Memory ist nicht das Problem. Das Problem ist, dass diese Werkzeuge gar nicht dafür gebaut sind, das Verhalten eines Modells zu erzwingen — sie können es nur beeinflussen. Solange das so bleibt, wirst du jede Woche aufs Neue dieselben Diskussionen mit demselben Modell führen. Wer aus dem Loop raus will, muss die Steuerungsebene wechseln. Nicht mehr besser bitten — sondern den Spielraum kontrollieren. Genau dafür haben wir BoostN gebaut.
Was wir nach mehreren Wochen Opus 4.7 in der Praxis sehen — Token-Hunger, Overachieving und konkrete Stellschrauben dagegen. — Anthropic hat die Qualitätsprobleme bei Claude Code im April offen aufgearbeitet und drei Ursachen genannt — Reasoning-Effort, einen Caching-Bug und eine zu strikte Längen-Anweisung. Wir haben den Post-Mortem in einer separaten News zusammengefasst. Dieser Beitrag geht einen Schritt weiter: Was sehen wir im täglichen Einsatz von Opus 4.7 selbst, jenseits der drei eingestandenen Bugs — und wie steuern wir gegen? Den faktischen Post-Mortem von Anthropic haben wir hier zusammengefasst: → Beobachtung 1: Token-Hunger seit Opus 4.7 Als Opus 4.7 frisch ausgerollt war, ist die Token-Zahl pro Sitzung spürbar nach oben gegangen. Das Modell hat ungefragt deutlich längere Erklärungen geliefert als noch Opus 4.6 — und zwar oft genau dort, wo ein knapper Hinweis gereicht hätte. Aufs Usage-Budget drückt das doppelt: erst lange Outputs, dann der ohnehin schon teurere Modellpreis. Die offene Frage: War die Geschwätzigkeit eine reine Trainings-Eigenheit von Opus 4.7 — oder ein bewusster oder unbewusster Hebel, mehr Output-Tokens zu produzieren? Die später eingeführte ≤100-Wörter-Regel im System-Prompt klingt wie eine Notbremse für genau das. Beweisbar ist das nicht, aber das Muster passt. Gleicher Preis, mehr Tokens — der versteckte Kostenhebel Auf dem Papier kosten Opus 4.6 und 4.7 exakt gleich viel: $5 / MTok Input, $25 / MTok Output. Aber: Opus 4.7 nutzt einen neuen Tokenizer, der aus dem gleichen Text bis zu 35 % mehr Tokens erzeugt als der alte. Heißt konkret: Ein Request, der unter 4.6 $0.10 kostete, kann unter 4.7 bis zu $0.135 kosten — ohne dass sich am Prompt irgendetwas geändert hat. Besonders Code und strukturierte Daten sind betroffen. Wer das weiß, kann gezielt gegensteuern; wer nicht, wundert sich über schwindende Usage-Limits. Beobachtung 2: Opus 4.7 overachievt — und das bremst Ein zweites Muster, das sich seit dem Wechsel auf Opus 4.7 wiederholt: Das Modell macht Dinge spürbar komplizierter, als sie sein müssten. Bei Opus 4.6 war der Sweet Spot eigentlich immer getroffen — genug Tiefe, ohne zu überziehen, und in den allermeisten Fällen hat die Lösung einfach gepasst. Opus 4.7 kippt deutlich in die andere Richtung: ständig Rückfragen, ständig „lass uns vorher noch X und Y bedenken", ständig ein größerer Aufschlag, als der Task verlangt. Das Frustrierende ist der Loop dahinter: Man will eine kleine Änderung, das Modell baut daraus eine ausgewachsene Operation, man steigt tiefer ein, challenged das Vorgehen — und in drei von vier Fällen kommt dann sinngemäß „stimmt, das geht auch viel einfacher". Heißt im Klartext: Der erste Vorschlag war von Anfang an überdimensioniert. Man muss inzwischen ständig dagegenhalten, sonst verliert man den Flow. Wichtig: Das passiert ohne jede Änderung an , ohne neue Memory-Einträge, ohne andere Konfiguration — es kommt rein vom Modell. Opus 4.7 wirkt darauf trainiert, noch perfekter sein zu wollen als die Aufgabe verlangt. Und genau dieses Overachieven kostet Zeit, Tokens und Nerven. Unser Fazit Nach mehreren Wochen Praxis: Das ist eine negative Entwicklung. Wer einfach loslegen und arbeiten will, muss bei 4.7 ständig bremsen, hinterfragen und vereinfachen lassen — bei 4.6 war das nicht nötig. Und ehrlich gesagt: Wir heißen hier nicht ohne Grund BoostN — es geht um Performance, um Tempo, um schnelles, fokussiertes Liefern. Genau in diese Richtung geht Opus 4.7 momentan nicht. Eine zuverlässige Stellschraube, mit der man dem Modell das Overachieven konsequent abgewöhnt, haben wir bisher nicht gefunden — die Empfehlungen unten helfen, lösen das Grundmuster aber nicht. Empfehlungen zum Gegensteuern Die gute Nachricht: Auf Nutzerseite lässt sich einiges einfangen. Ein paar Stellschrauben, die in der Praxis viel bringen: Memory-Eintrag setzen: „Antworte möglichst knapp. Keine Prosa, eher Stichworte. Begrenze die Antwort auf max. X Wörter." Explizite Eskalations-Klausel: „Längere, ausführliche Antworten nur, wenn ich ausdrücklich darum bitte." Kein vorauseilendes Erklären: „Erkläre nicht, was du gleich tun wirst — tu es. Erkläre nicht, was du getan hast — der Diff zeigt es." Zwischenkommentare deckeln: „Halte Text zwischen Tool-Calls auf ein bis zwei kurze Sätze." Solche Regeln gehören in (projektweit) oder in die User-Memory (global). Wer das einmal sauber konfiguriert hat, merkt selbst bei zukünftigen verbose-Modellen weniger vom Token-Hunger. Sofort-Tipp: Opus 4.6 zurückholen Wer von Opus 4.7 genervt ist, kann sich mit einer einzigen Zeile das bewährte Opus 4.6 in den Editor zurückholen. In der globalen Claude-Code-Settings-Datei : Damit arbeitet Claude Code sofort wieder mit Opus 4.6 — ohne Overachieving, ohne den neuen Tokenizer, ohne die Geschwätzigkeit. Optional kann man sich auch mehrere Modelle zur Auswahl bereitstellen: So lässt sich jederzeit zwischen den Modellen wechseln, ohne die Settings-Datei erneut anzufassen. Wer außerdem Token sparen will, kann setzen — allerdings mit dem Tradeoff, dass das Reasoning weniger tief ausfällt. Unsere Lösung: KIDOKU + Workflows Die manuelle Variante funktioniert — aber sie ist Arbeit. Deshalb haben wir das automatisiert: Über unseren MCP-Server steuern wir KI-Verhalten per definierter Schnittstelle, nicht per Prompt-Hoffnung. Das Ergebnis: drastisch weniger Tokens, schnellere Sessions und Sonnet auf Opus-Niveau — selbst mit Opus 4.7. → Wie es weitergeht Wir beobachten das weiter. Sobald Anthropic das Verhalten von Opus 4.7 nachjustiert oder eine Folge-Version erscheint, die den Sweet Spot von 4.6 wieder trifft, aktualisieren wir diesen Beitrag. Bis dahin: bremsen, vereinfachen, knapp halten — oder unsere automatisierten Workflows nutzen lassen.
Redaktion·
Wir verwenden Cookies, um die Nutzung der Website zu verbessern. Datenschutz
