Forked Subagents in Claude Code: Warum ich keine normalen Subagents mehr nutze

Forked Subagents in Claude Code: Warum ich keine normalen Subagents mehr nutze

Es war 1:47 Uhr morgens, als mir klar wurde, dass ich seit vier Stunden das falsche Problem debuggt hatte.

Ich steckte mitten in einer langen Claude-Code-Session – vermutlich bereits bei 180k Tokens – und entwickelte einen Zahlungsablauf für die SaaS eines Kunden. Ich startete einen normalen Subagenten, damit er einen bestimmten Controller überprüft und mir sagt, ob meine Validierungslogik tatsächlich das durchsetzt, was ich beabsichtigt hatte. Der Subagent meldete sich selbstbewusst zurück: „Sieht korrekt aus. Der Guard in Zeile 47 verhindert die von dir beschriebene Race Condition.“

Nur: Tat er nicht. Der Guard, um den ich mir Sorgen machte, war im Controller überhaupt nicht vorhanden. Er befand sich in einer Middleware, die der Subagent nie gesehen hatte, weil deren komprimierte Kontextzusammenfassung diese Middleware zu einer Zeile verdichtet hatte: sinngemäß „Projekt verwendet Standard-Laravel-Middleware-Stack.“ Die Feinheit – genau die spezielle Custom-Middleware, auf die es ankam – war beim Komprimieren untergegangen.

An diesem Punkt fing ich an, meine Aufmerksamkeit auf geforkte Subagenten in Claude Code zu richten. Und nach zwei Wochen, in denen ich meine Delegationsstrategie für lange Sessions komplett umgestellt habe, gibt es für mich kein Zurück mehr.

Dieser Beitrag ist das, was ich mir am ersten Tag gewünscht hätte, an dem ich /fork aktiviert habe. Kein Marketingtext. Sondern eine ehrliche Schilderung, was wirklich passiert ist, als ich es an realen Kundenprojekten getestet habe – dort, wo der Komprimierungsverlust weh tut und wo auch geforkte Subagenten nicht immer fehlerfrei arbeiten.

Die Kompressionssteuer, über die niemand spricht

Hier ist das Problem mit normalen Subagenten in Claude Code: Sie erben nicht dein Gespräch. Sie erben eine Zusammenfassung deines Gesprächs — Anthropics eingebaute Kontextkompression, die über alles läuft, was du bisher gesagt hast, und es so weit zusammenstaucht, dass es in das Kontextfenster des Subagenten passt, zusammen mit seiner eigentlichen Aufgabe.

Diese Kompression ist verlustbehaftet. Immer. Sie muss es sein.

Mein mentales Modell war schlicht falsch. Ich dachte, ein Subagent wäre wie ein Kollege auf Slack: „Hey, kurze Sache, hier ist, woran wir gearbeitet haben, schau dir das bitte mal an.“ Tatsächlich aber habe ich meinem Kollegen eher eine einseitige Management-Zusammenfassung eines dreistündigen Meetings übergeben – mit der Bitte, zu einer Entscheidung Stellung zu nehmen, die von einem spezifischen Kommentar in Minute 47 abhing.

Die Zusammenfassung bildet den Rahmen ab. Sie verliert die Details. Doch gerade bei Codearbeit sind die Details das ganze Spiel.

Das sieht man auch in den GitHub-Issues, die das Team von Anthropic pflegt. Es gibt eine laufende Anfrage — Issue #6825 — für konfigurierbare Vererbung von System-Prompt und Memory für Subagenten. Genau deshalb, weil das Standardverhalten der Vererbung je nach Anwendungsfall entweder zu viel oder zu wenig ist. Eine verwandte Diskussion findet sich in Issue #4908 zum Thema „scoped context passing“, im Grunde genommen dasselbe Problem von einer anderen Seite betrachtet: Entwickler wollen kontrollieren, was der Subagent tatsächlich zu sehen bekommt.

Hier liegt der Konflikt: Ein volles Kontextfenster verschlechtert auf Dauer die Entscheidungsqualität von Claude Code — die Genauigkeit sinkt nach meinen eigenen Tests ab etwa 200k Tokens spürbar ab, und Anthropics eigene Kontextmanagement-Dokumentation für das 1M-Fenster weist auf diesen Breakpoint hin. Die Hauptsession will also möglichst schlank bleiben. Ein Subagent, dem Kontext fehlt, trifft aber schlechte Entscheidungen. Kompression ist der Kompromiss – und Kompromisse kosten immer etwas.

Forked Subagents lösen diesen Zielkonflikt auf. Sie erben die gesamte Gesprächshistorie der Hauptsession, Byte für Byte, und teilen sich den Prompt-Cache mit ihr, sodass du nicht für alle Tokens den vollen Preis bezahlst. Das ist das Versprechen. Die Frage, die ich zwei Wochen lang verfolgt habe: Hält dieses Versprechen tatsächlich?

Was /fork tatsächlich macht (und warum es anders ist)

Der Befehl /fork startet einen Subagenten, der mit deinem vollständigen Gesprächsverlauf im Kontextfenster beginnt. Keine Zusammenfassung. Kein komprimiertes Outline. Die tatsächlichen Nachrichten, die tatsächlichen Tool-Aufrufe, die tatsächlichen Datei-Lesevorgänge – alles, was du bis zum Zeitpunkt des Forks angesammelt hast.

Entscheidend ist, dass der Fork sich den Prompt-Cache mit der Hauptsitzung teilt. Das ist wichtiger, als es klingt. Ohne geteiltes Caching wäre ein geforkter Subagent unerschwinglich teuer – du würdest für die gleichen geerbten Tokens doppelt bezahlen: einmal in der Hauptsitzung und einmal im Fork. Anthropic schreibt in seinem Beitrag zur Kontext-Engineering mit LMCache, dass die Prompt-Wiederverwendungsrate über die Claude-Code-Phasen hinweg bei 92 % liegt – und bei ReAct-artigen Subagenten-Loops ist sie sogar noch höher. Forking profitiert erheblich von dieser Wiederverwendung.

Das sieht in der Kostenstruktur praktisch so aus: Wenn deine Hauptsitzung bei 180.000 Tokens steht und du einen Fork erstellst, beginnt dieser auch bei 180.000 Tokens. Da diese Tokens jedoch bereits im Cache liegen, entspricht der effektive Preis etwa den Cache-Read-Raten – also rund 10 % des normalen Input-Preises auf Sonnet-Tiers. Ein Fork, der nominal so viel kosten würde wie ein 180k-Token-Prompt, kostet auf der ersten Runde tatsächlich eher so viel wie ein 18k-Token-Prompt und verhält sich danach wie eine normale Unterhaltung.

Das ist der Faktor, der die Kalkulation beim Delegieren verändert.

Ein subtiler, aber wichtiger Aspekt steckt in der konkreten Umsetzung. Eine aktuelle Optimierung der /fork-Interna schreibt pro Fork nur noch einen Verweis (Pointer) statt des gesamten Elterngesprächs auf die Festplatte und lädt es bei Bedarf (Hydration on Read) wieder ein. Das ist Infrastruktur, nicht sichtbar für Nutzer:innen, sorgt aber dafür, dass du mehrere Forks starten kannst, ohne dass deine Festplatte vollläuft. Das Feature ist jetzt produktionsreif, nicht mehr experimentell.

Um Forked Subagents in externen Builds zu aktivieren, setzt du die Umgebungsvariable CLAUDE_CODE_FORK_SUBAGENT=1 oder aktivierst das entsprechende Flag in deiner settings.json. Nach der Aktivierung steht /fork als Slash-Befehl in jeder Sitzung bereit, und du kannst den gestarteten Fork direkt für Folgeprompts adressieren, ohne zum Hauptthread zurückgehen zu müssen.

Der erste Fork, dem ich wirklich vertraut habe

Um ehrlich zu sein – ich habe /fork nicht von Anfang an vertraut. Ich wurde schon oft genug von Features enttäuscht, die auf einer Landing Page überzeugend wirken, aber beim Einsatz an echter Kundensoftware auseinanderfallen. Mein Standardmodus ist daher Skepsis.

Was hat mich umgestimmt?

Ich arbeitete an einem Design-System-Projekt – ein Dashboard mit Kanban-Board, Kalenderansicht und Einstellungsbereich, die alle eine konsistente visuelle Sprache teilen sollten. Ich war inzwischen rund 140.000 Tokens tief in einer Session, in der ich bereits ein Dutzend Komponenten-Entscheidungen getroffen, ein Farbsystem definiert, eine Typografie-Skala gewählt und drei Komponenten geschrieben hatte. Ich musste zwei Design-Varianten der Kanban-Karte generieren – eine kompaktere und eine großzügigere –, um zu sehen, welche besser zum restlichen System passte.

Mit einem normalen Subagenten wäre das ein Desaster geworden. Der Subagent hätte eine komprimierte Zusammenfassung erhalten wie: „Projekt nutzt Tailwind, Designsystem ist dark mit violetten Akzenten, Typografie ist Inter.“ Das reicht nicht, um Varianten zu generieren, die sich wirklich wie Teile desselben Systems anfühlen. Die Feinheiten – der exakte Abstandsraster, den ich nutzte, die spezifischen Schattenbehandlungen, wie ich mit Icon-Größen umging – wären zur Hälfte verloren gewesen.

Stattdessen habe ich geforkt. Sogar zwei Forks, parallel. Einer mit dem Prompt: „Erstelle eine kompaktere Kanban-Karten-Variante – behalte alles am existierenden System bei, reduziere aber den vertikalen Abstand um ca. 25 % und ziehe die Typografie-Skala eine Stufe enger.“ Der zweite: „Erstelle eine großzügigere Kanban-Karten-Variante – behalte das System bei, erweitere das Padding und gib der Karte mehr Raum zum Atmen.“

Beide Forks lieferten Varianten, die tatsächlich wie Teile desselben Designsystems wirkten, weil sie das gleiche Designsystem geladen hatten. Nicht nur eine Zusammenfassung davon. Das vollständige System. Die Farbtokens, die ich festgelegt hatte, die Komponentenpattern, die ich etabliert hatte, die Abstandslogik, an der ich zwei Stunden gefeilt hatte – alles war da.

Ab diesem Moment habe ich nicht mehr mit dem Feature diskutiert, sondern es einfach genutzt.

Wo Forking seinen Wert beweist

Zwei Wochen intensiver Nutzung haben mir eine grobe Taxonomie verschafft, wann geforkte Subagenten tatsächlich einen Unterschied machen und wann normale Subagenten weiterhin das richtige Werkzeug sind. Im Folgenden stelle ich die Muster vor, die sich bewährt haben.

Parallelisierung von Design-Arbeit

Das ist der Anwendungsfall, der mich überzeugt hat. Wenn du visuelle oder strukturelle Entscheidungen triffst, die von einem System abhängen, das du bereits in der Session aufgebaut hast, zerstört das Verlieren dieses Systems durch Kompression die Output-Qualität. Forking bewahrt dieses System.

Inzwischen starte ich routinemäßig zwei oder drei Forks parallel, wenn ich Varianten evaluieren muss – Komponenten-Designs, API-Strukturen, Datenbank-Schemata, Text-Alternativen. Jeder Fork erhält den vollen Kontext sowie ein spezifisches Variations-Prompt. Ich vergleiche die Ergebnisse nebeneinander. Dieser Vergleich ist nur sinnvoll, weil alle drei Forks auf derselben Basis arbeiten.

Konsolidierung und Zusammenfassung von Arbeitsspeicher

Wer die /bytheway-Funktion von Claude Code oder die Memory-Konsolidierungsfunktionen nutzt, verwendet ohnehin bereits geforkte Subagenten – sie laufen im Hintergrund. Diese Aufgaben benötigen den vollständigen Gesprächskontext, um nützlich zu sein. Eine Zusammenfassung, die aus einer komprimierten Summary generiert wird, ist lediglich eine Zusammenfassung einer Zusammenfassung – inhaltlich das Pendant zu einer Kopie einer Kopie.

Jetzt, da ich weiß, was unter der Haube passiert, nutze ich diese Funktionen gezielter. Wenn ich an die Kontextgrenze einer Session stoße, die ich bewahren möchte, schicke ich ein /bytheway los, um die wichtigsten Entscheidungen ins Memory zu konsolidieren, bevor ich komprimiere oder neustarte.

Multi-Tool-Parallelverifikation

Hier ein Muster, das ich mir angewöhnt habe und wirklich nützlich finde: Wenn ich gerade einen nicht-trivialen Code-Abschnitt generiert habe, starte ich direkt zwei Forks:

1. Fork A: „Erstelle ein Mermaid-Diagramm, das zeigt, wie sich die gerade vorgenommenen Code-Änderungen durch den Request-Lifecycle bewegen. Markiere alles, was sich geändert hat, in einer anderen Farbe.“

2. Fork B: „Führe eine Webrecherche durch, um zu überprüfen, ob die in den Code-Änderungen verwendeten API-Patterns im Jahr 2026 beim [Framework] noch Best Practice sind. Zitiere alles, was veraltet wirkt.“

Beide Forks haben den vollständigen Session-Kontext und wissen daher exakt, von welchem Code die Rede ist. Der Diagramm-Fork gibt mir einen visuellen Sanity Check. Der Verifikations-Fork erkennt, wenn meine Muskelgedächtnis-Handgriffe noch Patterns schreiben, die vor drei Jahren idiomatisch waren, aber inzwischen abgelöst wurden. Ich erhalte zwei unabhängige Perspektiven auf dieselbe Änderung, parallel erzeugt, ohne die Haupt-Session mit einer dieser Aufgaben zu überladen.

Abschottung von Tangenten

Dieser Punkt ist subtiler, aber wichtig für den Arbeitsfluss. Manchmal habe ich eine Seitenfrage, die interessant, aber eigentlich off-topic ist. „Moment – wäre dieser Ablauf einfacher, wenn wir hier ein anderes ORM-Pattern verwendet hätten?“ Normalerweise entgleist so eine Tangente entweder meinen Hauptthread für zwanzig Minuten oder wird gar nicht verfolgt, weil ich den Fokus nicht verlieren will.

Geforkte Subagenten liefern hier eine elegante Lösung. Fork erstellen, die Seitenfrage stellen, das Was-wäre-wenn erkunden. Ist die Antwort wertvoll, bringe ich die Erkenntnis zurück ins Hauptgespräch. Ist es eine Sackgasse, /rewind und der Fork ist weg. Die Hauptkonversation merkt nichts davon.

Das ist tatsächlich eine Verhaltensänderung in meiner Claude-Code-Nutzung, nicht nur ein Feature. Ich erforsche jetzt deutlich mehr Nebenfragen, weil die Erkundungskosten von „mögliche Entgleisung“ zu „kostenlose Tangente, bei Bedarf einfach verwerfen“ geschrumpft sind.

Wann Forking der falsche Weg ist

Forking ist nicht immer die richtige Entscheidung. Es gibt eine echte Falle in der Annahme, dass mehr Kontext immer besser ist – und genau in diese bin ich in der zweiten Woche mit dem Feature getappt.

Die Falle heißt Bias. Ein geforkter Subagent hat alles gesehen, was du in der Sitzung gemacht hast – inklusive des Codes, den du gerade geschrieben hast, der Architekturentscheidungen, die du getroffen hast, und der Bibliotheken, die du ausgewählt hast. Wenn du einen Fork bittest, diesen Code zu reviewen, bekommst du keinen frischen Blick von außen. Du bekommst deine eigenen Augen, nur als separaten Prozess. Der Fork weiß noch warum du jede Entscheidung getroffen hast, und Bestätigungsfehler schleichen sich ein.

Gerade bei Code Reviews ist das entscheidend. Ein gutes Code Review entdeckt genau das, woran du selbst nicht gedacht hast. Das funktioniert aber nur, wenn der Review von jemandem kommt, der eben nicht genauso gedacht hat wie du.

Ich habe das direkt getestet. Ich schrieb eine Reihe an Authentifizierungscode und ließ ihn von einem geforkten Subagenten prüfen. Der Fork meldete sich mit kosmetischen Hinweisen – Variablennamen, eine Docstring-Anpassung, ein kleines Refactoring. Dann ließ ich einen normalen Subagent (frischer Kontext, keine Historie) denselben Code begutachten. Der normale Subagent stellte fest, dass ich Tokens nicht constant-time genug verglich – ein echtes Sicherheitsproblem, das der Fork übersehen hatte, da der Code im Umfang des Fork-Kontexts „vernünftig im Rahmen der bisherigen Muster“ aussah.

Das ist die Faustregel, die ich daraus mitgenommen habe:

• Forken, wenn Kontext ein Vorteil ist. Design-Konsistenz, Gedächtniskonsolidierung, mehrstufige Workflows mit nötigter Verlaufshistorie, Exploration von Nebensträngen.
• Nicht forken, wenn Kontext ein Nachteil ist. Code Reviews, Security Audits, adversarielle Tests, überall dort, wo ein frischer Blick und neue Annahmen gebraucht werden.

Normale Subagenten haben weiterhin ihre Daseinsberechtigung. Sie übernehmen einfach einen anderen Job.

Der Forked-vs-Normal-Vergleich

Hier ist der Vergleich, den ich mir am ersten Tag gewünscht hätte – komprimiert auf das Wesentliche, sodass du ihn tatsächlich im Moment der Entscheidung nutzen kannst.

Die wichtigste Zeile ist die zu „Am besten geeignet für“. Greif nicht zu /fork, nur weil es die neuere Funktion ist. Nutze sie, weil deine Aufgabe tatsächlich von Kontext-Kontinuität profitiert. Andernfalls zahlst du eine Bias-Abgabe ohne Nutzen.

Aktivierung und praktische Nutzung

Falls du Forked Subagents noch nicht aktiviert hast, hier der kürzeste Weg:

Öffne dein Claude Code settings.json — üblicherweise findest du es unter ~/.claude/settings.json für den Benutzerscope oder .claude/settings.json im Projektverzeichnis. Setze entweder die Umgebungsvariable CLAUDE_CODE_FORK_SUBAGENT=1 in deinem Shell-Profil, oder füge das entsprechende Flag in dein Settings-JSON ein. Beachte, dass sich der exakte Schlüsselname zwischen den Versionen geändert hat; prüfe ggf. die aktuellen Release Notes von Claude Code, falls die Umgebungsvariable allein keine Wirkung zeigt.

Sobald aktiviert, steht dir /fork als Slash-Command in jeder Session zur Verfügung. Einfach eintippen, Prompt anhängen und schon hast du einen Fork. Du kannst Forks für Folge-Turns direkt ansprechen, indem du Nachrichten entsprechend präfigierst, und mit /rewind lässt sich ein Fork, der nicht zielführend war, wieder verwerfen.

Ein paar Praxistipps aus zwei Wochen Erfahrung:

Gabelungen bewusst, nicht reflexartig nutzen. In der ersten Woche habe ich für alles geforkt — das war zu viel. Forking bringt implizite Bias-Kosten bei Review-ähnlichen Aufgaben und erhöht die mentale Last, da mehrere Threads parallel verfolgt werden müssen. Im Alltag forke ich mittlerweile nur noch drei- bis viermal pro ernsthafter Session — immer dann, wenn die Aufgabe wirklich vom vollen Kontext profitiert.

Parallele Forks gezielt für Konvergenz einsetzen. Wenn du bei einer Entscheidung unsicher bist, starte zwei Forks mit gegensätzlichen Annahmen zum Vergleich. Ich habe das kürzlich gemacht, als es um die Wahl zwischen Server Components oder Client Components für eine bestimmte Next.js-Seite ging. Zwei Forks, zwei Argumentationen, paralleler Output. Nach fünf Minuten war anhand beider Ergebnisse klar, wo die Reise hingehen muss.

Achte auf den /rewind-Reflex. /rewind ist der Notausgang, der Exploration günstig macht. Wenn du ihn selten nutzt, forktst du wahrscheinlich nicht oft genug für echte Erkundung. Forks, die sich als Sackgasse entpuppen, sollten einfach per Rewind entfernt und nicht weiter beachtet werden.

Kombiniere Forks mit normalen Subagents für adversarielle Checks. Nachdem ein Fork eine Lösung generiert hat, schick dasselbe Problem parallel einem normalen Subagent ohne Kontext. Stimmen beide überein, steigt das Vertrauen. Wenn nicht, ist die Diskrepanz wertvoll — prüfe, warum die unvoreingenommene Sichtweise Aspekte sieht, die dem kontextgeladenen Fork entgangen sind.

Was ich in der ersten Woche falsch gemacht habe

Ich will ehrlich zu den Fehlgriffen sein, denn das Feature ist so leistungsfähig, dass man leicht Gefahr läuft, es zu überverkaufen.

Der erste Fehler: Ich habe zu viel geforkt. Ich habe für Code-Reviews geforkt, was dumm war. Der Fork hat sich an jeden Codeschnipsel erinnert, den ich gerade geschrieben hatte, und hat meine Arbeit im Grunde nur abgenickt. Boris Chernys Vortrag über den Claude-Code-Workflow bringt auf den Punkt, dass frischer Kontext manchmal der eigentliche Grund für einen Subagenten ist – und genau diesen Ratschlag habe ich am Anfang ignoriert.

Der zweite Fehler: Mir war nicht bewusst, wie sehr das Cache-Warmup zählt. Der erste Fork einer Session zahlt einen echten Preis, um den geerbten Kontext zwischenzuspeichern. Nachfolgende Forks sind dann günstig. Wenn man für eine kleine Aufgabe nur einen Fork macht, amortisiert man den Cache nicht so, wie das Feature eigentlich gedacht ist. Batcht eure Forks, wenn ihr könnt – wenn ihr wisst, dass ihr drei parallele Explorationen braucht, dann startet sie möglichst eng beieinander.

Der dritte Fehler: Ich bin bei der Sitzungsdauer nachlässig geworden. Geforkte Subagenten lösen das grundlegende Problem nicht, dass eine 400.000-Token-Hauptsession eine Session mit schwammiger Logik ist. Sie verschieben nur einen Teil der Arbeit aus der Hauptsession in Forks. Wenn deine Hauptsession aufgebläht ist, sind Forks daraus genauso aufgebläht. Irgendwann muss man dennoch komprimieren, einen Checkpoint setzen oder frisch beginnen. Mein früherer Beitrag über 1M-Kontext-Management in Claude Code beleuchtet die Seite des Prunings ausführlicher.

Das Feature entschuldigt keine schlechte Sitzungs-Hygiene. Es belohnt gute Sitzungs-Hygiene, indem Delegation in gut gemanagten Sessions wirklich nützlich wird.

Das Muster, das hängen blieb

Von all den Workflows, die ich ausprobiert habe, ist einer geblieben und inzwischen zur zweiten Natur geworden.

Wenn ich tief in einem Build stecke und kurz davor bin, eine scheinbar tragende Entscheidung zu treffen – „Soll ich diese Bibliothek nutzen oder selbst etwas schreiben?“, „Soll diese API auf REST basieren oder etwas anderes verwenden?“, „Ist diese Komponentenarchitektur allgemein genug oder manövriere ich mich in eine Sackgasse?“ – mache ich einen doppelten Fork. Zwei parallele Forks, in denen jeder jeweils eine Seite der Entscheidung einnimmt und gebeten wird, die eigene Position mit dem kompletten Sitzungs-Kontext zu verteidigen.

Fünf bis zehn Minuten später habe ich zwei kurze Memos. Ich lese beide. Die richtige Antwort ist dann meist offensichtlich, und noch wichtiger: Das Warum ist ebenso offensichtlich. Ich erhalte nicht nur eine Empfehlung – ich bekomme eine fundierte Argumentation für jede Option, bewertet im spezifischen Kontext dessen, was ich bereits gebaut habe.

Damit habe ich mir eine Gewohnheit abgewöhnt, bei technischen Entscheidungen einen befreundeten Entwickler zu fragen. Der Freund war manchmal nicht erreichbar, kannte den Projektkontext nicht und hatte seine eigenen Vorurteile. Die beiden Forks sind immer verfügbar, kennen den Projektkontext exakt, weil sie der Projektkontext sind, und ihre Voreingenommenheiten sind transparent, da ich die Prompts formuliert habe.

Das ist keine Kleinigkeit. Das ist eine echte Veränderung darin, wie ich technische Entscheidungen bei Solo-Projekten treffe.

Der Test, den ich heute Abend machen würde

Wenn Sie bis hierher gelesen haben und /fork noch nicht aktiviert ist, würde ich Folgendes vor dem Schlafengehen tun:

Öffnen Sie Ihre Claude-Code-Einstellungen, setzen Sie CLAUDE_CODE_FORK_SUBAGENT=1 und starten Sie die Sitzung neu. Wählen Sie ein Projekt aus, an dem Sie heute schon einige Stunden gearbeitet haben – idealerweise eines mit mehr als 80k Tokens Kontext. Überlegen Sie sich eine Frage, die Ihnen zu diesem Projekt schon länger im Kopf herumschwirrt, die Sie aber bisher nicht gestellt haben, weil sie zu sehr vom Thema abzuweichen schien.

Geben Sie /fork ein, stellen Sie die Frage und sehen Sie sich die Antwort an.

Vergleichen Sie dann das Ergebnis mit dem, was Sie von einem normalen Subagenten erhalten hätten – Sie können tatsächlich denselben Prompt anschließend nochmal mit einem normalen Subagenten ausführen und die Resultate direkt vergleichen. Achten Sie darauf, was der Fork eingefangen hat, was dem normalen Subagenten entgangen ist. Und sehen Sie, an welchen Stellen die frische Perspektive des normalen Subagenten tatsächlich hilfreicher war als das vollständige Erinnerungsvermögen des Forks.

Bei der zweiten oder dritten Nutzung eines Forks werden Sie ein Gefühl dafür entwickeln, wann dieses Feature seinen Zweck erfüllt und wann nicht. Genau dieses Bauchgefühl ist es, das Sie dabei eigentlich trainieren. Der Befehl an sich ist simpel. Die Fähigkeit, zu wissen, wann man ihn nutzt, ist die eigentliche Kunst.

Lass uns zusammenarbeiten

Möchten Sie KI-Systeme entwickeln, Workflows automatisieren oder Ihre Tech-Infrastruktur skalieren? Ich unterstütze Sie gerne dabei.

• Fiverr (individuelle Lösungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io