DeepSeek Harness Compaction: Kosten 2026 senken

Symptom: Die Cache-Trefferquote bleibt hoch, aber Tokenverbrauch, Antwortzeit oder Monatskosten steigen trotzdem.
Schnellste Lösung: Erfassen Sie zunächst die tatsächlichen Usage-Felder, kürzen Sie übergroße Tool-Ergebnisse und komprimieren Sie erst danach den Sitzungsverlauf – mit überprüfbarem Zustand vor und nach der Compaction.

Zu dieser Anleitung: Sie richtet sich an Einzelentwickler mit langen DeepSeek-Harness-Sitzungen, an Teams mit dauerhaft laufenden Agenten sowie an technische Verantwortliche, die Modellkosten und Arbeitsumgebung gemeinsam bewerten müssen.

Stand: zuletzt aktualisiert am 18.08.2026; Kosten-, Cache- und Usage-Angaben wurden anhand der aktuellen DeepSeek-API-Dokumentation und des geprüften Harness-Repository-Stands verifiziert. Preview-Funktionen, Ereignisfelder und Standardwerte können sich mit neuen Versionen ändern.

SECTION 01Warum hohe Cache-Treffer nicht automatisch niedrige Gesamtkosten bedeuten

DeepSeek weist im usage-Block unter anderem prompt_cache_hit_tokens und prompt_cache_miss_tokens aus. Diese Felder zeigen, welcher Teil der Eingabe aus dem Cache bedient wurde und welcher Teil neu verarbeitet werden musste. Sie sagen aber nicht, dass die gesamte Eingabe klein geblieben ist. (api-docs.deepseek.com)

Für Ihre Diagnose müssen Sie vier Mengen auseinanderhalten:

• Neue Eingabe: die aktuelle Nutzeranweisung, neue Dateien oder neue Anforderungen.
• Aufgelaufene Historie: frühere Nutzer- und Assistentenbeiträge, Tool-Aufrufe und deren Ergebnisse.
• Systemkontext: Regeln, Tool-Schemata, Projektbeschreibung und Sicherheitsvorgaben.
• Modellausgabe: Antwort-, Denk- oder Tool-Call-Inhalte, sofern sie vom Harness erneut in die nächste Anfrage übernommen werden.

Bei einem Agenten wird die nächste Anfrage häufig aus der bisherigen Historie plus dem neuen Arbeitsschritt gebildet. Selbst wenn der stabile Anfang der Eingabe wiedererkannt wird, wächst der veränderliche Teil weiter. Die Rechnung lautet daher nicht „Trefferquote gleich Kosten“, sondern:

Gesamtkosten = Cache-Treffer-Token × Trefferpreis + Cache-Fehl-Token × Fehlpreis + Ausgabe-Token × Ausgabepreis

DeepSeek veröffentlicht die Preise nach Tokenklasse und weist darauf hin, dass sie sich ändern können. Auf der aktuell geprüften Preisseite werden für die dort aufgeführten V4-Modelle getrennte Preise für Cache-Treffer, Cache-Fehlzugriffe und Ausgabe angegeben. Verwenden Sie für eine Budgetplanung immer die am Tag der Berechnung gültige Preisseite, nicht einen alten Screenshot oder eine zwischengeschaltete Auswertung. (api-docs.deepseek.com)

Die entscheidende Frage lautet deshalb: Welche Tokenmenge wächst pro Runde, und welcher Anteil davon ist überhaupt noch für die nächste Entscheidung erforderlich?

SECTION 02Die eigentliche Ursache liegt oft in der Sitzungsverlängerung

Eine lange Coding-Sitzung kann denselben Sachverhalt mehrfach in den Kontext tragen:

1. Der Agent liest eine Datei vollständig.
2. Ein Tool gibt zusätzlich Suchtreffer oder Build-Ausgaben zurück.
3. Der Agent fasst den Zustand zusammen.
4. Beim nächsten Schritt werden Teile der ursprünglichen Datei, die Tool-Ausgabe und die Zusammenfassung erneut übertragen.
5. Ein weiterer Test ergänzt neue Fehlermeldungen, ohne alte Ausgaben zu entfernen.

Das Problem ist nicht nur die Länge einzelner Nachrichten. Kritisch ist die Kombination aus Wiederholung, wechselnden Präfixen und fehlender Zustandsverwaltung. Ein stabiler Systemprompt kann den Cache begünstigen; eine ständig veränderte Tool-Ausgabe oder eine neue Arbeitsbereichsbeschreibung kann den wiederverwendbaren Präfix dagegen verkürzen.

Die offizielle Cache-Dokumentation beschreibt den Mechanismus als „best effort“. Der Cache garantiert weder eine konstante Trefferquote noch eine dauerhafte Speicherung. Zudem wird nur der passende Präfix wiederverwendet; die Ausgabe wird weiterhin neu erzeugt. (api-docs.deepseek.com)

Für Sie bedeutet das:

• Eine hohe Trefferquote kann bei wachsender absoluter Eingabemenge weiterhin teuer werden.
• Ein neuer Arbeitsbereich oder ein wechselnder Systemteil kann Cache-Vorteile abschwächen.
• Eine Anzeige im Harness ist nicht automatisch identisch mit den Rohfeldern der DeepSeek API.
• Drittanbieter-Parser können Felder umbenennen, zusammenfassen oder falsch gewichten.

Verwenden Sie für die Kostenanalyse deshalb die originale API-Antwort und speichern Sie mindestens Modell, Zeitstempel, Sitzungs-ID sowie die vollständigen usage-Felder.

SECTION 03Tool-Ergebnisse zuerst kürzen, bevor Sie eine Zusammenfassung erzeugen

In Agent-Workflows sind nicht die Nutzerfragen allein der Kostentreiber. Besonders schnell wachsen:

• Build- und Testprotokolle mit wiederholten Stacktraces,
• Suchergebnisse mit hunderten ähnlichen Treffern,
• vollständige Dateien, die mehrfach gelesen werden,
• Paketmanager- oder Installationsausgaben,
• große JSON-, CSV- oder Diagnose-Dateien,
• wiederholte Fehlversuche desselben Tools.

Die richtige Reihenfolge ist mechanisches Kürzen vor semantischer Zusammenfassung. Ein einfacher Filter kann identische Logblöcke entfernen, nur die letzten relevanten Fehlerzeilen behalten oder bereits gespeicherte Dateiinhalte durch einen Verweis ersetzen. Erst wenn diese Reduktion nicht genügt, sollte ein LLM eine kompakte Zusammenfassung erstellen.

Behalten Sie vollständige Beweise außerhalb der Sitzung. Dazu gehören beispielsweise:

• der vollständige fehlgeschlagene Testlauf,
• ein Patch oder Diff,
• die exakte Version einer geänderten Datei,
• ein Sicherheits- oder Compliance-relevantes Protokoll,
• reproduzierbare Eingaben und Ausgaben,
• eine Fehlermeldung, die später rechtlich oder technisch nachgewiesen werden muss.

In der Unterhaltung genügt dann eine strukturierte Referenz:

Artefakt: /workspace/logs/test-2026-08-18.txt
Relevanter Abschnitt: Zeilen 1840–1912
Status: 3 Tests fehlgeschlagen
Ursache: Timeout im HTTP-Client
Nächster Schritt: Retry-Konfiguration prüfen

So bleibt der Agent handlungsfähig, ohne den vollständigen Log bei jedem weiteren Turn mitzuschleppen. Im geprüften Harness-Stand sind Compaction-Dienste, ein grundlegendes Zusammenfassungs-Backend, Werkzeug zur Ergebnisbegrenzung und ein manueller Kompressionsbefehl als Bestandteile beziehungsweise Arbeitsabläufe dokumentiert. Die konkreten Auslöser und Standardkombinationen bleiben jedoch versionsabhängig. (github.com)

Vor- und Nachteile der Werkzeugkürzung

Vorteile:

• weniger veränderlicher Kontext,
• geringere Wahrscheinlichkeit, dass alte Fehler neue Entscheidungen überlagern,
• kleinere Anfragen an die API,
• bessere Lesbarkeit für Sie und den Agenten.

Nachteile:

• wichtige Zeilen können durch zu aggressive Filter verschwinden,
• reine Kürzung erkennt keine widersprüchlichen Zustände,
• eine Zusammenfassung ersetzt keinen vollständigen Prüfbeleg,
• falsch gesetzte Grenzen können den Agenten zu einer bereits verworfenen Lösung zurückführen.

Die Regel lautet daher: Kürzen Sie Darstellung, nicht Beweiskraft.

SECTION 04Was Compaction bewirken soll – und wo sie gefährlich wird

Compaction ersetzt einen langen Verlauf durch einen komprimierten Zustand. Das Ziel ist nicht, jede frühere Nachricht zu bewahren, sondern die Informationen zu erhalten, die für den nächsten Arbeitsschritt zwingend sind.

Eine brauchbare Zusammenfassung muss mindestens diese Punkte enthalten:

• ursprüngliches Ziel und aktuelle Teilaufgabe,
• bereits geänderte Dateien,
• noch offene Dateien oder Entscheidungen,
• ausgeführte Tests und deren Ergebnis,
• bekannte Fehler mit exakter Ursache,
• Nutzeranforderungen und Ausschlüsse,
• aktuelle Arbeitsbereichsgrenzen,
• ausstehende Tool-Aktionen,
• externe Artefakte mit Pfad und Zweck.

Der häufigste Fehler ist eine sprachlich gute, aber operativ unvollständige Zusammenfassung. „API angepasst, Tests noch offen“ ist für einen Agenten nicht ausreichend, wenn drei Dateien geändert wurden, ein Test wegen einer Umgebungsvariable fehlschlug und die nächste Aktion nur in einem bestimmten Unterverzeichnis erlaubt ist.

Prüfen Sie Compaction deshalb nicht nur durch Lesen der Zusammenfassung. Führen Sie vor und nach der Kompression dieselbe Kontrollhandlung aus:

1. Lassen Sie das aktuelle Ziel in einem Satz nennen.
2. Fragen Sie nach allen geänderten Dateien.
3. Lassen Sie offene Tests und bekannte Fehler auflisten.
4. Geben Sie denselben nächsten Arbeitsschritt vor.
5. Vergleichen Sie, ob der Agent dieselbe Datei, denselben Test und dieselbe Einschränkung auswählt.

Wenn eine kritische Antwort nach der Kompression fehlt, gibt es zwei sichere Wege: Zustand aus externen Artefakten wieder einfügen oder eine neue Sitzung mit einem kontrollierten Übergabeprotokoll eröffnen.

SECTION 05Kosten- und Zustandsprüfung in fünf umsetzbaren Schritten

1. Rohdaten pro Anfrage speichern

Speichern Sie jede API-Antwort oder zumindest deren usage-Block. Relevant sind insbesondere:

• Eingabe-Token,
• Ausgabe-Token,
• Cache-Treffer-Token,
• Cache-Fehl-Token,
• Modellname,
• Sitzungskennung,
• Zeitstempel,
• Antwortdauer.

Die DeepSeek-API-Dokumentation beschreibt die Cache-Felder ausdrücklich als Teil des Antwortobjekts. Prüfen Sie, ob Ihr Harness diese Werte unverändert weitergibt oder intern eigene Summen bildet. (api-docs.deepseek.com)

2. Token-Wachstum nach Quelle aufteilen

Markieren Sie Nachrichten nicht nur nach Rolle, sondern nach Funktion:

• system,
• Nutzerauftrag,
• Agentenantwort,
• Tool-Aufruf,
• Tool-Ergebnis,
• Zustandszusammenfassung,
• externe Artefakt-Referenz.

Ermitteln Sie anschließend, welche Kategorie zwischen zwei Runden gewachsen ist. Ohne diese Aufteilung bleibt „zu viele Token“ eine Vermutung.

3. Werkzeugausgaben begrenzen

Definieren Sie je Werkzeug eine Rückgabestrategie. Ein Testwerkzeug darf beispielsweise Status, relevante Fehlzeilen und Artefaktpfad liefern. Ein Dateilesewerkzeug sollte bei großen Dateien zunächst nur Ausschnitte oder eine Strukturübersicht zurückgeben. Vollständige Inhalte werden nur dann erneut geladen, wenn sie für den nächsten konkreten Edit erforderlich sind.

4. Compaction mit Kontrollfragen auslösen

Komprimieren Sie nicht sofort beim ersten Anzeichen höherer Kosten. Warten Sie, bis der Verlauf tatsächlich redundante oder veraltete Informationen enthält. Führen Sie anschließend die Kontrollfragen aus und vergleichen Sie die Antworten mit dem Zustand vor der Kompression.

5. Bei verändertem Ziel eine neue Sitzung starten

Eine neue Sitzung ist vorzuziehen, wenn:

• das Projektziel gewechselt hat,
• ein anderes Repository oder Unterverzeichnis bearbeitet wird,
• frühere Fehlversuche nicht mehr relevant sind,
• sich Berechtigungen oder Sicherheitsgrenzen geändert haben,
• die alte Historie überwiegend aus irrelevanten Tool-Ausgaben besteht.

Für eine Übergabe speichern Sie Ziel, Dateiliste, Teststatus, offene Risiken und Artefaktpfade in einer kurzen Startnotiz.

SECTION 06Der richtige Einsatz hängt von drei Situationen ab

Zusammenhängende Aufgabe:
Bleibt das Ziel identisch, arbeitet der Agent im selben Repository und sind die offenen Entscheidungen dokumentiert, ist Compaction meist sinnvoll. Sie erhalten die Kontinuität, ohne den gesamten Verlauf dauerhaft zu übertragen.

Neuer Arbeitsschwerpunkt:
Ändert sich die Aufgabe von Fehlersuche zu Architekturplanung oder von Implementierung zu Dokumentation, ist ein neuer Kontext häufig sauberer. Die alte Sitzung enthält dann zwar wertvolle Historie, aber nicht zwingend relevante Entscheidungsgrundlagen.

Prüf- oder Compliance-Aufgabe:
Trennen Sie vollständige Protokolle und Arbeitsartefakte vom Modellkontext. Der Agent erhält eine geprüfte Zusammenfassung mit Verweisen; das Original bleibt unverändert gespeichert. Dadurch lässt sich später nachvollziehen, worauf eine Entscheidung beruhte.

Ihre Entscheidung als überprüfbare Checkliste

• [ ] Sind Ziel, Repository und Arbeitsbereich nach der Kompression unverändert?
• [ ] Sind alle geänderten Dateien mit Pfad und aktuellem Status bekannt?
• [ ] Sind fehlgeschlagene Tests, Fehlermeldungen und offene Aufgaben erhalten?
• [ ] Gibt es für abgeschnittene Tool-Ergebnisse ein externes Artefakt?
• [ ] Wurden Cache-Treffer und Cache-Fehlzugriffe aus der API-Antwort übernommen?
• [ ] Wurde dieselbe Kontrollfrage vor und nach Compaction ausgeführt?
• [ ] Ist der Zustand nach der Kompression reproduzierbar?
• [ ] Würde ein neuer Agent die nächste Aktion ohne erneute Vollanalyse finden?
• [ ] Haben sich Projektziel, Berechtigungen oder Arbeitsbereichsgrenzen geändert?
• [ ] Falls ja: Wurde eine neue Sitzung mit einer Übergabenotiz gestartet?

Wenn einer der ersten vier Punkte nicht erfüllt ist, sollten Sie nicht allein wegen einer niedrigeren Tokenzahl fortfahren.

SECTION 07Häufige Fragen

Warum kann der Tokenverbrauch trotz hoher Cache-Trefferquote steigen?

Die Trefferquote ist ein Verhältnis, keine absolute Größenangabe. Wenn eine Sitzung von Runde zu Runde mehr Historie und Tool-Ergebnisse überträgt, kann der gecachte Anteil hoch bleiben, während die gesamte Eingabe wächst. Prüfen Sie daher die Tokenmengen pro Anfrage und die Summen über die gesamte Sitzung. Die offiziellen Usage-Felder sind dafür belastbarer als eine grafische Prozentanzeige. (api-docs.deepseek.com)

Kann Compaction wichtige Informationen aus einer Programmieraufgabe verlieren?

Ja, insbesondere bei impliziten Zuständen. Geänderte Dateien, Testfehler, Nutzerrestriktionen und offene Entscheidungen müssen ausdrücklich in der Zusammenfassung stehen. Prüfen Sie den komprimierten Verlauf mit denselben Fragen und Aktionen wie zuvor. Bei widersprüchlichen Antworten sollte der Agent auf ein gespeichertes Artefakt zurückgreifen oder eine neue Sitzung beginnen.

Wann ist eine neue Sitzung besser als Compaction?

Trennen Sie Sitzungen bei einem Zielwechsel, einem neuen Repository, anderen Berechtigungen oder einer stark fehlerbehafteten Historie. Bleibt die Aufgabe unverändert und der Zustand ist vollständig dokumentiert, ist Compaction meist effizienter. Der Auslöser sollte also der fachliche Zusammenhang sein, nicht ein pauschaler Nachrichten- oder Turn-Zähler.

Wie reduzieren Sie zu lange Tool-Ergebnisse?

Entfernen Sie doppelte Ausgaben, begrenzen Sie Suchtreffer und ersetzen Sie wiederholt gelesene Dateien durch Artefaktverweise. Bewahren Sie vollständige Logs und Diffs extern auf. Für den Agenten reichen relevante Zeilen, Status, Pfad und nächster Schritt, solange die Originaldaten weiterhin abrufbar und unverändert gespeichert sind.

Welche Daten gehören in eine belastbare Kostenschätzung?

Erfassen Sie Eingabe-, Ausgabe-, Cache-Treffer- und Cache-Fehl-Token je Anfrage. Ergänzen Sie Antwortzeit, Speicherverbrauch, Speicherwachstum und manuelle Wiederherstellungszeit. Die aktuellen Preise müssen aus der offiziellen DeepSeek-Preisdokumentation stammen, da sich Modelle, Preisstufen und Felder ändern können. (api-docs.deepseek.com)

SECTION 08Nicht nur die API-Kosten prüfen

Eine Compaction kann die Tokenrechnung senken und trotzdem den Gesamtaufwand erhöhen. Wenn der Agent nach der Kompression einen falschen Test ausführt, eine Datei erneut analysiert oder Sie den verlorenen Zustand manuell rekonstruieren müssen, entsteht ein zusätzlicher Arbeitskostenblock.

Messen Sie bei einem identischen Basistask mindestens:

• Tokenklassen und Modell,
• Cache-Treffer und Cache-Fehlzugriffe,
• Zeit bis zur ersten Antwort und Gesamtdauer,
• Arbeitsspeicher des laufenden Harness,
• Wachstum von Logs und Sitzungsdateien,
• Anzahl der Wiederholungen,
• manuelle Korrekturzeit,
• Ergebnisqualität und Teststatus.

Vergleichen Sie nicht eine einzelne billige Anfrage mit einer einzelnen teuren Anfrage. Führen Sie denselben Task mit derselben Modellversion und denselben Werkzeugen einmal ohne Änderung, einmal mit Tool-Kürzung und einmal mit Compaction aus. Erst eine wiederholbare Reihe zeigt, ob die Strategie stabil ist.

Ein technischer Verantwortlicher sollte daraus drei Budgetentscheidungen ableiten:

• Weiterlaufen: Tokenwachstum ist kontrolliert, der Zustand bleibt vollständig und die Umgebung ist nicht überlastet.
• Strategie anpassen: Kosten steigen hauptsächlich durch Tool-Ausgaben oder unnötige Historie; zuerst Kürzung und bessere Artefaktverwaltung einführen.
• Umgebung trennen: Mehrere Agenten blockieren sich, Speicher- und Speicherplatzverbrauch wachsen oder Sitzungen beeinflussen sich gegenseitig.

Für die Planung einer dauerhaft verfügbaren Arbeitsumgebung können Sie die MACNOX-Optionen für eine gemietete Mac-Umgebung prüfen. Entscheidend ist dabei nicht nur der Modellpreis, sondern ob Sitzungen getrennt, reproduzierbar und datenschutzgerecht betrieben werden können.

SECTION 09Warum die Umgebung bei langen Agentenaufgaben mitentscheidet

Auf einem dauerhaft belegten lokalen Mac konkurrieren mehrere Sitzungen um Arbeitsspeicher, Prozessorzeit, Speicherplatz und Netzwerkzugriff. Das kann dazu führen, dass ein eigentlich kostengünstiger Workflow durch langsame Builds, blockierte Tools oder manuelle Neustarts teurer wird. Bei sensiblen Projekten kommen zusätzlich Fragen zu Zugriff, Protokollaufbewahrung und DSGVO-konformer Datenverarbeitung hinzu.

Eine gemietete Mac-Umgebung ist nicht automatisch die beste Lösung. Wenn Sie über Monate hinweg eine konstante hohe Last haben, physische Schnittstellen benötigen oder spezielle lokale Hardware einsetzen müssen, kann der eigene Mac wirtschaftlicher sein. Für zeitlich begrenzte Agent-Tests, parallele Evaluierungen und getrennte Arbeitsbereiche kann eine gemietete Umgebung jedoch die sauberere Option sein. Informationen zu verfügbaren MACNOX-Mac-Arbeitsumgebungen helfen Ihnen, den Bedarf an Sitzungsdauer und paralleler Nutzung gegen die laufenden Mietkosten abzuwägen.

Der praktische Unterschied zum aktuellen lokalen Setup liegt oft nicht allein in der Rechenleistung: Ein belegter Rechner vermischt persönliche Nutzung und Agentenprozesse, lokale Sitzungen können sich gegenseitig Ressourcen entziehen, und ein Neustart oder Arbeitsplatzwechsel unterbricht lange Aufgaben. Wenn genau diese drei Nachteile Ihre Token- und Wiederherstellungskosten erhöhen, ist MACNOX für einen zeitlich begrenzten Test- oder Parallelbetrieb eine sinnvollere Ergänzung als die nächste ungeprüfte Compaction-Regel. Prüfen Sie zuerst die Messdaten; mieten Sie den Mac dann für das Zeitfenster, in dem Sie isolierte, reproduzierbare DeepSeek-Harness-Läufe benötigen.

SECTION 10FAQ