Vor einer langen Aufgabe in Claude Code: Wann compact sinnvoll ist und wie du Subagenten und Verbrauch kontrollierst

Bevor du Claude Code längere Zeit Code lesen, Änderungen vornehmen und Tests ausführen lässt, solltest du den Kontext nicht vorschnell leeren. Du musst aber auch nicht jede alte Diskussion behalten, nur um „die ganzen 1M auszunutzen“.

Kläre zuerst die wichtigeren Fragen: Welche ursprünglichen Details braucht der nächste Schritt noch? Lässt sich die Arbeit, die du delegieren möchtest, unabhängig erledigen? Und woran erkennst du nach Abschluss der Aufgabe, dass die Änderung tatsächlich geholfen hat — statt lediglich eine kleinere Verbrauchszahl zu erzeugen?

Am 19. September berichtete ZryMiller, dass er seine Vorgehensweise geändert hatte. Zuvor hatte er häufig kompaktiert und war dann zu dem von ihm als Standard bezeichneten 1M-Fenster zurückgekehrt. Seiner Einschätzung nach verbesserte sich die Arbeit damit deutlich; außerdem bereitete er nach eigenen Angaben die Veröffentlichung seiner ersten App vor. Der Beitrag enthält jedoch weder vergleichbare Aufgaben noch Verbrauchswerte vor und nach der Änderung oder ein Ergebnis, das die tatsächliche Veröffentlichung der App bestätigt. Das ist eine interessante persönliche Erfahrung, aber kein Beleg dafür, dass „jede lange Aufgabe ohne Kompaktierung besser gelingt“.

Entscheide also nicht pauschal zwischen „häufig kompaktieren“ und „niemals kompaktieren“, sondern an einem konkreten Übergang zwischen Arbeitsschritten.

Prüfe zuerst, was du tatsächlich verwendest

Führe im Terminal claude --version aus und notiere die Client-Version. Prüfe innerhalb der Sitzung mit /status das Konto und das aktuelle Modell, mit /model die verfügbaren Modelle und zugehörigen Einstellungen und mit /context die Kontextbelegung. Verbrauchsinformationen findest du über /usage. Diese Befehle zeigen unterschiedliche Informationen; sie sind keine austauschbaren Messgrößen. Offizielle Befehlsreferenz · Dokumentation zum Verbrauch

Die offizielle Modellbezeichnung in dieser Diskussion lautet Claude Fable 5.1. Die Modell-ID in der Claude API ist claude-fable-5-1, und die offizielle Spezifikation nennt ein Kontextfenster von 1M Tokens. Modell, Claude-Code-Version und effort-Einstellung sind unterschiedliche Angaben. Halte sie nicht bloß als „Fable verwendet“ oder „Ultra verwendet“ fest. Offizielle Modellspezifikation

Dass ein Modell 1M unterstützt, bedeutet nicht, dass automatisch für alle Konten, Modelle und Zugangswege dieselben Nutzungsbedingungen gelten. Die offizielle Dokumentation unterscheidet beispielsweise zwischen dem in Max, Team und Enterprise enthaltenen 1M-Zugang für Opus und dem Zugang in Pro, der usage credits erfordert. Auch das 1M-Fenster von Sonnet 4.6 benötigt bei Abonnements usage credits. Übertrage diese Regeln nicht ungeprüft auf andere Modelle. Client-Konfiguration, Modellzuordnung und Gateway-Unterstützung müssen ebenfalls geprüft werden: [1m] in der Modellauswahl hinzuzufügen erweitert nicht von selbst die Fähigkeiten des serverseitigen Modells. Voraussetzungen für 1M und Modellkonfiguration

Unterscheide außerdem drei leicht zu verwechselnde Zahlen: Die Kontextbelegung beschreibt, wie viel Inhalt die aktuelle Anfrage aufnehmen muss. Der kumulierte Token-Verbrauch erfasst, wie viele Eingabe-, Ausgabe- und Cache-Inhalte die Anfragen verarbeitet haben. Das Abo-Kontingent ist die Begrenzung des Kontos im jeweiligen Nutzungszeitfenster. Fünf Stunden oder eine Woche bezeichnen ein Kontingentfenster, nicht die Zusage, dass eine Aufgabe fünf Stunden oder eine Woche ununterbrochen laufen kann. Inhalte aus dem Cache belegen weiterhin Kontext, auch wenn die API-Abrechnung dafür andere Cache-Tarife ansetzen kann. „30 % des Kontexts belegt“ lässt sich daher nicht in „30 % des Fünf-Stunden-Kontingents verbraucht“ umrechnen. 1M ist auch kein Token-Guthaben, das beliebig oft kostenlos verarbeitet werden kann. Kontext und Caching · Preisstruktur der API

Überlege vor compact, welche Details der nächste Schritt noch braucht

Angenommen, du untersuchst einen Fehler, der Frontend, API und Datenbank betrifft. Die gerade gelesenen Codeausschnitte, eine fehlgeschlagene Anfrage und ein entdeckter Grenzfall haben noch keine überprüfbaren Schlussfolgerungen ergeben. Wenn du allein deshalb kompaktierst, weil „der Chat schon lang ist“, können genau die Details verloren gehen, die du als Nächstes miteinander abgleichen musst.

Ist dagegen die Ursache klar, sind die relevanten Dateien und Belegstellen notiert und steht nur noch eine kleine Implementierungsänderung nach einem abgestimmten Plan an, muss ein Großteil der bisherigen Suche möglicherweise nicht im aktuellen Fenster bleiben.

Ein geeigneter Zeitpunkt zum Kompaktieren wird nicht durch einen allgemeingültigen Prozentsatz bestimmt. Er ist erreicht, wenn eine Arbeitsphase abgeschlossen ist und zuverlässige Aufzeichnungen zum Weiterarbeiten ausreichen. Das ist eine Empfehlung für die Arbeitsweise, kein fester Schwellenwert des Modells.

Lass Claude zunächst den nötigen Stand in der von dir angegebenen Aufgabenaufzeichnung festhalten: bestätigte Fakten und Belegstellen, tatsächlich geänderte Dateien, ausgeführte Prüfungen mit ihren echten Ergebnissen, offene Fragen und den nächsten Schritt. Der gesamte Chat muss nicht kopiert werden. Ungeprüfte Vermutungen dürfen dabei nicht zu Schlussfolgerungen werden.

Anschließend kannst du den nativen Befehl /compact verwenden und angeben, was erhalten bleiben soll: Funktionsweise der Kompaktierung

/compact Behalte das aktuelle Ziel, bestätigte Schlussfolgerungen und Belegstellen, geänderte Dateien, ausgeführte Prüfungen mit ihren tatsächlichen Ergebnissen, offene Fragen und den nächsten Schritt bei. Entferne wiederholte Suchen und Diskussionen über bereits ausgeschlossene Möglichkeiten.

Dieser Text beschreibt Anforderungen an die Zusammenfassung, garantiert aber keinen verlustfreien Vorgang. Lass Claude vor weiteren Änderungen anhand des kompaktierten Kontexts erklären, was als Nächstes zu tun ist, und gleiche die wesentlichen Vorgaben mit den tatsächlichen Dateien und der Aufgabenaufzeichnung ab. Fehlt ein Grenzfall, ergänze ihn zuerst, statt erst eine abweichende Implementierung nacharbeiten zu müssen.

Wenn die nächste Aufgabe nichts mit der bisherigen zu tun hat, ist es meist einfacher, Ergebnisse und Übergabeinformationen zu speichern und mit /clear eine neue Sitzung zu beginnen. Mit /resume kannst du bei Bedarf zum ursprünglichen Gespräch zurückkehren. Das Leeren einer Sitzung erstattet keinen bereits angefallenen Verbrauch und setzt das Abo-Kontingent nicht zurück. Sitzungsbefehle · Was in der Verbrauchsanzeige zurückgesetzt wird

Claude Code verfügt bereits über automatische Kompaktierung. Für diese Arbeitsweise musst du also kein Plugin installieren. Ab v2.1.221 gibt es außerdem /autocompact: Ohne Argumente zeigt der Befehl das aktuelle Fenster für die automatische Kompaktierung an; /autocompact auto stellt die auf das Modell abgestimmte Fenstereinstellung wieder her. Letzteres speichert eine Einstellung, statt dem Modell lediglich eine Präferenz mitzuteilen. Das maximale Kontextfenster des Modells und das Fenster für automatische Kompaktierung sind nicht dasselbe. Befehl für automatische Kompaktierung

HKTECH_AI schätzte, dass eine einzelne Kompaktierung etwa 15 % eines Fünf-Stunden-Kontingents verbrauchen könnte. Der Beitrag enthält weder eine Rechnung noch eine Berechnungsmethode. Dieser Prozentsatz sollte deshalb keine Nutzungsregel werden. Entscheidend ist, ob nach dem Kompaktieren weniger Inhalte wiederholt in nachfolgende Anfragen übernommen werden — und ob dafür erneutes Lesen, Erklären oder Korrigieren nötig wird.

Subagenten können Arbeit aufteilen — aber „einer nach dem anderen“ muss richtig umgesetzt werden

SHCH beschrieb folgende Rollenverteilung: Fable plant und trifft Entscheidungen, ein Scout mit Sonnet übernimmt die Suche und ein Builder mit Opus führt klar definierte Aufgaben aus. Dabei riet er ausdrücklich dazu, jeweils nur einen Subagenten aufzurufen.

Sein veröffentlichter Builder-Screenshot betont, den vorhandenen Plan einzuhalten, bei Problemen mit dem Plan anzuhalten und zu berichten, keine weiteren Subagenten zu starten und die Prüfergebnisse zu nennen. Diese Anweisungen sind nützlich, weil sie Verantwortlichkeiten abgrenzen. „Starte keine weiteren Subagenten“ auf einem Bild bleibt aber eine Vorgabe im Prompt, kein softwareseitig erzwungenes Limit. Der Autor erwähnte außerdem mehrere gleichzeitig laufende Hauptsitzungen und veröffentlichte keine überprüfbaren Verbrauchswerte vor und nach der Umstellung. Die Konfiguration bedeutet daher nicht „nur ein Agent im gesamten Konto“, und erst recht lässt sich daraus kein fester Einsparungsprozentsatz ableiten.

Ein gewöhnlicher Subagent beginnt mit einem eigenen Kontext und erhält die delegierte Aufgabe sowie die zugehörige Konfiguration. Er bekommt nicht automatisch den gesamten Gesprächsverlauf der Hauptsitzung; ein fork-Subagent übernimmt dagegen die bestehende Unterhaltung. Eine Untersuchung mit vielen Zwischenschritten in einen Subagenten auszulagern kann die Prozessdetails in der Hauptsitzung reduzieren. Die Anfragen des Subagenten verarbeiten aber weiterhin Tokens, und sein zurückgegebenes Ergebnis gelangt ebenfalls in die Hauptsitzung. Kontextgrenzen von Subagenten

Frage deshalb zuerst „Lohnt es sich, diese Aufgabe zu delegieren?“ und erst danach „Wie viele sollen gleichzeitig laufen?“. Eine einfache Suche braucht keine vollständige Kette aus Planer, Rechercheur und Ausführendem. Auch zwei Aufgaben, die wiederholt dieselbe Datei ändern, eignen sich nicht unbedingt für parallele Ausführung. Wirklich unabhängige Untersuchungen mit klaren Ergebnissen sind bessere Kandidaten für einen parallelen Vergleich.

Du kannst die Arbeitsanweisungen beispielsweise so konkretisieren:

Ziel: Die vereinbarten Änderungen umsetzen und die unmittelbar relevanten Prüfungen bestehen.
Erlaubter Umfang: Die von dieser Anforderung betroffene Implementierung und die zugehörigen Tests.
Vorgehen: Einfache Suchen direkt ausführen. Nur bei tatsächlichem Bedarf delegieren, dabei ausschließlich den für die Teilaufgabe nötigen Kontext und die Ergebnisanforderungen übergeben und jeweils einen Subagenten beauftragen. Während des Wartens nicht wiederholt denselben Status abfragen.
Abschlusskriterien: Gemäß den Abnahmekriterien liefern und nach bestandenen relevanten Prüfungen aufhören. Bei einer Blockade den erledigten Teil und die Ursache nennen; dieselbe Aufgabe nicht erneut starten.

Das sind weiterhin Verhaltensanweisungen. Wenn du die Erstellung nativer Subagenten tatsächlich begrenzen möchtest, verwende die Steuerelemente des Clients. Claude Code unterstützt ab v2.1.217 Grenzen für gleichzeitige Ausführung und Delegationstiefe. Das folgende Startbeispiel für Bash/Zsh unter macOS und Linux ist ein vorsichtiger Ausgangspunkt, um unnötige Parallelität zu untersuchen: Referenz der Umgebungsvariablen

CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS=1 \
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 \
claude

Die erste Variable legt die sitzungsbezogene Parallelitätsprüfung fest, wenn über das Werkzeug Agent neue Subagenten erstellt werden. Die zweite begrenzt Subagenten auf eine Ebene und verhindert weitere verschachtelte Delegation. Es handelt sich nicht um Prompts; andere bereits gestartete Sitzungen werden damit auch nicht rückwirkend verändert. Referenz der Umgebungsvariablen

Das ist allerdings keine globale Sperre nach dem Prinzip „überall und jederzeit höchstens ein Agent“. Die offizielle Dokumentation nennt ausdrücklich Ausnahmen: ultracode-Sitzungen wenden diese Parallelitätsgrenze nicht an; manuelles /subtask und das Fortsetzen bereits abgeschlossener Subagenten werden nicht von derselben Neuerstellungsprüfung blockiert; Workflows und agent teams haben eigene Limits. Mehrere Hauptsitzungen und extern gestartete Prozesse lassen sich mit dieser einen Einstellung ebenfalls nicht gemeinsam begrenzen. Parallelitätsgrenzen und Ausnahmen

Brauchst du in deinem eigenen Scheduler eine echte globale Obergrenze, müssen Starts, Fortsetzungen und Wiederholungsversuche über eine gemeinsame Warteschlange oder Parallelitätssperre koordiniert werden. „Einer nach dem anderen“ im Prompt reicht nicht aus. Das gehört zu deiner eigenen Scheduler-Implementierung und ist keine weitere, undokumentierte Claude-Code-Einstellung.

Auf ein Ergebnis warten heißt nicht, das Modell ständig nach Fortschritt fragen zu lassen

LeeLeepenkman beklagte nicht bloß „den Einsatz von Subagenten“. Er beschrieb, dass Fable 5.1 muse einen großen Prompt übergab und anschließend ungefähr alle fünf Sekunden dessen Status abfragte, wodurch der Kontext schnell anwuchs. Der ursprüngliche Beitrag erklärt weder die konkrete Umsetzung von muse noch enthält er Anfrageprotokolle oder ein Ergebnis nach Behebung des Problems. Fünf Sekunden können deshalb nicht als festes Polling-Intervall von Claude Code dargestellt werden.

Native Hintergrund-Subagenten bieten derzeit Abschlussbenachrichtigungen; ihre Ergebnisse werden in späteren Gesprächsrunden an die Hauptsitzung zurückgegeben. Laufende Arbeit kannst du mit /tasks prüfen. Das ist etwas anderes, als das Modell immer wieder neue „Schon fertig?“-Anfragen senden zu lassen. Hintergrund-Subagenten und Ergebnisbenachrichtigungen

Klappe bei der Untersuchung die Werkzeugaufrufe der Sitzung auf und verfolge dieselbe Aufgabe: Liefern wiederholte Prüfungen neue Informationen? Wurde eine bereits abgeschlossene Aufgabe erneut gestartet? Hat die Statusabfrage tatsächlich einen neuen Modellaufruf ausgelöst? Ctrl+O öffnet eine detailliertere Gesprächsansicht. Die Anzahl der Aktualisierungen in der Oberfläche ist aber nicht gleich der Anzahl der Modellanfragen. Wenn du Verbrauchsdaten pro Anfrage brauchst, gleiche sie auch mit den Aufzeichnungen deines tatsächlichen Anbieters ab. Interaktion und Sitzungsansicht

Bei nativen Benachrichtigungen ist eine zusätzliche, vom Modell ausgeführte Schleife mit häufigen Statusabfragen in der Regel unnötig. Unterstützt ein externes Werkzeug nur Polling, kann das Programm in angemessenen Abständen nach Zustandsänderungen sehen, ein Timeout setzen und dem Modell nur bei einem neuen Ergebnis oder einer Ausnahme Informationen übergeben. Ziel ist es, Modellaufrufe ohne Informationsgewinn zu reduzieren — nicht, notwendige Fortschrittskontrolle zu verbieten.

Prüfe nach dem Zurücksetzen des Kontingents zuerst, was noch offen ist

intwerpret schilderte einen drastischeren Fall. Nach Erreichen des Nutzungslimits wählte er Warten mit automatischer Fortsetzung. Anschließend seien 39 Agenten aufgetaucht und hätten das Kontingent erneut aufgebraucht; schließlich wechselte er zurück zu Codex. Die Unterlagen enthalten weder Client-Version noch Aufgabeninhalt, vollständige Konfiguration oder die Herkunft des Fortsetzungsmechanismus. Ob die Aufgabe später abgeschlossen wurde, ist ebenfalls nicht bekannt.

Dieser Bericht ist ein Anlass, den Fortsetzungsablauf zu prüfen. Er beweist nicht, dass „Claude Code bei automatischer Fortsetzung zwangsläufig 39 Agenten startet“. Auch das vom Autor verwendete Wort „Ultra“ genügt nicht als Nachweis, dass er den zuvor erwähnten ultracode-Modus nutzte.

Umgekehrt lässt sich automatische Fortsetzung inzwischen auch nicht pauschal Drittanbieter-Skripten zuschreiben. Die offizielle Dokumentation zum interaktiven Modus beschreibt eine native Fortsetzung nach dem Zurücksetzen des Nutzungslimits: Ab v2.1.234 können berechtigte interaktive Abo-Sitzungen warten, bis wieder Kontingent verfügbar ist, und dann weiterarbeiten. Das ist nicht mit dem Verhalten bei API-Schlüsseln, -p oder sämtlichen Hintergrundmodi gleichzusetzen. Fortsetzen bedeutet auch nicht einfach, die letzte ursprüngliche Aufgabe des Nutzers erneut zu senden. Natives Warten und automatische Fortsetzung

Wenn die Aufgabe nicht unbeaufsichtigt weiterlaufen soll, deaktiviere in /config Continue automatically at usage limit (nach Zurücksetzen des Nutzungslimits automatisch fortsetzen). In Versionen, die diese Einstellung unterstützen, kannst du auch Folgendes ausführen:

/config autoContinueAtUsageLimit=false

Wartet die Sitzung bereits, musst du auch diesen konkreten Wartevorgang abbrechen: Drücke bei leerem Eingabefeld Esc oder wähle unter /rate-limit-options Don’t continue automatically (nicht automatisch fortsetzen). Die Standardeinstellung zu ändern und einen bereits gewählten Wartevorgang abzubrechen sind zwei verschiedene Schritte. Automatische Fortsetzung abbrechen und konfigurieren

Prüfe anschließend /tasks und den tatsächlichen Zustand der Dateien. Welche Aufgaben laufen noch, welche sind abgeschlossen und welche benötigen nur eine weitere Prüfung? Verwende vorhandene Ergebnisse weiter und benenne bei offener Arbeit klar das Fortsetzungsziel. Sende nicht die gesamte Anforderung erneut, damit sie noch einmal in Aufgaben zerlegt wird.

Gerade vor Commits, Deployments, dem Senden von Nachrichten oder anderen Aktionen mit Außenwirkung solltest du prüfen, ob der vorherige Versuch bereits erfolgreich war. Ein zurückgesetztes Kontingent beantwortet nur die Frage „Können weitere Anfragen gestellt werden?“. Es garantiert nicht, dass die nächsten Aktionen nichts bereits Erledigtes wiederholen.

Beurteile erst das Ergebnis und dann die Veränderung beim Verbrauch

chasemdev erklärte, dass er Fable nicht ständig selbst Code schreiben ließ, sondern zur Koordination von Opus-Subagenten einsetzte. Trotzdem erwartete er, bald das Wochenlimit zu erreichen. Dieses „bald“ war seine damalige Prognose, kein bestätigtes Endergebnis des Verbrauchs. Es erinnert aber an einen leicht übersehenen Punkt: Erfasse nicht nur das Hauptmodell, sondern auch die Modelle der Subagenten und ihre Arbeit.

Der Bereich Session in /usage zeigt aktuell den Token-Verbrauch der Sitzung und eine lokal berechnete Kostenschätzung. Abo-Nutzer sehen in derselben Oberfläche zusätzlich den Verbrauch ihres Tarifs. Der Dollarbetrag unter Session ist keine Abo-Rechnung und entspricht auch nicht zwingend der endgültigen Belastung durch den API-Anbieter. Bei nutzungsabhängiger Zahlung ist die Rechnung des tatsächlichen Anbieters maßgeblich. Was /usage derzeit bedeutet

Auch die lokale Zuordnung des Abo-Verbrauchs ist nur ein Hinweis. Die Aufschlüsselung nach Subagenten, Plugins, Skills und anderen Komponenten stammt aus dem jüngsten Verlauf auf diesem Rechner. Sie umfasst nicht die gesamte Nutzung auf anderen Geräten oder im Web und ist kein Kausalnachweis dafür, „wie viel Verschwendung ein Plugin verursacht hat“. Wenn Showing last-known usage erscheint, notiere den Zeitstand der angezeigten Daten und aktualisiere sie vor einem Vergleich. Umfang der Zuordnung und zwischengespeicherte Werte

Dafür brauchst du kein aufwendiges Evaluierungssystem. Wähle eine klar begrenzte, sicher reproduzierbare Aufgabe, schreibe ihre Abnahmekriterien auf und erfasse zu Beginn und am Ende Folgendes:

Was du erfasst	Welche Fragen du beantworten solltest
Aufgabe, Ausgangsversion des Codes, Modell, effort, Client-Version	Vergleichst du vorher und nachher dieselbe Art von Arbeit und dieselben Einstellungen?
/context und Kompaktierungsverlauf	Sind Vorgaben verloren gegangen, waren erneutes Lesen oder zusätzliche Erklärungen nötig?
Subagenten und Verhalten beim Warten	Welche Aufgaben wurden erstellt oder fortgesetzt, wie viele liefen maximal gleichzeitig, und gab es wiederholte Prüfungen ohne neue Informationen?
Verbrauchswerte, Zeitpunkte und Kontingent-Resets	Wurde das Kontingent zwischendurch zurückgesetzt, floss Aktivität anderer Sitzungen ein und wurden bei API-Nutzung alle beteiligten Modelle berücksichtigt?
Tatsächliche Ergebnisse und Prüfresultate	Sind die Anforderungen erfüllt, relevante Prüfungen bestanden und wie viel manuelle Nacharbeit bleibt?

Ändere jeweils nur eine Vorgehensweise — etwa erst nach Abschluss der Untersuchung zu kompaktieren oder die Parallelität bei neuen Subagenten zu begrenzen. Behalte die ursprünglichen Abnahmekriterien bei und verkleinere die Aufgabe nicht stillschweigend, um geringeren Verbrauch zu erzielen. Halte auch fest, ob sich der Cache-Zustand unterscheidet. Wurden bei zwei Durchläufen unterschiedliche Modelle, Codeversionen oder Aufgabenumfänge verwendet, darf nicht die gesamte Differenz der Kompaktierung zugeschrieben werden.

Weniger Tokens bei fehlenden Anforderungen oder einer dem Menschen überlassenen Prüfung sind keine Verbesserung. Umgekehrt ist ein stärker belegtes Kontextfenster allein kein Beleg für Verschwendung, wenn dadurch die Aufgabe in einem Durchgang ohne wiederholte Untersuchung fertig wird.

Führe getrennte Aufzeichnungen für unabhängige API-Nutzung und Abonnement. Ein Wechsel der Abrechnungsquelle setzt das ursprüngliche Abo-Kontingent nicht zurück und ändert auch nicht automatisch, wie der Client delegiert, wartet und kompaktiert. Ob der Wechsel sinnvoll ist, beurteilst du anhand von Gesamtverbrauch und Nacharbeit bis zum Abschluss derselben Aufgabe, nicht nur anhand des Einzelpreises eines Modells. Unterschiede zwischen Abrechnungsarten · Token-Abrechnung der API

Bevor ein Plugin über compact entscheidet, prüfe, welche Inhalte es nach außen sendet

Kun Chen ging von einer praktischen Frage aus: „when should i /compact my session“ — wann sollte ich meine aktuelle Sitzung kompaktieren? Sein compact-adviser verwendet Jev von TypeSafe, um einzuschätzen, ob ein geeigneter Übergang zwischen Arbeitsphasen erreicht ist. Das Plugin bietet einen Hinweismodus und einen automatischen Modus, der ausdrücklich aktiviert werden muss. Projektbeschreibung

Die Prüfung für diesen Artikel wurde auf Commit d1655faa16a22b68bff60c3d7deb0123e1e52a53 festgelegt. Dort nennt das Manifest des Claude-Code-Plugins die Version 0.1.4. Das Projekt setzt Node.js 22 oder neuer und Claude Code 2.1.274 oder neuer voraus und gibt an, mit 2.1.275 geprüft worden zu sein. Die Claude-Code-Anbindung beruht auf experimentellen Funktions-Hooks und erfordert CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1. Das sind die vom Projekt genannten Kompatibilitätsbedingungen, keine Ergebnisse eines Installationstests für diesen Artikel. Manifest der festgelegten Version · Versions- und Integrationsvoraussetzungen

Wichtiger ist: Der hint-Modus bedeutet nur, dass keine automatische Kompaktierung stattfindet. Er bedeutet nicht, dass die Entscheidung lokal fällt oder kein Kontext nach außen gesendet wird. Die Sicherheitsdokumentation beschreibt, dass nach der Installation ausgewählte Sitzungsinhalte an TypeSafe gesendet werden, sobald ein Schlüssel aus der Startumgebung, gespeicherten Einstellungen oder einer .env-Datei im Arbeitsverzeichnis verfügbar ist und die Aufrufbedingungen erfüllt sind. Dazu gehören Nutzervorgaben, jüngere sichtbare Antworten und Werkzeugergebnisse, eine vorhandene Zusammenfassung sowie Namen erzeugter Artefakte. Einen separaten Schalter zur Bestätigung der Weitergabe gibt es nicht. Die Auszüge können weiterhin Code oder Geschäftsinformationen enthalten; eine bestmögliche Bereinigung garantiert nicht, dass keine sensiblen Inhalte übrig bleiben. Grenzen der Kontextweitergabe

Ist das Plugin bereits installiert, kannst du es mit /compact-adviser off abschalten oder so starten:

COMPACT_ADVISER_DISABLE=1 claude

Laut Projektbeschreibung werden damit Anfragen, Hinweise und automatische Kompaktierung des Plugins gestoppt. Deaktiviert wird das Plugin, nicht die eigene automatische Kompaktierung von Claude Code. Dürfen Arbeitsinhalte nicht zusätzlich an TypeSafe geschickt werden, deaktiviere oder deinstalliere das Plugin, statt lediglich von auto auf hint umzuschalten. Deaktivierung

Die vom Autor erwähnte Evaluierung mit 40 Sitzungen stammt vom Projekt selbst; der Datensatz ist nicht öffentlich. Daraus ergibt sich keine Garantie, dass Details deiner eigenen Aufgaben erhalten bleiben. Selbst wenn das Plugin einen Zeitpunkt als „geeignet zum Kompaktieren“ einstuft, zählt am Ende, ob die Arbeit danach korrekt fortgesetzt werden kann. Grenzen der Evaluierung

All das lässt sich bereits ohne Plugin umsetzen: den Stand an Übergängen zwischen Arbeitsphasen sichern und die für den nächsten Schritt nötigen Details behalten; Subagenten klar abgegrenzte, unabhängige Aufgaben geben; doppelte Starts beim Warten und Fortsetzen vermeiden; und die Wirkung anhand von Ergebnissen und Verbrauchsaufzeichnungen gemeinsam beurteilen.

Das Ziel bei langen Aufgaben ist weder, das Kontextfenster zu füllen, noch jede einzelne Anfrage möglichst billig aussehen zu lassen. Es geht darum, weniger Arbeit ohne Fortschritt zu erzeugen und zuverlässig zu Ende zu bringen, was bereits begonnen wurde.