DeepSeek hat am 17. Oktober sein Modell V4.1 Flash aktualisiert und zwei separate Webwerkzeuge für API-Entwickler geöffnet. Das nun unter deepseek-flash angebotene Modell ist DeepSeek-V4.1-Flash-1017; der neue Search-Endpunkt liefert strukturierte Webergebnisse, während Fetch eine einzelne Seite als Markdown zurückgibt. Für Entwickler eines Agenten, der aktuelle Informationen benötigt, ändert die Veröffentlichung sowohl das über einen bestehenden API-Namen verfügbare Modell als auch die Informationsquellen, die eine Anwendung aufrufen kann. Laut DeepSeek schneidet das Modell auch in Benchmarks für Programmieragenten besser ab, doch diese Zahlen stammen aus eigenen Auswertungen.

Die große Veränderung

  • Was sich geändert hat: DeepSeek hat das Modell hinter deepseek-flash ersetzt, ohne den API-Namen oder seine Tokenpreise zu ändern. Außerdem hat es Search und Fetch als eigenständige JSON-APIs verfügbar gemacht.
  • Warum das wichtig ist: Eine Anwendung kann Suchergebnisse anfordern, eine ausgewählte Seite abrufen und dieses Material in den eigenen Arbeitsablauf einspeisen. Die dokumentierten Schnittstellen machen Schritte und Anfragegebühren sichtbar. Sie belegen weder die Richtigkeit jeder abgerufenen Seite noch eine bessere Leistung des neuen Modells in der Umgebung eines bestimmten Nutzers.
  • Worauf zu achten ist: Unabhängige Durchläufe des neuen Modells mit offengelegten Agenteneinstellungen würden DeepSeeks Leistungsbehauptungen prüfen. Entwickler, die Search oder Fetch nutzen, müssen auch die Anfrageabrechnung, Ratenlimits und den Umgang ihrer Anwendungen mit möglicherweise nicht verfügbaren oder unzuverlässigen Seiteninhalten verfolgen.

Ein Modellname, eine neue Version

DeepSeeks Änderungsprotokoll vom 17. Oktober zufolge ist das aktualisierte Flash-Modell auf Website, App und API verfügbar. Bestehende API-Aufrufe mit deepseek-flash greifen auf V4.1-Flash-1017 zu. Nach Angaben des Unternehmens bleiben Aufrufmethode und Modellpreise unverändert. Seine aktuelle Preistabelle nennt eine Kontextlänge von einer Million Token sowie Unterstützung für Denk- und Nichtdenkmodus, Werkzeugaufrufe und Bildverarbeitung. Die Preise zu Spitzenzeiten liegen bei $0.30 je Million nicht zwischengespeicherter Eingabetoken und $1.20 je Million Ausgabetoken; außerhalb der Spitzenzeiten betragen sie die Hälfte. Zwischengespeicherte Eingaben haben einen separaten niedrigeren Tarif. Dies sind Gebühren für das gehostete Modell, getrennt von Search- und Fetch-Anfragen.

DeepSeek hat außerdem die aktualisierten Modellgewichte veröffentlicht, und zwar unter einer MIT-Lizenz. Damit können Teams eine eigene Bereitstellung prüfen, müssen jedoch die erheblichen Rechen- und Einrichtungsanforderungen des gewählten Inferenzsystems berücksichtigen. BIG CHANGE hat die Gewichte weder installiert noch den Ressourcenbedarf gemessen. In seinem Veröffentlichungsbeitrag empfiehlt das Unternehmen DeepSeek Harness v0.2.1-rc.1 oder neuer für das aktuelle Modell. Diese Empfehlung gilt für das Harness, nicht als API-Versionsvorgabe.

Die Leistungszahlen haben einen engeren Aussagebereich als ein allgemeines Leistungsversprechen für Programmieraufgaben. DeepSeek meldet für das neue Modell einen DeepSWE-v1.1-Wert von 77.0 gegenüber 74.2 für das vorherige V4.1 Flash sowie einen Terminal-Bench-4.0-Wert von 42.3 gegenüber 31.2. Laut Änderungsprotokoll kam beim Terminal-Bench-Durchlauf Claude Code und beim DeepSWE-Durchlauf Mini-SWE-V2 zum Einsatz. Diese Agentenumgebungen beeinflussen, was ein Benchmark misst. Das Unternehmen berichtet auch von kürzeren Aufgabenlaufzeiten und Ausgaben, doch BIG CHANGE hat die Tests weder reproduziert noch eine Verbesserung der Kosten pro Aufgabe bestätigt. Keines dieser Ergebnisse belegt, wie sich das Modell in einem unbeaufsichtigten Produktionsablauf verhalten wird.

Suchergebnisse und abgerufene Seiten sind getrennte Aufrufe

Die Anleitung zu Search und Fetch dokumentiert zwei POST-Endpunkte: /v1/tools/search nimmt eine Suchanfrage entgegen und liefert ein results-Array zurück, während /v1/tools/fetch eine URL annimmt und einen Titel sowie den Seiteninhalt als Markdown zurückgibt. Beide erfordern einen DeepSeek-API-Schlüssel in einem Bearer-Header. Search kann 1 bis 50 Ergebnisse anfordern und optional Seiteninhalte einschließen. Ohne diese Option ist das Feld content leer. Die Ergebnisse umfassen URL, Titel, Textauszug, Zusammenfassung und Metadaten wie ein Datum, sofern verfügbar. Diese Felder werden vom Suchdienst geliefert und sind keine unabhängige Prüfung der Aussagen oder des Veröffentlichungszeitpunkts einer Seite.

Für eine Anwendung, die eine aktuelle Quelle benötigt, besteht der dokumentierte Weg darin, nach möglichen Seiten zu suchen und eine ausgewählte URL abzurufen, wenn deren Inhalt benötigt wird. Die Anwendung muss weiterhin entscheiden, was sie dem Modell übergibt und wie sie die Antwort mit der Quelle abgleicht. Die Anleitung sagt nicht, dass ein einfacher deepseek-flash-API-Aufruf automatisch beide Anfragen ausführt. DeepSeek zufolge rufen serverseitige Werkzeuge in DeepSeek Harness, Claude Code und Codex die Dienste bei Nutzung mit seiner API bereits auf; eine eigenständige Integration bleibt eine separate Entscheidung. Diese Unterscheidung ist für die Einschätzung von Verhalten und Kosten wichtig.

DeepSeek berechnet $0.75 je 1.000 erfolgreiche Search-Anfragen und denselben Betrag je 1.000 erfolgreiche Fetch-Anfragen. Nach der veröffentlichten Regel muss eine Suche ein nicht leeres Ergebnisarray beziehungsweise ein Abruf Seiteninhalte zurückgeben, damit eine Anfrage berechnet wird. Laut Unternehmen sind serverseitige Search- und Fetch-Aufrufe über die genannten Agentenwerkzeuge für DeepSeek-API-Nutzer kostenlos, bis die Abrechnung am 1. November 2026 um 00:00 Uhr Pekinger Zeit beginnt (31. Oktober, 16:00 UTC). Die Tokengebühren des Modells gelten weiterhin. Für Search und Fetch gilt jeweils ein kontoweites Limit von fünf Anfragen pro Sekunde; Fetch hat zusätzlich ein Limit pro Domain.

Der Fetch-Endpunkt hängt von der Verfügbarkeit und den Zugriffsregeln der Zielwebsite ab. DeepSeeks Anleitung nennt unter anderem Ablehnung aufgrund von Richtlinien, blockierte oder nicht unterstützte Seiten, fehlende extrahierbare Inhalte und Ratenbegrenzung als mögliche Fehler. Eine Anwendung, die das zurückgegebene Markdown verwendet, sollte es als zu prüfendes Quellenmaterial behandeln, nicht als zu befolgende Anweisung. Das ist eine vom Entwickler festzulegende Grenze im Arbeitsablauf und keine Zuverlässigkeitsgarantie der API.

Quellen und weiterführende Lektüre