Deep Agents v0.7 senkt Token pro Runde um 65%

Deep Agents v0.7 reduziert die grundlegenden Eingabe-Token pro Runde um 65%. Das bedeutet weniger festen Prompt-Overhead bei jedem Aufruf, geringere API-Kosten und mehr Kontextplatz für die wirklich wichtigen Teile der Aufgabe.

Das Update lässt sich so zusammenfassen:

• Der standardmäßige Basis-System-Prompt wurde entfernt
• Die integrierten Tool-Beschreibungen sind kürzer
• Todos werden nicht mehr standardmäßig angehängt
• Middleware wird gezielt ausgewählt statt gebündelt
• Die Einsparungen stammen vom Harness, nicht vom Modell

Einfach ausgedrückt: Wenn ein Agent 10 Aufrufe ausführt, wurde derselbe feste Rahmen früher 10 Mal gesendet. In v0.7 ist dieser Rahmen standardmäßig deutlich kleiner. Dadurch fällt die Anfrage in jeder Runde schlanker aus, besonders bei einfachen Aufgaben wie dem Lesen oder Schreiben von Dateien.

Einige Punkte stechen hervor:

• Die Kosten skalieren mit llm_calls × input_tokens_per_call
• Die alte Konfiguration sendete Text für Planung, Dateisystem und Sub-Agenten, selbst wenn eine Aufgabe ihn nicht benötigte
• Die neue Konfiguration überträgt mir die Kontrolle, sodass ich Prompt, Tools und Middleware passend zur Aufgabe auswähle
• Die größten Einsparungen entstehen durch das Entfernen des Basis-Prompts und das Kürzen der Tool-Texte
• Lange Workflows mit mehreren Agenten profitieren am meisten, weil sich der feste Overhead bei jedem Schritt wiederholt

Hier ist der einfache Vorher-Nachher-Vergleich:

Mein Fazit: Bei v0.7 geht es weniger um Modelländerungen als um Prompt-Disziplin. Halte ich das Harness schlank, bleiben die gesamten 65% erhalten. Füge ich wieder zahlreiche Middleware-Komponenten und Tools hinzu, geht ein Teil dieses Vorteils verloren.

Das ist der Kern des Updates und die Grundlage für den Rest des Artikels.

Was sich am konfigurierbaren Harness geändert hat

Die Token-Reduzierung um 65% entstand durch eine Änderung der Inhalte, die das Harness in jeder Runde einfügt, und nicht durch ein intelligenteres Modell. Kurz gesagt entfernt v0.7 einen großen Teil des Standardtexts, der früher mit jeder Anfrage gesendet wurde.

Basis-System-Prompt entfernt und Tool-Beschreibungen gekürzt

Vor v0.7 packte das Harness einen standardmäßigen System-Prompt, lange Tool-Beschreibungen, Planungs-Middleware und Sub-Agenten-Logik in jede Anfrage, selbst wenn die Aufgabe nichts davon erforderte. v0.7 macht das Harness konfigurierbar, sodass Entwickler entscheiden, was in jeder Runde eingefügt wird.

Die größten Overhead-Quellen waren der standardmäßige Basis-System-Prompt und die langen integrierten Tool-Beschreibungen. Der Basis-Prompt enthielt Anweisungen für Planungstools, Dateisystem-Tools und Sub-Agenten und wurde in jeder Runde gesendet. In v0.7 wurde dieser Prompt entfernt. Entwickler können jetzt einen zur Aufgabe passenden Prompt-Text bereitstellen.

Auch die integrierten Beschreibungen für Hilfsprogramme wie ls, read_file und write_file wurden gekürzt. Die Tools verhalten sich weiterhin gleich. Jede Anfrage enthält lediglich weniger festen Begleittext. Keine der Änderungen betrifft das zugrunde liegende Modell. Sie reduzieren nur die Token-Last, die früher jede Runde tragen musste.

Todos sind optional und Middleware lässt sich nun ausdrücklich auswählen

Vor v0.7 wurde todoListMiddleware standardmäßig angehängt, sodass in jeder Runde Planungstext gesendet wurde. In v0.7 sind Todos optional. Sie werden also nur hinzugefügt, wenn eine Aufgabe tatsächlich von einer mehrstufigen Planung profitiert.

Dieselbe Umstellung gilt für den restlichen Middleware-Stack. FilesystemMiddleware und SubAgentMiddleware sind nicht mehr standardmäßig gebündelt. Entwickler können nur die benötigte Middleware zusammenstellen. Eine Aufgabe zum Lesen von Dateien kann Sub-Agenten-Logik auslassen. Ein Verifizierungsworkflow kann Checklisten-Middleware nur dann hinzufügen, wenn sie hilfreich ist.

Wie die Orchestrierung expliziter wird

Die praktische Änderung ist einfach: Die Konfiguration wechselt von impliziten Vorgaben zu ausdrücklichen Einstellungen. Statt das Harness entscheiden zu lassen, welche Tools sichtbar sind, welche Middleware ausgeführt wird und was der System-Prompt sagt, treffen Entwickler diese Entscheidungen selbst. Sie kontrollieren jetzt Prompt-Zusammenstellung, Tool-Sichtbarkeit und Middleware für jede einzelne Aufgabe.

Diese Änderungen zeigt der folgende Standard-Agenten-Stack. ^[2]

Token-Nutzung im Vorher-Nachher-Vergleich

Die Änderungen am Harness zeigen sich sofort in der Nutzlast jeder Runde. Die Einsparungen entstehen durch einen kleineren festen Anfragerahmen und nicht durch eine Änderung des Nutzer-Prompts oder Modells.

Runde mit dem Standard-Agenten vor v0.7

Vor v0.7 enthielt jede Runde Gerüste für Planung, Dateisystem und Sub-Agenten, auch wenn nichts davon verwendet wurde. Todo-Texte und Middleware-Prompts waren ebenfalls standardmäßig enthalten. Dadurch wiederholte sich in jeder Runde eine große feste Nutzlast.

Runde mit dem Standard-Agenten nach v0.7

Nach v0.7 sendet eine einfache Aufgabe zum Lesen einer Datei nur die Tools und Middleware, die sie benötigt. Der zusätzliche Overhead wiederholt sich daher nicht mehr über mehrere Runden hinweg. Der Basis-System-Prompt wurde entfernt, Tool-Beschreibungen sind kürzer und eine Aufgabe zum Lesen von Dateien trägt keinen ungenutzten Planungs- oder Sub-Agenten-Text mehr mit sich.

Wie Aaron Jewitt anmerkt, skalieren Agentenkosten mit llm_calls × input_tokens_per_call.^[1]

Woher die Token-Einsparungen stammen

Hier entsteht die Reduzierung um 65%.

Die größten Einsparungen entstehen durch das Entfernen des Basis-Prompts und das Kürzen der Tool-Beschreibungen. Deshalb machen eine selektive Middleware und eine eingeschränkte Tool-Sichtbarkeit in täglichen Workflows einen so deutlichen Unterschied.

Der nächste Abschnitt zeigt, wie Entwickler diese Einsparungen bewahren, indem sie nur die Harness-Bestandteile auswählen, die eine Aufgabe braucht.

Harness-Konfigurationsmuster für Entwickler

Sobald die Token-Einsparungen gesichert sind, besteht der nächste Schritt darin, für jede Aufgabe ein schlankes Harness-Profil zu wählen. Die Einsparungen stammen aus kleineren Prompts und enger gefassten Harness-Vorgaben. In Deep Agents v0.7 verursacht das Harness und nicht das Modell den größten Teil des Token-Overheads pro Runde. Bei der Optimierung von Deep Agents v0.7 geht es daher weniger um die Modellwahl als um die Zusammenstellung des Harness.

Nur die für die Aufgabe benötigte Middleware auswählen

Verwenden Sie Middleware nur, wenn eine Aufgabe Kontrollpunkte, Planung oder Zustandsverwaltung erfordert. Bei kurzen Aufgaben erzeugen diese zusätzlichen Ebenen lediglich Overhead.

Die Regel ist einfach: Beginnen Sie mit dem kleinsten Middleware-Stack, den die Aufgabe benötigt. Dasselbe gilt für Tools. Stellen Sie nur die Tools bereit, die für die aktuelle Aufgabe tatsächlich erforderlich sind.

Tool-Sichtbarkeit begrenzen und Beschreibungen kürzen

Alle Tools in jeder Runde anzuzeigen ist eine der schnellsten Möglichkeiten, die Eingabe pro Runde aufzublähen. Eine enge Tool-Sichtbarkeit hält den Prompt klein.

Kürzere Tool-Beschreibungen verkleinern den Prompt zusätzlich. Präzise, knappe Beschreibungen reduzieren die Prompt-Größe und erleichtern dem Modell die Auswahl des richtigen Tools, ohne viel zusätzlichen Kontext zu benötigen.

Optionale Todos und profilbasierte Vorgaben verwenden

Todo-Verwaltung hilft bei langfristigen Aufgaben, bei denen ein Agent den Fortschritt über viele Schritte hinweg verfolgen muss. Bei kurzen Aufgaben mit einem einzigen Schritt verursachen Todos Overhead, ohne einen Nutzen zu bieten.

Aktivieren Sie Todos nur für langfristige Aufgaben und legen Sie schlanke oder umfangreiche Vorgaben je Agentenklasse fest. Schlanke Vorgaben für Agentenklassen bewahren bei einfachen Agenten den Vorteil von 65%, während umfangreichere Profile für planungsintensive Workflows vorgesehen bleiben.

Diese Entscheidungen bestimmen, ob sich die Reduzierung um 65% im Alltag als geringere Kosten und schnellere Iteration bemerkbar macht.

Bedeutung des v0.7-Updates für Kosten, Geschwindigkeit und Skalierung

Niedrigere Inferenzkosten und schnellere Iterationsschleifen

Der kleinere Anfragerahmen summiert sich in langen Workflows bei jeder Runde. Token-Kosten wachsen über mehrstufige Ausführungen hinweg. Ein schlankes Harness spart daher nicht nur in der ersten Runde Geld, sondern hält auch den Ausgangspunkt jeder weiteren Runde kleiner. Mit wachsender Unterhaltung wird der Abstand größer.

So zeigt sich die Reduzierung in der Praxis:

Kleinere Nutzlasten beschleunigen außerdem Iterationsschleifen. Wenn Sie eine Prompt-Änderung testen oder eine neue Tool-Konfiguration ausprobieren, kehren leichtere Anfragen schneller zurück. Das beseitigt viel Reibung aus der täglichen Entwicklungsarbeit.

Bessere Skalierbarkeit für lange Workflows und mehrere Agenten

Diese Token-Einsparungen werden noch wichtiger, wenn mehrere Agenten dasselbe Workflow-Budget teilen. Fester Overhead ist ein unauffälliger Kostenfaktor in Multi-Agenten-Systemen. Trägt jeder Agent ein überdimensioniertes Harness, vervielfacht sich der Overhead über jede koordinierte Runde.

Ein schlankeres Harness-Paket hält den Bedarf jedes Agenten kleiner. Das verbessert den Durchsatz und verringert das Risiko, mitten in einem Workflow an Kontext- oder Ratenlimits zu stoßen.

Wenn sich Kontextfenster füllen, kann die Leistung sinken. Ein schlankes Harness lässt jedem Agenten mehr nutzbaren Kontextplatz für tatsächliche Aufgabendaten. Einfach gesagt bleiben länger laufende Workflows länger präzise, ohne dass Komprimierungs- oder Zusammenfassungslogik zu früh eingreifen muss.

Ein geringerer Overhead pro Aufruf ist bei Workflows mit vielen Runden, vielen Agenten oder beidem am wertvollsten. Die Token-Reduzierung um 65% senkt die Kosten pro Aufruf. Der größere Skalierungsvorteil entsteht jedoch durch das explizite Orchestrierungsmodell in v0.7. Mit klaren Abbruchkriterien statt offenen Schleifen benötigen Agenten insgesamt weniger Aufrufe, um eine Aufgabe abzuschließen.

Wichtigste Erkenntnisse aus der Veröffentlichung von Deep Agents v0.7

Deep Agents v0.7 verbessert Kosten und Qualität, indem das Harness konfigurierbar wird. Die Auswahl der Middleware, die Tool-Sichtbarkeit und profilbasierte Vorgaben entscheiden nun darüber, ob ein Workflow die gesamten Einsparungen behält oder einen großen Teil durch zusätzlichen Overhead wieder verliert.

Die Konfiguration ist der wichtigste Optimierungshebel. Sie zählt besonders in Workflows mit vielen Runden, vielen Agenten oder beidem.

Häufig gestellte Fragen

Wie behalte ich in realen Workflows die gesamten Token-Einsparungen von 65%?

Behandeln Sie die Harness-Konfiguration als lebendes System und nicht als einmalige Aufgabe. Messen Sie zunächst Token-Nutzung und Anzahl der LLM-Aufrufe. Verwenden Sie anschließend das Harness, um präzise Verhaltensregeln festzuschreiben.

Nutzen Sie PreCompletionChecklistMiddleware, um redundante Gedankenschleifen zu stoppen. Verwenden Sie LocalContextMiddleware, um nur den vom Modell benötigten Kontext und die notwendigen Tools zu übergeben. Fügen Sie Prompt-Caching hinzu, damit Systemanweisungen über mehrere Ausführungen hinweg stabil bleiben.

Wenn die Token-Nutzung ansteigt, suchen Sie nach Abweichungen und verschärfen Sie die Harness-Regeln.

Welche Aufgaben sollten weiterhin Todos oder zusätzliche Middleware verwenden?

Verwenden Sie todoListMiddleware, wenn der Agent ein komplexes, mehrteiliges Problem bearbeitet. Dadurch kann der Agent während der Arbeit verfolgen, was abgeschlossen ist und welche Punkte noch offen sind.

Wenn Sie im Prompt die Verwendung des Tools write_todos anfordern, kann der Agent den Fortschritt bei neuen Informationen aktualisieren. Das macht lange, anspruchsvolle Workflows leichter nachvollziehbar und hilft dem Agenten, den Kurs zu halten.

Beeinträchtigt ein kleineres Harness die Qualität oder Zuverlässigkeit des Agenten?

Standardmäßig nicht. Ein kleineres, abgestimmtes Harness kann dieselbe Zuverlässigkeit bewahren oder sogar verbessern, indem es Token pro Runde durch bessere Kontextverarbeitung, Tool-Auslagerung und strukturierte Prompt-Verpackung reduziert.

Die Qualität bleibt erhalten, wenn diese Einsparungen mit deterministischen Schutzmechanismen wie Verifizierungsschleifen und Checklisten vor Abschluss kombiniert werden. So bleibt der Agent auf die wichtigen Aufgabendaten konzentriert und prüft seine Arbeit, bevor er antwortet.