Ich hörte auf, mein Context Window zu verwalten. Ich fing an, damit zu designen.

Die Erleuchtung kam nicht beim Lesen eines Changelogs. Sie traf mich mitten in der Session, drei Agents tief in einem Refactoring, Main Thread bei gerade mal 30%. Kein /compact. Kein Neustart. Einfach... sauber.

Sechs Wochen zuvor war ich wie alle anderen. Context Decay bei 60%, schwammige Antworten, Claude vergisst die Datei, die es gerade gelesen hat. Diese Situation, wo man am liebsten etwas kaputt schlagen möchte (aber man kann keine KI verprügeln, also starrt man nur auf den Bildschirm und atmet).

Dann lieferte /insights die Diagnose, um die ich nie gebeten hatte: 219 Overlap-Events in 28 Tagen. Ich betrieb Multi-Clauding, ohne es zu wissen.

März 2026 war ein Festival der Tools. Ausgereifte Subagents, Agent Teams, context: fork. Dieser Artikel ist keine Feature-Tour. Es geht darum, wie sich mein mentales Modell verändert hat und welches Entscheidungsframework ich jetzt nutze, um zu bestimmen, ob ich einen Agent starte, zwei oder fünf.

Drei Agents, Ein Refactoring, Null Komprimierung

Das Refactoring war ein WooCommerce Product Sync, der sechs Monate lang technische Schulden angehäuft hatte. Diese Art von Codebase, wo jede Datei einen Kommentar hat mit "temporärer Fix" vom Januar.

Drei Agents, jeder in seinem eigenen Kontext. Einer am API Layer (zwölf Endpoints, Validation, Error Paths). Einer schreibt die Transform Logic neu, die zu Spaghetti-Code geworden war wegen sechs Monaten "füg einfach eine Bedingung hinzu". Einer auditiert die Test Suite, um herauszufinden, welche Tests tatsächlich etwas testen versus welche einfach nur... da sind. Vibes-Tests.

Main Thread bei 30%, koordiniert, macht nicht die schwere Arbeit. Kein Moment, wo Claude Fragen zu Dateien beantwortet, die es vor vierzig Minuten gelesen hat, mit der Zuversicht von jemandem, der diese Datei definitiv nicht gelesen hat. (Du kennst diesen Gesichtsausdruck. Das selbstbewusst-falsche Gesicht.)

Dasselbe Refactoring, zwei Monate früher: Single Session, Context füllt sich beim zweiten Endpoint, Antworten werden schwammig ab Datei sieben, ich starte neu, erkläre die ganze Mise en Place erneut, verliere zwanzig Minuten, starte wieder neu. Beim dritten Neustart refaktoriere ich nicht mehr. Ich babysitte Claudes Gedächtnis.

Diesmal: zwei Stunden. Saubere Summaries von jedem Agent. Merge, Test, Push.

Ich verwaltete kein Window mehr. Ich designte ein System von Kontexten.

Die Diagnose, um die ich nicht gebeten hatte

Ich führte /insights auf meine Claude Code Usage aus. 374 Sessions. 219 Multi-Claude Overlap Events in 28 Tagen. Nicht weil ich clever war. Weil ich immer neue Sessions öffnete, wenn die alte verfiel, ohne sie zu schließen. Versehentliches Multi-Clauding, der Grund für schlechte Gewohnheiten.

Die Overlap-Zahl war ein Symptom. Die Krankheit lag darunter: Ich behandelte Context wie eine knappe Ressource. Jedes /compact war ein kleines Eingeständnis, dass die Session sich verschlechterte. Jeder Neustart war ein größeres. Und jedes Mal, wenn ich ein zweites Terminal öffnete "nur um schnell etwas zu checken", versuchte mein Workflow Context zu verteilen, bevor ich die Tools hatte, es absichtlich zu tun.

Context Decay war das Symptom. Context wie eine Beschränkung zu behandeln war die Krankheit.

Versehentliches Multi-Clauding ist kein Zeichen von Inkompetenz. Es ist ein Signal, dass der Workflow das Single-Session-Modell überwachsen hat. Wenn deine /insights Overlaps zeigen, bist du wahrscheinlich auch soweit.

Context hörte auf, eine Beschränkung zu sein. Es wurde zu einem Baumaterial.

Zuerst das Ergebnis.

Im März 2026 wurden vier Dinge gleichzeitig ausgeliefert: das 1M Token Context Window, ausgereifte Subagent-Typen (Explore, Plan, General purpose), context: fork als First-Class-Feature in Custom Skills und Agent Teams als experimenteller Multi-Agent-Modus. Jedes für sich nützlich. Zusammen veränderten sie, was ein Context Window ist.

Nicht eine Box, die sich füllt. Ein Material, das man verteilt.

Denk an den Shift von Monolith zu Microservices. Nicht die Hype-Version mit zwölf Services und einem Message Bus für eine Todo-App. Die echte Version: Du hörtest auf, RAM in einem großen Prozess zu sparen und fingst an, Isolation Boundaries zu designen. Jeder Service bekommt seinen eigenen Speicher. Der Orchestrator bleibt leicht. Kommunikation passiert über definierte Interfaces, nicht über Shared State. Derselbe Shift, angewandt auf Context. Jeder Subagent bekommt ein frisches 200K Window. Der Main Thread bleibt leicht. Ergebnisse kommen als Summaries zurück, nicht als Raw Bleed.

Die Practitioner Community konvergiert auf ähnliche Zahlen. "Split by context, not by role" taucht immer wieder als Pattern auf. Main Context sitzt bei etwa 30-40% für Leute, die den Switch gemacht haben. Lydia Hallie vom Claude Code Team präsentiert context: fork als Design-Feature, nicht als Workaround. Simon Willison formalisierte Subagent-Patterns in seinen Agentic Engineering Writeups.

Warum jetzt? Diese Patterns sind nicht neu (Docker hat Container nicht erfunden). Aber die März-Konvergenz machte sie für jeden Solo-Dev mit Max Plan zugänglich. Vor März bedeutete Context verteilen, gegen die Tools zu kämpfen. Danach erwarten die Tools es.

Faire Warnung: Die Microservices-Analogie bricht schnell zusammen, wenn man sie zu weit treibt. Keine Service Discovery zwischen Agents. Kein "Context Mesh". Agent Teams sind experimentell, keine ausgereifte Distributed Runtime. Das mentale Modell hilft. Die Analogie ist ein Startpunkt, kein Ziel.

Dasselbe Modell, dieselben Token. Völlig andere Beziehung.

Die Theorie ist sauber. In der Praxis läuft die Frage jeder Session auf etwas brutal Einfaches hinaus: starte ich einen Agent, zwei oder fünf?

Das Entscheidungsframework, das ich tatsächlich nutze

Task kommt an
├── Kohärenter Scope, verwandte Dateien, Context < 40%
│   └── Single Agent. Scope-Lock Prefix. Fertig.
├── Heavy Exploration (> 3 unverwandte Dateien zu lesen), Ergebnis = Summary
│   └── Subagent / context: fork. Es exploriert, du bleibst sauber.
└── Unabhängige Subtasks + Koordination bringt Vorteile
    └── Agent Team. Aber: wenn Agents ständig
        Output voneinander lesen müssen → zurück zu Single Agent.

Drei Regime. Die Grenzen sind wichtiger als die Kategorien.

Single Agent ist immer noch die richtige Wahl für die meisten Tasks. Eine Feature-Addition, die drei verwandte Dateien berührt. Ein Bug Fix, wo der Scope offensichtlich ist. Wenn der Context bequem passt und die Dateien verwandt sind, fügt ein Subagent Overhead für null Nutzen hinzu. Ein Scope-Lock Prefix in deinem Prompt erledigt den Job: "Du arbeitest an X. Berühre nur Dateien Y und Z. Exploriere nicht über diesen Scope hinaus."

Subagents sind für Situationen, wo Exploration deinen Main Context vergiften würde. Der Trigger, bei dem ich gelandet bin: wenn ich mehr als drei unverwandte Dateien lesen muss, um eine Frage zu beantworten, das ist ein Spawn. Letzte Woche explorierte ein Subagent den Auth Flow einer Partner API, las vierzehn Dateien über drei Repos, lieferte eine sechszeilige Summary. Mein Main Context bewegte sich nicht. Dieselbe Exploration in einer Single Session hätte 35-40% des Windows mit Dateiinhalten gefressen, die ich nie wieder angeschaut hätte.

Agent Teams sind für Situationen, wo Subtasks unabhängig sind, aber das Gesamtergebnis von paralleler Ausführung profitiert. Das Refactoring aus Abschnitt eins. Eine Debugging-Session mit drei gleichzeitig erforschten Hypothesen. Der kritische Test: wenn Agents ständig den Output voneinander lesen müssen, um fortzufahren, hast du keine unabhängigen Subtasks. Du hast einen einzelnen Task im Trenchcoat, der vorgibt, drei zu sein. Zurück zu Single Agent.

Die Prompt-Struktur, die ich nutze, um ein Agent Team zu starten:

"Drei parallele Agents. Jeder Agent bekommt EINEN Scope:
- Agent 1: [scope]. Liefere: [spezifischer Output].
- Agent 2: [scope]. Liefere: [spezifischer Output].
- Agent 3: [scope]. Liefere: [spezifischer Output].
Kein Agent liest die Dateien eines anderen Agents. Final Merge ist meiner."

Jeder Agent erhält einen Scope, Constraints und ein erwartetes Deliverable. Wenn du das Pattern erkennst, liegt es daran, dass Context Boundaries wie Prompt Contracts angewandt auf Multi-Context-Architektur funktionieren. Dieselbe Disziplin. Scope, Constraints, Deliverable. Nur dass du jetzt den Contract für einen isolierten Context schreibst, nicht für eine Single Session.

Dieses Framework ist auf Solo/Indie Usage kalibriert. In einem Team von vier Devs verschieben sich die Dynamiken (Git Conflicts, Permissions, menschliche Koordination gestapelt auf Agent-Koordination). Habe Agent Teams in einem Team noch nicht stressgetestet. Solo hält es.

Die Regel: wenn du den Contract des Subagents nicht in zwei Sätzen schreiben kannst, muss er nicht existieren.

Die Token-Rechnung, über die niemand sprechen will

Context verteilen kostet mehr Token. Das ist der ehrliche Teil, und so zu tun, als wäre es anders, wäre unehrlich.

Agent Teams verbrauchen 4-7x die Token einer Single Session für dieselbe Arbeit. Subagents parallel auf einem Pro Plan treffen das Rate Limit in etwa zwanzig Minuten. Der Max Plan für $100-200/Monat ist der realistische Boden für diesen Workflow.

Jetzt der Teil, den niemand berechnet.

Prompt Caching verändert die Mathematik. Bei Heavy Sessions sind 90%+ der Token Cache Reads für $0.50 pro Million Token für Opus. Der Multiplikator ist real, aber es ist ein Multiplikator auf einer Basis, die dramatisch günstiger ist als der Sticker Price. Meine monatliche Rechnung stieg vielleicht um 40% nach dem Switch zu Multi-Context. Nicht um 400%. Der Prompt Caching Layer ist das, was die ganze Multi-Context-Ökonomie tatsächlich funktionieren lässt.

Aber vergiss die Token-Rechnung für eine Sekunde. Karen aus der Buchhaltung würde mich umbringen, wenn ich das sage, aber die Token-Rechnung ist die falsche Tabelle.

Die echten Kosten von Context Decay: die zwanzig Minuten, in denen man Context nach einem Neustart neu erklärt. Der Bug, den du auslieferst, weil Claudes Antwort auf einer Datei basierte, die es halb erinnerte. Der dritte Neustart, wo du das Refactoring aufgibst und es von Hand machst. Diese Kosten stehen auf keiner Rechnung. Sie zeigen sich an deinem Freitagnachmittag, dem, den du eigentlich am Pool mit den Kindern verbringen solltest, beim Debuggen einer Session, die bei 65% verfault ist.

Multi-Context eliminiert die unsichtbaren Kosten. Die Token-Rechnung steigt. Die Gesamtkosten sinken.

Diese Zahlen gelten für Max Plan mit Opus Prompt Caching. Bei Pro verschiebt sich das Verhältnis stark. Bei direkter API ohne Caching kann Multi-Context unerschwinglich werden. Kopiere meine Zahlen nicht auf dein Tier.

Was sich ändert, wenn alle so denken

Das klarste Signal, dass dieser Shift real ist, sind nicht die Features. Es ist, dass Practitioners, die gewechselt haben, nicht zurückgehen. "Split by context, not by role" wird zu einem Reflex, nicht zu einem Ratschlag. Die Leute, die täglich Multi-Context nutzen, evangelisieren es nicht. Sie machen es einfach, so wie niemand mehr über die Nutzung von Git spricht. Man nutzt einfach Git.

Die Tools folgen. Agent Teams ist heute experimentell, aber die Richtung ist gesetzt. Context Persistence zwischen Sessions wird bereits ausgeliefert (Auto-Memory, /resume). Es gibt 100+ Community Subagent Configs auf GitHub, die auf dem Pattern aufbauen, bevor es überhaupt einen offiziellen Namen hat.

Die meisten Devs nutzen Claude Code immer noch als Monolith mit einem großen Window. Und es funktioniert. Aber manche Tasks verdienen mehr. Und zu wissen, welche, das ist der ganze Punkt. 🤷

Vor zwei Monaten kämpften wir gegen Context Decay. Restart, compact, clear, MCPs optimieren, Skills beschneiden... beteten, dass Claude sich an Zeile 42 erinnert.

Heute sind meine CLAUDE.md-Dateien ein anderes Tier. Keine "tu X nicht"-Listen mehr. Scope-Deklarationen für jeden Context. Meine Skills haben context: fork by default. Projektstruktur reflektiert Context-Verteilung, nicht umgekehrt.

Der Shift war nicht technisch. Die Tools existierten bereits in Teilen. Das mentale Modell bewegte sich: hör auf, eine einzelne Session zu schützen, fang an, isolierte Kontexte zu architektieren. Alles andere folgte.

Ein Agent reicht für die meisten Tasks. Aber zu wissen, wann es nicht reicht, und im richtigen Moment zu forken, anstatt an einer Session zu klammern, die verfault, das ist der Unterschied zwischen Claude Code nutzen und es verstehen.

Quellen

Simon Willison, "Agentic Engineering Patterns" (simonwillison.net). Lydia Hallie (Anthropic), Claude Code context: fork Dokumentation und Präsentationen. Akshay Pachaar, "split by context, not by role" (X/Twitter, März 2026).

(*) Das Cover ist KI-generiert. Die drei Agents im Bild haben bessere Koordination als die meisten Standups, an denen ich teilgenommen habe.