Die Werkzeuge

Eine Liste der Werkzeuge in diesem Text wäre nach drei Monaten falsch. Die gepflegte steht in der Marktübersicht, je Werkzeug mit Hersteller, Bauform und dem Tag, an dem zuletzt jemand beim Hersteller nachgelesen hat. Was länger hält, sind die Bauformen. Es gibt drei davon, alle drei sind in Gebrauch, und die Nummern hier ordnen sie danach, wie weit sie ins Projekt greifen. Entstanden sind sie in einer anderen Reihenfolge, die Jahreszahlen stehen jeweils dabei. Die ganze Folge mit allen Werkzeugen zeigt die Zeitleiste der Coding-Agenten.

Bauform 1: Code-Completion beim Tippen

Sie schreiben, und im Editor erscheint grau ein Vorschlag für den Rest der Zeile oder der Funktion. Tab übernimmt ihn, weitertippen verwirft ihn.

GitHub Copilot zeigte das im Juni 2021 (externe Seite, github.blog), siebzehn Monate vor ChatGPT. Benutzen konnten es damals wenige, und die Ankündigung (externe Seite, github.blog) sagt es im letzten Satz selbst: Die Plätze für die technische Vorschau sind begrenzt, wer mitmachen will, soll sich gleich anmelden.

Für alle offen stand Copilot ein Jahr später (externe Seite, github.blog), zu zehn Dollar im Monat. Das ist die älteste Bauform und heute die unauffälligste: Sie läuft in fast jedem Editor mit, oft ohne dass jemand sie eigens eingerichtet hat.

Was sie sieht, ist eng begrenzt: die offene Datei, ein paar benachbarte, den Namen dessen, was Sie gerade tippen. Was sie tut, ebenso: Sie schlägt vor. Ausgeführt wird nichts, und was Sie übernehmen, steht danach im Editor wie selbst getippt.

Bauform 2: Der Agent in der Entwicklungsumgebung

Hier verschwindet die Zeile, an der Sie stehen, als Bezugspunkt. Sie beschreiben ein Vorhaben in einem Feld daneben, und das Werkzeug arbeitet über mehrere Dateien.

Cursor hat das im November 2024 (externe Seite, cursor.com) mit dem Composer vorgeführt. Der Änderungseintrag (externe Seite, cursor.com) nennt schon damals beides, was diese Bauform ausmacht: eine frühe Fassung eines Agenten im Composer, der sich seinen Kontext selbst aussucht und das Terminal benutzt.

Der Gewinn gegenüber Bauform 1 ist der Blick über die einzelne Datei hinaus. Der Gewinn gegenüber Bauform 3 ist die Ansicht: Jede Änderung steht markiert im Editor und lässt sich einzeln behalten oder verwerfen.

Wann sie dort steht, ist die feinere Frage, und derselbe Hersteller beantwortet sie drei Wochen später in einem weiteren Eintrag (externe Seite, cursor.com): Der Agent speichert seine Änderungen von selbst auf die Festplatte.

Die Datei ist also geschrieben, wenn die Markierung erscheint. Wer verwirft, nimmt zurück. Im selben Eintrag steht der Satz, der die zweite Grenze verschiebt: Im Yolo-Modus kann der Agent Befehle im Terminal von selbst ausführen.

Damit kann diese Bauform beides, was der nächste Abschnitt Bauform 3 zuschreibt. Aus einem Unterschied der Bauart ist eine Einstellung geworden, und das ist der Grund, warum die drei Fragen weiter unten nach Rechten fragen statt nach Fenstern.

Bauform 3: Der Agent auf der Kommandozeile

Kein Editor, kein Fenster. Sie starten ein Programm im Pro­jekt­ver­zeichnis und schreiben hinein, was geschehen soll. Es liest Dateien, ändert sie, führt Befehle aus und liest deren Ausgabe.

Diese Bauform ist älter, als die meisten annehmen. Aider gab es bereits 2023 (externe Seite, aider.chat), zwanzig Monate bevor Claude Code im Februar 2025 (externe Seite, anthropic.com) erschien und der Sache zu ihrer heutigen Bekanntheit verhalf. Wie man mit Claude Code arbeitet, erklärt die Rubrik Claude Code erklärt Kapitel für Kapitel.

Was in der Kommandozeile läuft, kann grundsätzlich alles, was Sie dort auch könnten. Tests starten, Abhängigkeiten nachziehen, ein Verzeichnis durchsuchen, sich mit einem anderen Rechner verbinden. Wie viel davon ohne Rückfrage geschieht, regelt ein Modus. Claude Code startet im Terminal inzwischen im Auto-Modus (externe Seite, code.claude.com): Ein zweites Modell prüft die meisten Handlungen, bevor sie laufen, und die üblichen Rückfragen entfallen. Cursor bietet für Bauform 2 dasselbe Muster (externe Seite, cursor.com) unter dem Namen Auto-review an. Die Reichweite ist bei beiden weit, und wie viel davon ohne Rückfrage läuft, ist bei beiden eine Einstellung.

Das ist zugleich der Grund, warum diese Bauform am meisten Vorkehrungen verlangt. Die Kapitel danach handeln überwiegend davon.

Wie man das eine vom anderen unterscheidet

Drei Fragen genügen.

seitlich verschiebbar

eigene Darstellung, Stand 07.08.2026

Wer bestimmt, was gelesen wird? Bei Bauform 1 der Ort des Cursors. Bei 2 und 3 das Werkzeug selbst.

Kann es etwas ausführen? Bei Bauform 1 nein. Bei 2 und 3 so viel, wie der eingestellte Modus zulässt, bei 3 bis an die Grenzen der Kommandozeile.

Wann sehen Sie eine Änderung? Bei 1, bevor sie gilt. Bei 2 und 3, nachdem sie geschrieben ist, und bei 3 nur, wenn Sie danach sehen.

Alle drei nebeneinander ist der Normalfall

Es gibt keine Entscheidung zu treffen, bei der eine Bauform gewinnt. In der Praxis benutzt man alle drei am selben Tag: die Code-Completion beim Schreiben von Hand, den Agenten in der Ent­wick­lungs­um­ge­bung für eine überschaubare Änderung mit Blick darauf, die Kommandozeile für alles, was lange läuft oder viele Dateien anfasst.

Wer heute anfängt, fängt trotzdem am besten mit Bauform 3 an. Der Grund: Dort wird sichtbar, was in den anderen verborgen abläuft.

Was bei der Auswahl wirklich zählt

Weniger, als man denkt, hängt am Modell dahinter, und Tiefe 2 sagt, warum. Eher diese vier Dinge:

• Wo die Daten hingehen. Läuft das Modell beim Anbieter oder bei Ihnen? Bei fremdem Code ist das keine Geschmacksfrage.
• Was es kostet und wie abgerechnet wird. Pauschale je Monat oder Abrechnung nach Verbrauch. Bei Bauform 3 kann derselbe Auftrag je nach Vorgehen ein Vielfaches kosten.
• Ob Sie eigene Regeln hinterlegen können. Gegenstand von Kapitel 03.
• Ob es sich einbauen lässt. Ein Werkzeug, das nur mit einem Menschen davor läuft, taugt nicht für alles, was regelmäßig geschehen soll.

Der sichtbare Unterschied zwischen den Bauformen ist die Oberfläche. Der wirksame ist, was das Werkzeug lesen und ausführen darf, und beides hängt weniger am Hersteller als an einer Handvoll Entscheidungen, die man selbst trifft.

Was der Agent zu Beginn sieht

Ein verbreiteter Irrtum: Ein Agent im Pro­jekt­ver­zeichnis kenne das Projekt. Zu Beginn sieht er wenig: die Projektanweisung, falls es eine gibt, und je nach Werkzeug einen kurzen Stand der Ver­si­ons­ver­wal­tung, wie Kapitel 04 zeigt. Alles Weitere muss er sich holen.

Wie er das tut, unterscheidet sich, und der Unterschied ist spürbar.

Über eine Übersicht. Aider baut eine Karte des Projekts auf, in der die wichtigsten Namen und Zusammenhänge stehen, und legt sie in den Kontext. Vorteil: Der Agent weiß von Anfang an, was es gibt. Nachteil: Die Karte kostet Platz, bei jedem Aufruf.

Über Suche bei Bedarf. Andere Werkzeuge starten ohne Übersicht und suchen sich, was sie brauchen, wenn sie es brauchen. Vorteil: Der Kontext bleibt frei. Nachteil: Der Agent findet nur, wonach er sucht, und wonach er sucht, rät er.

Praktisch heißt das: Etwas, das an einer unerwarteten Stelle steht oder anders heißt als vermutet, findet ein suchender Agent oft nicht. Er baut es dann ein zweites Mal. Das ist eine der Arten, wie doppelter Code aus Agentenarbeit entsteht. Wie oft sie gegenüber den anderen vorkommt, ist nirgends erhoben. Sie steht hier, weil der Aufbau sie erzeugt: Ein besseres Modell sucht an derselben falschen Stelle.

seitlich verschiebbar

eigene Darstellung, Stand 07.08.2026

Der Kontext ist die knappe Größe

Was ein Agent liest, steht danach in seinem Kontextfenster und geht bei jedem weiteren Schritt erneut mit. Die Mechanik dazu steht in Grundkurs, Kapitel 05 und Grundkurs, Kapitel 08, die Folgen für diese Arbeitsweise sind eigen.

Eine Sitzung, die lange läuft, füllt sich. Am Anfang stehen die Anweisungen, dann die gelesenen Dateien, dann jede Tool-Ausgabe, dann die eigenen Zwischenschritte. Bevor das Fenster überläuft, greift das Werkzeug ein und ersetzt das Bisherige durch eine Zusammenfassung. Genau dann bemerkt man es an der Arbeit: Der Agent vergisst, was zu Beginn im Gespräch vereinbart war, oder wiederholt etwas, das schon erledigt ist. Wer die Zusammenfassung schreibt, entscheidet damit über das Überleben jeder Einzelheit, und das ist der Gegenstand von Kapitel 05.

Die Gegenmittel sind unspektakulär und wirksam. Eine Sitzung je Thema statt einer langen. Große Ausgaben in eine Datei umleiten und daraus nur das Nötige lesen. Und die Sachen, die immer gelten, dorthin schreiben, wo sie bei jedem Start wieder dastehen, statt sie im Gespräch zu wiederholen.

Berechtigungen, und warum sie schnell aufweichen

Lange fragten Werkzeuge der Bauform 3 vor jedem Befehl. Am ersten Tag findet man das richtig, am dritten lästig. Dann setzt man eine Allowlist, damit die harmlosen Befehle ohne Rückfrage durchlaufen, und irgendwann steht darauf mehr, als man noch überblickt.

Die Hersteller haben darauf mit einem zweiten Modell geantwortet, das statt Ihrer prüft. Bei Claude Code ist das der Auto-Modus, inzwischen der Startzustand im Terminal. Laut der Doku zu den Rechtemodi (externe Seite, code.claude.com) arbeitet Claude darin ohne die routinemäßigen Rückfragen nach einer Erlaubnis.

Cursor nennt dasselbe Auto-review und schreibt die Grenze in seiner Doku (externe Seite, cursor.com) gleich dazu: Der Klassifikator kann sich irren. Er kann einen Aufruf zulassen, den Sie blockiert hätten, oder einen blockieren, den Sie zugelassen hätten.

Die Allowlist bleibt daneben bestehen.

Zwei Dinge, die dabei regelmäßig übersehen werden.

Eine Rückfrage, die niemand beantwortet, ist ein Ausschalter. Läuft ein Agent nachts oder in einem automatischen Ablauf, ist niemand da, der sie beantwortet. Claude Code lehnt in einem solchen Lauf jede offene Rückfrage ab und arbeitet ohne den Schritt weiter. Hängt ein eigenes Programm als Antwortgeber daran, wartet der Lauf (externe Seite, code.claude.com) auf dessen Antwort. In beiden Fällen geschieht der Schritt nicht. Wer das nicht bedenkt, baut eine Sicherung, die zuverlässig verhindert, dass überhaupt etwas passiert.

Eine Allowlist beschreibt Befehle. Was daraus folgt, steht nicht darauf. Ein erlaubtes Werkzeug kann fremde Inhalte lesen, und in fremden Inhalten kann eine Anweisung stehen. Bis hierher ist das eine Überlegung. Der Vorfall bei Hugging Face (externe Seite, huggingface.co) vom Juli belegt sie nicht: Dort war der Agent der Angreifer, und er lief in einer Auswertung, für die der Betreiber die Schutzschichten eigens abgeschaltet hatte. Was er zeigt, ist die Reichweite eines Modells ohne Bremsen. Was eine Tool-Liste leisten kann und wo die Umgebung einspringen muss, steht in Grundkurs, Kapitel 09.

Der praktische Schluss lautet: Was ein Agent anrichten kann, ergibt sich aus dem, worauf er Zugriff hat, und das ist eine Entscheidung beim Einrichten. Ein Agent in einem Wegwerf-Baum mit eigenen Zugangsdaten ist ein anderes Risiko als einer im Hauptverzeichnis mit den Schlüsseln des Benutzers.

Das Modell ist austauschbar geworden, in Grenzen

Vor zwei Jahren war die Wahl des Werkzeugs zugleich die Wahl des Modells. Heute steht bei vielen eine Liste zur Auswahl, und Aider treibt es am weitesten: Laut seiner Modellübersicht (externe Seite, aider.chat) arbeitet es auch mit lokalen Modellen, etwa über Ollama.

Auf derselben Seite steht die Einschränkung, ein paar Zeilen tiefer: Mit weniger leistungsfähigen Modellen funktioniert Aider womöglich nicht gut.

Der Grund ist derselbe, aus dem ein Werkzeug überhaupt etwas ändern kann: Es erwartet die Änderung in einer bestimmten Form und bucht ein, was es wiedererkennt. Ein Modell, das diese Form verfehlt, kann guten Code schreiben, ohne dass sich eine einzige Datei ändert. Austauschbar heißt also gegen ein Modell, das dazu in der Lage ist, und wie lang die Liste dieser Modelle ist, unterscheidet die Werkzeuge mehr als ihre Oberfläche.

Damit verschiebt sich, worauf es bei der Auswahl ankommt. Die Frage nach dem besten Modell tritt zurück, und diese vier treten vor:

• Wie geht das Werkzeug mit Fehlern um? Merkt es, dass ein Befehl fehlschlug, und was macht es dann?
• Wie viel vom Kontext verbraucht es selbst, bevor Sie ein Wort geschrieben haben? Angebundene Tools kosten Platz, auch ungenutzt, und wie viel, hängt daran, ob das Werkzeug ihre Beschreibungen vorab lädt.
• Lässt sich etwas dranbauen? Eigene Abläufe, eigene Prüfungen, eigene Auslöser.
• Läuft es ohne Menschen davor?

Die letzten beiden Punkte trennen ein Werkzeug, mit dem man arbeitet, von einem, auf dem man etwas aufbaut. Bei Bauform 1 stellen sie sich kaum. Bei 3 sind sie oft der Grund, sie zu wählen.

Wo die Bauformen sich überschneiden

Die Grenzen sind unscharf geworden. Ent­wick­lungs­um­ge­bungen haben eine eingebaute Kommandozeile, Kommandozeilen-Agenten bekommen Oberflächen, und Anbieter bieten beides an.

Das ändert an der Ordnung nichts, weil sie an drei Fragen hängt statt an Produktnamen: Wer entscheidet, was gelesen wird? Was darf ausgeführt werden? Wann sehen Sie die Änderung?

Ein Werkzeug, das alle drei Antworten dem Werkzeug überlässt, ist Bauform 3, auch wenn es ein Fenster hat.

Was nach zwei Jahren übrig geblieben ist

Von den Werkzeugen, die 2024 als führend galten, sind einige verschwunden, gekauft oder eingestellt. Das ist bei einem Gebiet in dieser Geschwindigkeit normal und der Grund, warum dieses Kapitel keine Rangliste enthält.

Was geblieben ist, sind die Bauformen. Die Code-Completion von 2021 gibt es weiter, und die Kommandozeile ist seit Aider dieselbe Idee. Der Agent in der Ent­wick­lungs­um­ge­bung hat in derselben Zeit an Rechten gewonnen, wie der Yolo-Modus in Tiefe 1 zeigt: Geblieben ist die Bauform, gewandert sind ihre Voreinstellungen. Wer eine davon verstanden hat, kommt mit einem neuen Werkzeug derselben Bauform binnen einer Stunde zurecht, und die Einstellungen sieht er sich trotzdem an.

Ab einer gewissen Nutzungsdauer entscheidet über die Tool-Wahl nichts von dem, was in Ver­gleichs­ta­bellen steht. Es entscheiden drei Dinge: was der Sockel im Kontext kostet, ob mehrere Läufe nebeneinander möglich sind, und ob sich das Werkzeug ohne Menschen davor betreiben lässt.

Der Sockel

Bevor Sie ein Wort geschrieben haben, steht im Kontext bereits eine beträchtliche Menge Text: die Systemanweisung des Werkzeugs, die Beschreibung jedes angebundenen Tools, die Pro­jekt­an­wei­sungen, oft eine Verzeichnis- oder Projektübersicht.

Das ist der Sockel, und er ist keine Kleinigkeit. Er wird bei jedem einzelnen Schritt mitgeschickt, also bei jedem Tool Call innerhalb einer Aufgabe. Wer zwanzig Tools anbindet, weil sie einmal nützlich sein könnten, zahlt deren Beschreibungen bei jedem Schritt mit, sofern das Werkzeug sie vorab lädt. Claude Code lädt in der Voreinstellung nur die Namen. Die Tool-Suche hält laut MCP-Doku (externe Seite, code.claude.com) den Kontextverbrauch durch MCP niedrig, indem sie die Tool-Definitionen erst lädt, wenn Claude sie braucht.

Der Sockel schrumpft damit, und die Auswahl läuft über eine Suche.

Zwei Folgerungen, beide unbequem:

Weniger angebundene Tools sind oft besser, und der zweite Grund neben den Kosten steht in den Empfehlungen des Protokolls, über das solche Tools meistens angebunden werden. Alle Beschreibungen vorab zu laden, kostet laut diesen Empfehlungen (externe Seite, modelcontextprotocol.io) dreifach: Es verschwendet Token, erhöht die Latenz und verschlechtert die Leistung des Modells.

Wo die Grenze liegt, sagt dieselbe Seite, und sie liegt höher, als eine Faustzahl vermuten lässt: Für eine Handvoll Tools ist das Vorabladen völlig vertretbar.

Zum Problem wird es bei Dutzenden angebundenen Servern mit Hunderten von Tools, und als Schwelle für das Nachladen bei Bedarf nennt die Seite einen Anteil am Kontextfenster von einem bis fünf Prozent. Wer fünf Tools angebunden hat und sich um die Auswahlgüte sorgt, sorgt sich damit an der falschen Stelle. Das Thema steht in Grundkurs, Kapitel 09: Angebunden heißt nicht benutzt, und was gewählt wird, entscheidet die Beschreibung.

Der Sockel ist nicht konstant. Er ändert sich mit jedem Update des Werkzeugs, ohne dass jemand etwas tut. Wer seine Kosten je Aufgabe kennt, sollte sie gelegentlich neu messen.

seitlich verschiebbar

eigene Darstellung, Stand 03.08.2026

Nebenläufigkeit

Der Punkt, der in Vergleichen fehlt und in der Praxis am meisten ausmacht: Können mehrere Läufe gleichzeitig arbeiten, ohne sich zu behindern?

Bei Bauform 1 stellt sich die Frage nicht, dort sitzt ein Mensch davor. Bei Bauform 3 ist sie zentral, denn dort will man irgendwann drei Aufgaben parallel laufen lassen. Bauform 2 ist nachgezogen: Cursor lässt seit Version 2.0 vom Oktober 2025 bis zu acht Agenten (externe Seite, cursor.com) an derselben Anweisung arbeiten, jeden in einem eigenen Worktree oder auf einem entfernten Rechner.

Das geht nur, wenn jeder Lauf seinen eigenen Worktree hat. Zwei Agenten im selben Verzeichnis erzeugen genau die Sorte Fehler, die hinterher niemand zuordnen kann: Der eine committet, was der andere gerade schreibt. Wie getrennte Bäume daraus eine Eigenschaft des Aufbaus machen, steht in Kapitel 04.

Getrennt sind dabei die Dateien im Baum. Alles andere teilen die Läufe weiter, und darüber stolpert man beim ersten Mal: dieselbe Datenbank, derselbe Port, dieselben Cache, dieselben Zugangsdaten. Auf dieser Seite hier war es eine Verknüpfung. Ein Aufräumbefehl im zweiten Baum löschte den Bau-Cache des ersten mit, weil beide auf dasselbe Verzeichnis zeigten. Ein Baum trennt, was in der Ver­si­ons­ver­wal­tung liegt.

Ein Werkzeug, das das nicht zulässt, weil es einen festen Zustand im Pro­jekt­ver­zeichnis hält, deckelt damit, wie viel man mit ihm tun kann.

Wenn ein Koordinator die Läufe startet

Im Abschnitt davor verteilen Sie selbst: Sie öffnen drei Sitzungen, geben jeder ihre Aufgabe, wiederholen in jeder denselben Hintergrund und sehen nach, welche fertig ist. Seit September 2026 übernimmt Claude Code diese Arbeit in seinen Projekten (externe Seite, claude.com), zunächst als Beta für einen Teil der Pro- und Max-Abonnenten. Ein Projekt ist ein einziges Gespräch, das über Tage weiterläuft, und dieses Gespräch ist die Hauptsitzung. Die Dokumentation (externe Seite, code.claude.com) beschreibt es als eine lang laufende Sitzung, in der Claude die Koordination übernimmt.

Der Koordinator nimmt entgegen, was Sie schicken, beantwortet kurze Fragen selbst und macht aus jeder Aufgabe einen Thread, oder er reicht sie an einen Thread weiter, der im selben Bereich schon arbeitet. Das erinnert an die Hauptunterhaltung mit ihren Subagenten aus Kapitel 13, und der Unterschied liegt in der Größe der Arbeiter. Ein Subagent läuft innerhalb einer Sitzung, ein Thread ist selbst eine. Laut Dokumentation (externe Seite, code.claude.com) ist jeder Thread eine eigene Sitzung mit eigenem Kontextfenster, die ein Stück Arbeit erledigt und sich beim Gespräch zurückmeldet, sobald sie fertig ist.

Ein Thread in der Cloud klont die Repositories in seine eigene Sandbox und arbeitet auf einem eigenen Branch. Das ist die Trennung aus dem Abschnitt davor, hier legt sie der Anbieter an. Einen Worktree braucht ein solcher Thread deshalb keinen, und berühren zwei Threads denselben Code, zeigt sich das als gewöhnlicher Merge-Konflikt zwischen zwei Pull Requests (externe Seite, claude.com).

Vom Koordinator sollten Sie zwei Dinge wissen. Er sieht von den Threads nur deren Rückmeldungen; was ein Thread im Einzelnen getan hat, steht in dessen eigenem Verlauf, und dort lässt er sich auch direkt anweisen. Und er arbeitet aus den letzten Nachrichten, den letzten Threads und dem Projektgedächtnis (externe Seite, code.claude.com). Was nie verloren gehen darf, gehört deshalb ins Projektgedächtnis. Modell und Aufwand lassen sich für Koordinator und Threads getrennt einstellen, ab Werk laufen beide auf Opus, der Koordinator mit niedrigem und die Threads mit hohem Aufwand.

Telefon, Browser, Terminal

Projekte gibt es laut Dokumentation (externe Seite, code.claude.com) an drei Orten: unter claude.ai/code, in der Desktop-App und in der Mobil-App von Claude. Die Kommandozeile im Terminal gehört nicht dazu.

Vom Telefon aus lässt sich damit jeder Thread öffnen, lesen und anweisen, und die Threads in der Cloud arbeiten weiter, während der Laptop zugeklappt ist. Eine Sitzung, die Sie selbst im Terminal starten, lässt sich auch nachträglich keinem Projekt zuordnen. Die Verbindung zum eigenen Rechner läuft in die Gegenrichtung, über Remote Control (externe Seite, code.claude.com): Wer in einem Ordner claude remote-control startet und laufen lässt, gibt diesen Ordner frei, und das Projekt kann einen Thread dort ausführen, etwa wenn eine Aufgabe eine lokale Datenbank oder einen Dienst hinter dem VPN braucht. Ein solcher Thread arbeitet mit den Dateien, Werkzeugen und Einstellungen dieses Rechners und startet mit den Pro­jekt­an­wei­sungen. Das Projektgedächtnis lädt er nicht, und er läuft nur, solange der Rechner wach ist. Zum Start am 17.09.2026 liefen alle Threads in der Cloud, und die Ausführung auf dem eigenen Rechner war für bald angekündigt (externe Seite, claude.com).

Wer im Terminal bleibt, hat dort eigene Wege, mehrere Sitzungen zu führen. Am nächsten an einem Projekt sind die Agententeams: Eine Sitzung übernimmt die Leitung (externe Seite, code.claude.com), verteilt Aufgaben an weitere Sitzungen und fasst die Ergebnisse zusammen. Läuft das Terminal in tmux oder in iTerm2, bekommt jedes Teammitglied einen eigenen Bereich im Fenster (externe Seite, code.claude.com), in den man hineinklicken und direkt eingreifen kann. Die Koordination liegt dabei bei der leitenden Sitzung, tmux liefert die Aufteilung des Fensters. Die Agententeams sind experimentell und ab Werk abgeschaltet (externe Seite, code.claude.com), und ihre Mitglieder arbeiten im selben Verzeichnis, weshalb jedes andere Dateien bearbeiten muss; warum, steht in Kapitel 04.

Sitzungen, die Sie selbst starten, etwa in mehreren Fenstern von tmux, bleiben Läufe ohne Koordinator. Sie können einander aber Nachrichten schicken (externe Seite, code.claude.com): Ändert eine Sitzung etwas, auf dem eine andere aufbaut, kann Claude die andere warnen. Für den Überblick gibt es die agent view, und von ihr sagt die Dokumentation (externe Seite, code.claude.com), dass Sie weiterhin jede Sitzung selbst starten und ihr die Aufgabe selbst geben. Remote Control schließlich verbindet claude.ai mit einer Sitzung auf dem eigenen Rechner (externe Seite, code.claude.com); damit ist auch eine selbst gestartete Terminal-Sitzung vom Telefon aus erreichbar, dann als einzelne Sitzung außerhalb jedes Projekts. Sobald zwei dieser Sitzungen dieselben Dateien berühren können, braucht jede ihren eigenen Worktree, wie oben beschrieben.

Zwei Eigenheiten

Anweisungen wie „höchstens zwei Threads gleichzeitig“ speichert Claude im Projektgedächtnis. Die Dokumentation stellt klar, dass ein so gesetztes Limit keine feste Obergrenze ist; wer eine Regel wörtlich und von Anfang an für jeden Thread will, schreibt sie in die Pro­jekt­an­wei­sungen. Außerdem hält ein Thread in der Cloud seine Sandbox zwischen zwei Schritten an. Lässt sie sich nicht fortsetzen, beginnt er mit einem frischen Klon, und was nicht committet war, kann dabei verloren gehen (externe Seite, code.claude.com). Bei langen Aufgaben lohnt deshalb die Anweisung, Zwischenstände zu committen und zu pushen, dieselbe Gewohnheit wie „klein und oft“ in Kapitel 04.

Und weil jeder Thread eine vollständige Sitzung ist, verbraucht ein Projekt dasselbe Kontingent wie Ihre übrigen Sitzungen, nur schneller (externe Seite, code.claude.com). Stößt ein Thread an die Grenze Ihres Abos, wartet er und läuft nach dem Zurücksetzen von selbst weiter. Eine Arbeit, die Sie laufen ließen, verbraucht so laut Dokumentation (externe Seite, code.claude.com) schon Ihr nächstes Nutzungsfenster, ohne dass Sie eine Nachricht geschickt haben. Was das bei Abrechnung nach Verbrauch heißt, steht im nächsten Abschnitt.

Was Abrechnung nach Verbrauch praktisch heißt

Bei Pauschale je Monat ist die Rechnung vorhersehbar und die Nutzung gedeckelt. Bei Abrechnung nach Verbrauch ist es umgekehrt, und die Streuung ist größer, als die Preistabelle vermuten lässt.

Derselbe Auftrag kostet je nach Vorgehen ein Vielfaches. Die Treiber:

• Wie oft der Kontext neu geschickt wird. Eine Aufgabe mit dreißig Tool-Schritten schickt den Sockel dreißigmal.
• Ob ein Cache greift. Bei gleichbleibendem Anfang des Kontexts wird der günstiger abgerechnet. Wer die Anweisungen ständig ändert, verliert das.
• Wie viel gedacht wird. Was ein Modell vor der Antwort denkt, wird als Ausgabe abgerechnet, und Ausgabe ist die teure Spalte. Der Beleg dafür steht in Grundkurs, Kapitel 10.
• Wie viele Läufe scheitern. Ein abgebrochener Lauf kostet alles, was bis dahin verbraucht wurde, und liefert dafür nichts.

Die praktische Regel lautet deshalb, den Aufwand zur Aufgabe zu wählen. Eine mechanische Umbenennung über vierzig Dateien braucht kein Nachdenken, eine Architekturfrage keine dreißig Tool-Schritte.

Die Kante zwischen Werkzeug und Bausatz

An einem Punkt hört die Tool-Wahl auf und etwas anderes fängt an: wenn man mit dem Agenten aufhört zu arbeiten und beginnt, etwas zu bauen, das selbst arbeitet.

Der Übergang ist erkennbar an einer einzigen Frage: Läuft es, wenn niemand zusieht?

Alles daran hängt:

• Es braucht eine Anmeldung, die ohne Browserfenster funktioniert.
• Es braucht ein Zeitlimit, sonst hängt es bis zum nächsten Neustart.
• Es braucht eine Aussage darüber, was ein Fehlschlag ist, und einen Weg, ihn zu melden. Ein Lauf, der still nichts tut, sieht von außen aus wie einer, der nichts zu tun fand.
• Es braucht einen definierten Ausgangszustand, sonst arbeitet es auf dem, was gerade herumliegt.

Das ist der Punkt, an dem aus Vibe-Coding Betrieb wird, und ab dort gelten die Regeln des Betriebs. Wer einen nächtlichen Lauf einrichtet und ihn nicht überwacht, hat sich einen Dienst gebaut, dessen Ausfall er zufällig bemerkt.

Die Angriffsfläche wächst mit den Rechten

Ein Agent mit Netzzugang und Ausführungsrecht liest Inhalte, die andere geschrieben haben, und handelt danach. Damit ist jeder gelesene Text eine mögliche Anweisung.

An dieser Stelle laufen zwei Risiken zusammen, die gern verwechselt werden. Das eine ist die untergeschobene Anweisung: Der Agent tut, was in einer fremden Datei steht. Das andere ist der Ausbruch: Der Agent oder der von ihm ausgeführte Code findet einen technischen Fehler und verlässt seine Umgebung. Die beiden Fälle, die hier belegt sind, gehören zur zweiten Sorte.

Der Angriff auf Hugging Face (externe Seite, huggingface.co) im Juli will dabei mit Vorsicht gelesen werden: Der Agent lief in einer Auswertung, für die der Betreiber die Schutzschichten eigens abgeschaltet hatte. Der zweite Fall zeigt die Grenze an der Sandbox selbst. Ein Sicher­heits­for­scher legt Schritt für Schritt offen (externe Seite, accomplish.ai), wie ein Agent aus seiner virtuellen Maschine ausbricht, und hält fest, dass der dafür genutzte Fehler der austauschbare Teil der Kette ist. Er arbeitet an einem konkurrierenden Entwurf und schreibt das in seinem Schlussabschnitt dazu.

Was daraus folgt, ist eine Frage der Auslegung statt einer Liste von Verboten: Was hat der Agent überhaupt in Reichweite? Ein Lauf mit eigenen, eng geschnittenen Zugangsdaten in einem eigenen Verzeichnis richtet im schlimmsten Fall dort Schaden an. Ein Lauf mit den Rechten des Benutzers richtet ihn überall an.

Woran man ein Werkzeug nach einer Woche beurteilt

Das erste Ergebnis sagt wenig. Nach einer Woche zählen drei Fragen:

Wie oft musste eine Änderung zurückgenommen werden? Wie oft hat es behauptet, etwas getan zu haben, das es nicht getan hat? Wie lange dauert es von der Beschreibung bis zu dem Punkt, an dem Sie das Ergebnis verantworten würden?

Die dritte Zahl schließt die beiden anderen ein, denn Rücknahmen und falsche Erfolgsmeldungen kosten genau die Zeit, die sie misst. Bei einem schnellen Werkzeug mit schlechter Rückmeldung fällt sie deshalb schlechter aus als bei einem langsamen mit guter.