Tool-Kontext und Prompt-Caching

Zweierlei stimmt für jede Anfrage, die der eingebaute Harness stellt: Die Tool-Definitionen sind darin der größte feste Kostenblock, und fast keine davon wird benutzt. Diese Seite erklärt, was Control Center dagegen tut, und warum die Antwort nicht einfach „schicke weniger Tools“ lautet.

Das Problem ist die Aufmerksamkeit, nicht die Bytes

Control Center registriert etwa 126 Tools. Vollständig geschickt kosten ihre Definitionen grob 23.000 Token bei jeder Anfrage — Kosten, an die keine Verdichtung herankommt, weil die Tool-Definitionen in einem anderen Teil der Anfrage reisen als die Unterhaltung.

Die Tokenrechnung ist der naheliegende Einwand. Mit Prompt-Caching ist sie der kleinere. Die eigentlichen Kosten sind die Auswahlgenauigkeit. Veröffentlichte Auswertungen zum Tool-Aufruf kommen überein: Modelle wählen das richtige Tool zuverlässig, solange irgendwo bei etwa 30–50 Tools im Kontext stehen, und werden darüber hinaus stetig schlechter. Als Ursache gilt die semantische Überlappung, nicht die Tokenzahl. Sobald ein Katalog mehrere Tools enthält, deren Beschreibungen sich ähnlich lesen, wählt das Modell zwischen Doppelgängern, statt sich an eine Fähigkeit zu erinnern.

Bei 126 Tools liegt ein Agent bei jedem einzelnen Turn weit jenseits dieses Bandes — auch in den vielen Turns, in denen er nur eine Datei lesen musste.

Die zweistufige Oberfläche

Ein Lauf bekommt deshalb zwei Dinge zu sehen:

• eine residente Menge — grob zwei Dutzend Tools, bei jeder Anfrage mit vollem Schema geschickt;
• einen Namensindex von allem anderen, gruppiert unter Überschriften wie „Tickets and projects“ oder „Memory and knowledge“, der für den ganzen Katalog ein paar hundert Token kostet.

Am aktuellen Katalog gemessen schrumpft der Tool-Block damit von ~23,1k Token auf ~5,0k, etwa 78 % kleiner, und die immer sichtbare Menge liegt in dem Band, in dem die Auswahl zuverlässig ist.

Die residente Menge sind die Tools, die ein Lauf in den meisten Läufen braucht: das Datei- und Shell-Vokabular (read, write, edit, search, bash, …), die Discovery-Tools, die Aufgaben-Checkliste, die Gedächtnissuche und das Verb, das der aktuelle Modus aufrufen muss, um sein Ergebnis zu liefern. Das eigene Ausgabe-Verb eines Modus ist immer resident — ein Lauf darf nie erst nach dem einen Aufruf suchen müssen, der sein Lieferergebnis erzeugt.

Zurückgestellt heißt nicht unerreichbar

Das ist der Teil, der den Entwurf sicher macht und nicht nur billig. Ein zurückgestelltes Tool ist vom ersten Turn an aufrufbar. Zurückgehalten wird nur sein Schema.

Der Agent sieht den Namen in seinem Prompt. Ruft er diesen Namen direkt auf, lädt der Harness das Schema und führt das Tool im selben Schritt aus — kein Fehler, kein Roundtrip. Das Modell muss nicht wissen, dass das Tool je „entladen“ war.

Kennt der Agent die Aufgabe, aber nicht den Namen, nimmt search_tools eine Beschreibung in Alltagssprache („ein Ticket jemandem zuweisen“), reiht die ganze Oberfläche des Laufs und liefert die Treffer mit bereits geladenen Schemas, sodass der nächste Turn eines davon aufrufen kann. Findet eine Suche nichts, sagt sie das klar und schlägt eine andere Formulierung oder eine breitere Suche vor — absichtlich, denn ein Agent, der eine leere Suche als „diese Fähigkeit gibt es nicht“ liest, erfindet einen Ersatz, statt noch einmal nachzusehen.

search_tools gibt es nur im eingebauten Harness. Externe MCP-Clients haben stattdessen search_tool_bm25, das denselben Index reiht, Treffer aber nur beschreibt — diese Clients haben jedes Schema schon über tools/list bekommen, geladen werden muss also nichts.

Was die Zurückstellung nie tut

Die Zurückstellung greift nach dem Tool-Filter des Modus, nie an seiner Stelle. Sie versteckt ein Schema. Ein Tool, das der Modus verweigert hat, kann sie nicht hervorholen. Ein aktiviertes Tool durchläuft die Freigabeaufforderung und die Aktions-Schutzregeln genauso wie ein residentes, und ein Tool kann keinen Namen laden, der von Anfang an nicht auf der Oberfläche des Laufs stand.

Die MCP-Oberfläche, die externe Clients sehen, bleibt unangetastet. tools/list liefert weiter den vollständigen Katalog. Ein früherer Versuch, ihn zu stutzen, hat Agenten komplett außer Gefecht gesetzt: MCP-Clients prüfen Tool-Namen gegen ihre eigene gecachte Liste und lehnen alles ab, was nicht darauf steht, ohne den Server je zu fragen. Ein Tool „versteckt, aber aufrufbar“ war damit schlicht unerreichbar. Die Zurückstellung sitzt im Harness, und dort kann er ein Tool mitten im Lauf tatsächlich laden.

Ausschalten

--tool-deferral=off (oder CC_SERVER_TOOL_DEFERRAL=off) macht jedes zugelassene Tool wieder resident und erzeugt genau die Anfragen, die der Server stellte, bevor es die Zurückstellung gab. Siehe die Referenz zur cc_server CLI.

Prompt-Caching

Die Last von Agenten ist schief verteilt: Sie schicken riesige Prompts und bekommen kleine Antworten, Turn für Turn, jedes Mal mit demselben Präfix. Anbieter cachen dieses Präfix, und ein Lesezugriff auf den Cache kostet etwa ein Zehntel eines frischen. Die Cache-Trefferquote ist deshalb eine Eigenschaft erster Klasse des Harness und keine Optimierung am Rande. Bei Anthropic bringt sie zusätzlich Durchsatz, weil gecachte Token nicht gegen das Eingabelimit pro Minute zählen.

Caching trifft bei einem exakten Präfix. Daraus folgt eine Regel.

Schon Gesendetes nie umschreiben

Jedes geänderte Byte macht den Cache ab dieser Stelle ungültig. Der Harness hängt deshalb nur an: neue Nachrichten ans Ende, und neu aktivierte Tool-Schemas hinter den gecachten Tool-Block, nicht in ihn hinein. Diese Reihenfolge hält die Aktivierung billig: Das gecachte Präfix bleibt identisch, und der Lauf zahlt nur die Schemas, die er gerade geladen hat.

Die Schleife kürzt außerdem veraltete Tool-Ausgabe aus älteren Turns, um Kontext zurückzuholen. Sie wartet, bis genug zurückzuholen ist, dass sich das Umschreiben lohnt. Ein Schnitt ist damit ein seltenes, tiefes Umschreiben und kein dauernder Cache-Miss.

Wo die Marker sitzen

Ein Anbieter lässt nur eine begrenzte Zahl von Cache-Markern zu, und Control Center setzt sie bewusst:

Marker	Deckt	Lebensdauer
Letztes residentes Tool	Der Tool-Block	1 Stunde
Letzter Systemblock	Tools + System-Prompt	1 Stunde
Ende des vorigen Turns	Verlauf bis zur letzten Anfrage	5 Min.
Ende des aktuellen Turns	Der vollständige Verlauf	5 Min.

Die letzten beiden sind ein rollierendes Paar, und der Grund dafür ist fein: Eine Cache-Suche geht eine begrenzte Zahl von Blöcken rückwärts durch und sucht etwas, das eine frühere Anfrage abgelegt hat. Ein einzelner Turn, der viele Tools parallel ausführt, kann mehr Blöcke erzeugen, als dieses Fenster fasst. Dann verfehlt ein End-Marker still, und die Anfrage zahlt den vollen Preis, ohne dass die Antwort das anzeigt. Die genaue Stelle zu markieren, an der die vorige Anfrage aufgehört hat, macht den Treffer zur Struktur und nicht zum Wettrennen.

Das Präfix aus Tools und System bekommt die lange Lebensdauer, weil es über den ganzen Lauf konstant bleibt und jeder Lauf sowie jeder Subagent derselben Form es teilt. Die Uhr startet, wenn eine Anfrage beginnt — ein Turn, der mehrere Minuten streamt, hat von einem kurzen Fenster schon das meiste verbraucht, bevor die nächste Anfrage entsteht.

Subagenten teilen ein Präfix

Subagenten desselben Typs erzeugen bytegleiche Prompt-Präfixe. Sie sollen deshalb einen Cache-Eintrag lesen, statt dass jeder seinen eigenen schreibt. Lesbar wird ein Eintrag erst, wenn die Anfrage, die ihn geschrieben hat, zu antworten beginnt. Startet ein Fan-out auf einmal, zahlt jedes Kind den Aufpreis für ein Präfix, das sie alle teilen.

Der Harness lässt das erste Kind einer Form starten und gibt die Geschwister frei, sobald es zu streamen beginnt. Die Wartezeit ist begrenzt: Ein langsames erstes Kind kostet einen Cache-Treffer, den Fan-out selbst nie. Aus demselben Grund bekommt jeder Subagent dieselbe residente Tool-Menge, unabhängig vom Profil. Sie je Profil zu variieren würde das gemeinsame Präfix ohne Gewinn zerlegen, denn das Profil hat schon entschieden, was das Kind aufrufen darf.

Zusehen, wie es arbeitet

Beide Hälften lassen sich beobachten:

• Kontext in einer Unterhaltung zeigt die residenten Tools, den zurückgestellten Index und, was jedes zurückgehaltene Schema kosten würde, aufgebaut aus demselben Codepfad, den ein echter Lauf benutzt.
• Jeder Lauf zeichnet auf, welche zurückgestellten Tools er geladen hat und was das ausgelöst hat. Eine Suche ohne Treffer bleibt so als Fehltreffer beim Nachschlagen sichtbar, statt in einem Agenten zu verschwinden, der still etwas Benachbartes tut.
• Observability meldet die Cache-Rate als Cache-Lesezugriffe geteilt durch alle verarbeiteten Prompt-Token, Schreibzugriffe eingeschlossen. Ein Lauf, der sein Präfix immer wieder neu aufbaut, liegt niedrig, und nicht wie einer, der nie einen Cache gebraucht hat.