DeepSeek V4 Pro ist seit dem 13. August 2026 allgemein in App, Web und API verfügbar. Für Unternehmen ist nicht nur das neue Modell relevant: V4 Pro und V4 Flash unterstützen jetzt die Thinking-Effort-Stufen low, high und max. Außerdem unterstützt die DeepSeek API nativ das Responses-API-Format und wird vom Anbieter als für Codex angepasst beschrieben.
Seit dem 16. August 2026 um 16:00 Uhr UTC gilt zudem ein Peak-/Off-Peak-Preismodell. Nach DeepSeek-Angaben liegen die Off-Peak-Preise bei der Hälfte der Peak-Preise. Damit lassen sich nicht nur Modelle, sondern auch Denkaufwand und Ausführungszeit als Kostenhebel steuern. Das funktioniert jedoch nur, wenn Qualität, Wartezeit und Nacharbeit gemeinsam gemessen werden.
Was offiziell bestätigt ist
DeepSeek nennt die GA-Verfügbarkeit von V4 Pro in App, Web und API. Für API-Aufrufe bleibt die Methode laut Update unverändert; das Modell wird über den Namen deepseek-v4-pro angesprochen. Low, high und max stehen für V4 Pro und V4 Flash zur Verfügung. DeepSeek ordnet low einfachen Aufgaben, high alltäglichen Agentenaufgaben und max komplexeren Szenarien zu.
Der Anbieter meldet für V4 Pro unter anderem 87,9 Punkte bei Terminal Bench 2.1, 61,5 bei NL2Repo, 83,3 bei Cybergym und 62,7 bei DeepSWE. Diese Zahlen sind bestätigte Anbieterangaben, aber keine unabhängige Prüfung für den eigenen Unternehmensprozess. Einige genannte Testsätze sind zudem intern oder stark spezialisiert. Eine Beschaffungsentscheidung sollte deshalb auf eigenen Referenzfällen beruhen.
Native Unterstützung des Responses-API-Formats kann den Integrationsaufwand reduzieren, beweist aber keine vollständige Austauschbarkeit mit jeder vorhandenen Anwendung. Parameter, Werkzeugaufrufe, Streaming, Fehlerbilder und Antwortstrukturen müssen im konkreten System geprüft werden. Gleiches gilt für die vom Anbieter beschriebene Anpassung an Codex.
Entscheidungsmatrix für low, high und max
Thinking Effort sollte nicht frei nach Nutzerpräferenz gewählt werden. Unternehmen benötigen eine Prozessregel, die Aufgabenklasse, Fehlerfolgen und akzeptable Laufzeit verbindet. Der Anbieter liefert eine grobe Einordnung; die betrieblichen Schwellenwerte müssen aus eigenen Tests entstehen.
- Low testen für klar definierte, leicht prüfbare Aufgaben mit geringem Schadenspotenzial, etwa Formatierung oder strukturierte Vorarbeiten. Ein schneller Review bleibt erforderlich.
- High als Ausgangspunkt für alltägliche Agentenaufgaben prüfen, bei denen mehrere Schritte oder Werkzeuge nötig sind, Ergebnisse aber durch feste Kriterien abgenommen werden können.
- Max nur für nachweislich komplexe Aufgaben einsetzen, wenn der zusätzliche Aufwand in eigenen Tests einen messbaren Qualitätsgewinn bringt und längere Laufzeit sowie höhere Kosten akzeptabel sind.
- Nicht automatisieren, wenn falsche Ergebnisse unmittelbar rechtliche, finanzielle, sicherheitsrelevante oder irreversible Folgen haben und keine wirksame Freigabestufe existiert.
- Dynamisch hochstufen, wenn ein Vorgang definierte Unsicherheits- oder Qualitätsgrenzen überschreitet. Eine Hochstufung darf nicht bloß eine fehlerhafte Anfrage mehrfach teurer ausführen.
Die richtige Kennzahl ist nicht der Preis eines einzelnen Aufrufs. Verglichen werden sollten die Gesamtkosten je fachlich akzeptiertem Ergebnis: Modellkosten, Wiederholungen, Laufzeit, menschliche Prüfung und Nacharbeit. Wenn max weniger Fehlversuche erzeugt, kann es trotz höherem Einzelaufwand wirtschaftlicher sein. Umgekehrt ist low nur günstiger, wenn die Erfolgsquote stabil bleibt.
Peak und Off-Peak sinnvoll in Prozesse übersetzen
Der bestätigte Off-Peak-Abschlag schafft einen klaren Anreiz für verschiebbare Arbeit. Er ist aber kein Grund, interaktive oder zeitkritische Prozesse künstlich zu verzögern. Zuerst wird die maximale Wartezeit des Geschäftsprozesses festgelegt, danach der Ausführungszeitpunkt.
- Gut verschiebbar sind vorbereitete Stapelverarbeitungen, nicht dringende Codeanalysen, Testentwürfe oder interne Aufbereitungen mit Ergebnisbedarf am folgenden Arbeitstag.
- Schlecht verschiebbar sind interaktive Assistenz, Kundenanfragen mit zugesagter Reaktionszeit, Störungsbearbeitung und Prozesse, deren Verzögerung nachgelagerte Teams blockiert.
- Getrennte Warteschlangen verhindern, dass dringende Vorgänge hinter günstigen Batch-Aufgaben warten.
- Budgets sollten pro Aufgabenklasse und Thinking-Effort-Stufe gelten, nicht nur als ein gemeinsames Monatslimit.
- Fallbacks müssen klären, ob ein Vorgang bei Überlastung wartet, auf eine andere Stufe wechselt oder kontrolliert abgebrochen wird.
Für die Kalkulation zählt der effektive Preis nach Ausführungszeit, aber auch der organisatorische Aufwand des Schedulings. Ein Off-Peak-Lauf spart nichts, wenn Ergebnisse zu spät geprüft werden, Fehler erst am nächsten Arbeitstag auffallen oder zusätzliche Bereitschaft nötig wird. Unternehmen sollten daher Preisvorteil und Prozesskosten getrennt ausweisen.
Responses API: Kompatibilität vor Migration beweisen
- Schnittstellenbestand erfassen: Dokumentieren Sie verwendete Request-Felder, Antwortformate, Streaming, Werkzeugaufrufe, Zustandsverwaltung und Fehlerbehandlung.
- Referenzfälle ausführen: Testen Sie identische Aufgaben mit erwarteten Ergebnissen und protokollieren Sie Abweichungen bei Inhalt, Tool-Aufrufen, Latenz und Abbrüchen.
- Sicherheitsgrenzen prüfen: Verifizieren Sie Berechtigungen, erlaubte Werkzeuge, Datenklassifizierung, Protokollierung und den Umgang mit unbeabsichtigten Aktionen.
- Migration begrenzen: Starten Sie mit einem reversiblen Prozess und behalten Sie den bisherigen Pfad als Fallback, bis die neue Integration ihre Grenzwerte stabil einhält.
Ein Ein-Klick-Skript oder ein bekanntes API-Format kann die technische Einrichtung vereinfachen. Es ersetzt jedoch weder die fachliche Abnahme noch Datenschutz-, Vertrags- und Sicherheitsprüfung. Besonders agentische Abläufe müssen nicht nur richtige Antworten liefern, sondern auch ausschließlich erlaubte Schritte ausführen.
Vier Phasen für einen kontrollierten Produktionspilot
- Baseline bilden: Messen Sie den heutigen Prozess mit festen Aufgaben, Qualitätskriterien, Kosten, Laufzeit, Wiederholungen und menschlicher Nacharbeit.
- Je eine Stellschraube testen: Prüfen Sie zuerst das Modell, dann Thinking Effort, anschließend Responses-Kompatibilität und zuletzt zeitliche Verlagerung. So bleiben Ursachen erkennbar.
- Grenzen festlegen: Definieren Sie Mindestqualität, maximales Budget, zulässige Laufzeit, erlaubte Werkzeuge und Abbruchbedingungen pro Aufgabenklasse.
- Gestuft freigeben: Erhöhen Sie Volumen oder Autonomie nur nach bestandenem Review. Bei wiederkehrenden Fehlaktionen, unklarer Kostenentwicklung oder sinkender Qualität wird auf die letzte stabile Stufe zurückgeschaltet.
DeepSeek V4 Pro kombiniert damit mehrere operative Hebel, die für Agentensysteme relevant sind. Der Geschäftsvorteil entsteht nicht automatisch aus GA-Status oder Benchmarkwerten. Er entsteht, wenn Aufgaben sauber klassifiziert, Effort-Stufen datenbasiert gewählt, verschiebbare Lasten kontrolliert geplant und Integrationen gegen reale Unternehmensfälle geprüft werden.