DeepSeek Harness: Einen Tag Kosten berechnen

„Einen Tag laufen lassen“ ist keine einheitliche Kostenart. Wir unterscheiden zunächst vier Betriebsformen:

1. Einzelaufgabe: Ein klar abgegrenzter Auftrag endet mit einem definierten Ergebnis.
2. Tagesbatch: Mehrere ähnliche Aufgaben werden nach einem festen Zeitplan verarbeitet.
3. Interaktive Entwicklung: Eine Person greift ein, ändert Prompts, prüft Ergebnisse und startet weitere Schritte.
4. Dauerhafter Agent: Der Prozess beobachtet, plant, ruft Tools auf und läuft mit automatischen Wiederholungen weiter.

Für jede Form brauchen wir eine Definition für „fertig“. Dazu gehören:

• erwartete Dateien, Tests oder Datensätze;
• erlaubte Anzahl von Wiederholungen;
• maximale Laufzeit;
• Bedingungen für einen sicheren Abbruch;
• Regel für menschliche Übernahme;
• Aufbewahrungsfrist für Logs und Artefakte.

Ohne diese Grenzen ist „DeepSeek Harness einen Tag Kosten berechnen“ nicht reproduzierbar. Zwei Läufe mit gleicher Dauer können völlig unterschiedliche Ergebnisse liefern, wenn einer nach einem erfolgreichen Test endet und der andere bei jedem Tool-Fehler weiterarbeitet.

Unsere Grundformel lautet:

Gesamtkosten =
API-Kosten
+ Mac-Umgebung
+ Speicher und Backups
+ Überwachung
+ menschliche Wartung

Die API-Kosten werden weiter zerlegt:

API-Kosten =
(Input Cache Hit × Hit-Preis)
+ (Input Cache Miss × Miss-Preis)
+ (Output × Ausgabe-Preis)
+ Wiederholungs- und Fehlversuchskosten

Die Zeit ist damit nur ein Auslöser für Verbrauch. Sie ist nicht der Verbrauch selbst.

Die offizielle Preisseite führt für DeepSeek V4 Flash und DeepSeek V4 Pro getrennte Preise für Cache-Treffer, Cache-Fehltreffer und Ausgabe-Token auf. Für V4 Flash nennt sie derzeit 0,0028 US-Dollar je Million Cache-Hit-Token, 0,14 US-Dollar je Million Cache-Miss-Token und 0,28 US-Dollar je Million Ausgabe-Token. Für V4 Pro sind es 0,003625, 0,435 und 0,87 US-Dollar je Million Token in den entsprechenden Kategorien. Die Preise können sich ändern; prüfen Sie vor jeder Budgetfreigabe die offizielle Preistabelle für Modelle und Token.

Die Tabelle beantwortet aber nur die Preisfrage. Für den Betrieb zählt die Kosten pro erfolgreicher Aufgabe.

V4 Flash ist der naheliegende Startpunkt für:

• standardisierte Codeänderungen;
• Extraktion und Klassifikation;
• einfache Batch-Aufgaben;
• kurze Tool-Schleifen;
• Vorprüfungen, bei denen ein Fehlschlag billig bleibt.

V4 Pro ist eher zu prüfen, wenn:

• die Aufgabe mehrere Abhängigkeiten gleichzeitig berücksichtigen muss;
• ein Fehler deutlich teurer ist als zusätzliche Ausgabe-Token;
• die Ausgabe nach einem Fehlversuch manuell korrigiert werden müsste;
• komplexe Planung oder anspruchsvolle Code-Analyse den Hauptanteil bildet.

Die richtige Kennzahl ist:

Kosten je erfolgreiche Aufgabe =
gesamte API- und Betriebskosten
÷ erfolgreich abgeschlossene Aufgaben

Ein günstigeres Modell kann durch zusätzliche Wiederholungen, längere Antworten oder mehr menschliche Prüfung teurer werden. Ein teureres Modell kann sich lohnen, wenn es die Zahl der Fehlversuche senkt.

Die offizielle Dokumentation beschreibt für beide Modelle eine Kontextlänge von 1.000.000 Token und eine maximale Ausgabe von bis zu 384.000 Token. Das ist eine technische Obergrenze, kein sinnvolles Tagesbudget. Setzen Sie max_tokens für jede Anfrage bewusst und nicht auf einen pauschal maximalen Wert. Die API-Referenz dokumentiert Modellwahl, Thinking-Modus und Ausgabelimit.

Der Cache ist kein Rabatt, den wir pauschal annehmen dürfen. Er hängt von der Struktur des Präfixes ab. Die offizielle Cache-Dokumentation erklärt, dass wiederverwendbare Präfixeinheiten an Anfragegrenzen gespeichert werden. Eine spätere Anfrage muss den passenden Präfix vollständig wiederverwenden; eine veränderte Einfügung kann den Treffer verhindern. Die Antwort enthält dafür prompt_cache_hit_tokens und prompt_cache_miss_tokens. Prüfen Sie die Cache-Regeln und Nutzungsfelder in der offiziellen Dokumentation.

Für einen Harness-Lauf sollten wir mindestens diese Felder in einer JSONL- oder Datenbankzeile speichern:

• Zeitstempel;
• Modell;
• Aufgaben-ID;
• Prompt-Token;
• Cache-Hit-Token;
• Cache-Miss-Token;
• Ausgabe-Token;
• Thinking aktiviert oder deaktiviert;
• Tool-Aufrufe;
• Wiederholungsgrund;
• Ergebnisstatus;
• menschliche Übernahme.

Thinking ist ebenfalls ein Kostenfaktor. Die offizielle API-Dokumentation nennt aktiviertes Thinking als Standard und beschreibt die Steuerung über thinking sowie reasoning_effort. Die Anleitung zum Thinking-Modus sollte deshalb Bestandteil der Runbook-Prüfung sein.

Ein häufiger Fehler ist die Budgetierung nur anhand sichtbarer Antwortlänge. Bei Agent-Aufgaben können zusätzliche Reasoning-Token, Tool-Ergebnisse, erneut übertragene Historie und Validierungsanfragen anfallen. Für jede Aufgabenklasse brauchen wir deshalb einen eigenen Messwert:

Token je Aufgabe =
Prompt-Token
+ Cache-Hit-Token
+ Cache-Miss-Token
+ Ausgabe-Token
+ Token aus Wiederholungen

Die Cache-Hit- und Cache-Miss-Werte dürfen nicht addiert und anschließend nochmals als gesamte Eingabe gezählt werden. Sie sind zwei Bestandteile derselben Eingabemenge.

Eine hohe Parallelität beschleunigt nicht automatisch die Zahl der gültigen Ergebnisse. Die dokumentierte Parallelitätsgrenze gilt pro Konto. Für V4 Pro nennt die offizielle Rate-Limit-Dokumentation 500 gleichzeitige Verbindungen, für V4 Flash 2.500. Wird die Grenze überschritten, kann die API HTTP 429 zurückgeben. Die vollständige Beschreibung zu Parallelität und Isolation ist vor der Batch-Planung zu prüfen.

Wir erfassen daher vier verschiedene Mengen:

1. geplante Teilaufgaben;
2. tatsächlich gesendete Anfragen;
3. wiederholte Anfragen nach Limitierung oder Serverfehlern;
4. erfolgreiche, akzeptierte Ergebnisse.

Die offizielle Fehlerdokumentation unterscheidet unter anderem ungültige Anfragen, fehlendes Guthaben, Rate Limits, Serverfehler und Überlastung. Ein pauschales „bei Fehler immer sofort wiederholen“ kann Kosten vervielfachen und einen Rate-Limit-Zyklus verlängern. Die Fehlercodes und empfohlenen Reaktionen gehören deshalb in die Betriebslogik.

Für jede Wiederholung brauchen wir eine Ursache:

• Netzwerkunterbrechung;
• HTTP 429;
• HTTP 500 oder 503;
• ungültiges Tool-Schema;
• unvollständige Ausgabe;
• fehlender Kontext;
• Ergebnis fachlich nicht akzeptiert;
• manuell neu gestarteter Auftrag.

Nur die ersten Ursachen eignen sich meist für automatisches Wiederholen. Bei einem fachlich falschen Ergebnis ist ein neuer Prompt oft teurer als eine gezielte Reparatur. Außerdem darf ein Tool-Fehler nicht stillschweigend eine komplette Agent-Schleife neu starten.

Die Mac-Kosten sollten wir nach der Nutzungsform berechnen, nicht nach dem Etikett „lokal“ oder „remote“.

Für den vorhandenen Mac berechnen wir mindestens:

Mac-Kosten =
Strom und Infrastruktur
+ anteilige Gerätebelegung
+ Speicher
+ Backups
+ Fernzugriff
+ Betriebszeit

Eine vorhandene Hardware ist nicht kostenlos, wenn sie während des Harness-Laufs keine Builds, Tests oder interaktiven Sitzungen ausführen kann. Diese entgangene Nutzung ist eine Opportunitätskostenposition. Wir sollten sie als interne Rate erfassen, nicht als vermeintlich exakten Marktpreis.

Bei einer kurzfristigen Umgebung zählen dagegen:

• Vorbereitungszeit;
• Einrichten von API-Schlüsseln und Umgebungsvariablen;
• Repository-Übertragung;
• Abhängigkeiten und Laufzeit;
• Log-Speicherung;
• Backup;
• kontrolliertes Herunterfahren;
• Wiederherstellung nach einem Abbruch.

MESHLAUNCH bietet hierfür unterschiedliche Mac-Zugänge und Standortoptionen an. Für eine belastbare Kalkulation verwenden wir jedoch nur die tatsächlich bestätigte Mietdauer und die gebuchte Umgebung. Nicht bestätigte Preise oder Konfigurationen gehören nicht in eine Beispielrechnung. Einen passenden Einstiegspunkt finden Sie auf der deutschsprachigen Mac-Übersicht von MESHLAUNCH.

DSGVO-relevant ist vor allem der Datenpfad. Quellcode, Zugangsdaten, Logs und generierte Artefakte müssen getrennt betrachtet werden. Prüfen Sie vor dem Lauf:

• welche Dateien an die API gesendet werden;
• ob Logs vollständige Prompts enthalten;
• wer Fernzugriff erhält;
• wie lange Artefakte gespeichert werden;
• ob Backups verschlüsselt sind;
• wie API-Schlüssel aus Umgebungsvariablen entfernt werden.

Die menschliche Arbeit wird häufig erst nach dem ersten Fehler sichtbar. Wir führen deshalb ein Wartungsprotokoll mit diesen Kategorien:

• Installation;
• Versionsprüfung;
• Upgrade und Regressionstest;
• Berechtigungsfreigabe;
• Tool- oder Schemaanpassung;
• Logprüfung;
• Ausnahmebehandlung;
• Ergebnisfreigabe;
• Wiederanlauf nach Mac- oder Netzwerkfehler.

Der Zeitwert kann intern nach Stundensatz oder nach Teamkosten angesetzt werden. Entscheidend ist, dass er nicht in einer allgemeinen „Betriebspauschale“ verschwindet.

Ein Entwickler-Preview verdient eine zusätzliche Reserve. Harness-Implementierungen können unterschiedliche Annahmen zu Tool-Aufrufen, Streaming, Thinking-Inhalten und Nachrichtenhistorie treffen. Wir übernehmen keine fremden Ressourcenwerte als offizielle DeepSeek-Harness-Zahlen. Für die eigene Umgebung messen wir CPU-Auslastung, Arbeitsspeicher, SSD-Wachstum, Prozessabstürze und Wiederanlaufzeit selbst.

1. Aufgabenvertrag festlegen

Schreiben Sie vor dem Start auf, was als erfolgreich gilt. Definieren Sie außerdem maximale Wiederholungen, Zeitüberschreitung und menschliche Übernahme.

2. Messfelder aktivieren

Speichern Sie pro API-Antwort die Tokenfelder, Modellwahl, Thinking-Einstellung und den Status. Ohne Cache-Hit- und Cache-Miss-Felder bleibt die Rechnung unvollständig.

3. Teilaufgaben und Wiederholungen zählen

Zählen Sie nicht nur ursprüngliche Jobs. Erfassen Sie auch parallele Subtasks, Tool-Aufrufe, Rate-Limit-Wiederholungen und manuell neu gesendete Anfragen.

4. Mac-Zeit protokollieren

Starten Sie die Zeitmessung beim Einrichten der Umgebung und beenden Sie sie erst nach Log-Sicherung und kontrolliertem Stoppen. Der reine Zeitraum zwischen erster und letzter API-Anfrage reicht nicht.

5. Kosten pro Ergebnis auswerten

Ersetzen Sie die Frage „Was kostet ein Tag?“ durch vier Kennzahlen:

• API-Kosten pro Aufgabe;
• Gesamtkosten pro erfolgreichem Ergebnis;
• Tagesverbrauch gegenüber dem Budget;
• Anteil der Aufgaben mit menschlicher Übernahme.

• Wenn die Aufgabe standardisiert ist, die Ausgabe kurz bleibt und die Erfolgsquote stabil ist, wählen Sie V4 Flash.
• Wenn V4 Flash häufige fachliche Wiederholungen erzeugt, testen Sie V4 Pro mit identischem Aufgabenpaket.
• Wenn der Cache-Hit-Anteil niedrig ist, stabilisieren Sie den wiederverwendbaren Präfix, bevor Sie das Modell wechseln.
• Wenn die Ausgabe regelmäßig das gesetzte Limit erreicht, kürzen Sie Kontext und Aufgabenumfang, statt nur das Limit zu erhöhen.
• Wenn HTTP 429 häufig auftritt, senken Sie die Parallelität und staffeln Sie Wiederholungen.
• Wenn der Mac überwiegend wartet, verkürzen Sie die Umgebungsdauer oder nutzen Sie einen besser passenden kurzfristigen Lauf.
• Wenn menschliche Übernahme einen wesentlichen Teil der Gesamtkosten bildet, pausieren Sie die Automatisierung und beheben Sie zuerst die Fehlerklasse.
• Wenn die Kosten pro erfolgreicher Aufgabe unter dem genehmigten Schwellenwert bleiben, erweitern Sie den Batch schrittweise.
• Wenn Tagesbudget, Fehlerrate oder Datenschutzgrenze überschritten werden, stoppen Sie automatisch und prüfen Sie den Lauf manuell.

Wir setzen absichtlich keinen scheinbar präzisen Endbetrag ein. Ein belastbarer Test besteht aus einem kleinen, realen Aufgabenpaket mit festem Modell, identischem Kontext und klarer Abnahme.

Die offiziellen Tokenpreise werden am Testtag eingetragen. Danach wird der Lauf mit den tatsächlichen Feldern erneut berechnet. Dieses Verfahren ist zuverlässiger als eine Schätzung aus erwarteten Stunden oder aus der maximalen Kontextgröße.

Für die Umgebung können Sie anschließend die passende Mac-Konfiguration für MESHLAUNCH prüfen. Wenn der Lauf nur wenige Stunden dauert und die Startvorbereitung gering bleibt, kann eine kurzfristige Umgebung sinnvoll sein. Wenn der Agent regelmäßig, planbar und mit hoher Auslastung arbeitet, vergleichen Sie die bestätigte Mietdauer mit der anteiligen Belegung eines eigenen Geräts.

Eine lokale Lösung hat drei reale Nachteile: Der Mac bleibt für andere Aufgaben blockiert, Fernzugriff und Wiederanlauf müssen selbst betrieben werden, und Speicher- sowie Backup-Pflichten bleiben im eigenen Verantwortungsbereich. Eine dauerhaft reservierte Umgebung kann dagegen bei unregelmäßigen Jobs unnötige Leerlaufkosten erzeugen. Bei kurzen Validierungen ist daher meist nicht „maximale Laufzeit“, sondern die niedrigste belegte Gesamtzeit das bessere Ziel.

MESHLAUNCH ist sinnvoll, wenn Sie für einen begrenzten Zeitraum eine kontrollierte Mac-Umgebung benötigen, ohne sofort ein Gerät dauerhaft zu binden. Die Entscheidung sollte trotzdem erst nach einem echten Testlauf fallen: Tokenverbrauch, Cache-Treffer, Fehlerwiederholungen und menschliche Eingriffe bestimmen, ob Mieten, lokales Ausführen oder eine dauerhafte Umgebung wirtschaftlich ist.

Beginnen Sie mit dem kleinsten Aufgabenpaket, das den vollständigen Ablauf abbildet. Setzen Sie ein Tageslimit, speichern Sie die Nutzungsfelder und beenden Sie den Prozess automatisch, sobald Kosten, Wiederholungen oder Übernahmerate den vereinbarten Schwellenwert überschreiten.