DeepSeek V4.1 Flash API Tutorial: Baue einen visuellen Bugfixing-Agenten

Was ist DeepSeek V4.1 Flash?

DeepSeek bietet V4.1 Flash in der API unter der Modell-ID deepseek-flash an. Es akzeptiert Bildeingaben, unterstützt Denk- und Nicht-Denkmodi, hat ein Kontextfenster von 1 Mio. Tokens und kann bis zu 384K Tokens über Chat Completions und die Responses API zurückgeben.

Unser Überblick zu DeepSeek V4.1 Flash behandelt Launch, Architektur und Benchmarks. 

Wie funktioniert DeepSeek V4.1 Flash?

DeepSeek beschreibt V4.1 Flash als 552B-Parameter-MoE-Backbone, während Hugging Face 763B Parameter für den veröffentlichten Checkpoint meldet. Die Differenz liegt größtenteils am 196B-Parameter-Engram-Conditional-Memory plus Vision-Encoder und -Projektor – Komponenten, die im Checkpoint enthalten sind, aber außerhalb des MoE-Backbones liegen.

Das Causal-Encoder-Decoder-Design nutzt gecachte Encoderzustände wieder, mit 8B aktiven Parametern pro Token während der Eingabeverarbeitung und 16B während der Ausgabe.

Was ist neu in DeepSeek V4.1 Flash?

V4.1 Flash ist das erste Modell der neuen V4.1-Architekturfamilie mit nativ integrierter Bildverständnisfähigkeit. Visuelle und Text-Embeddings werden von Beginn des Pre-Trainings gemeinsam trainiert, statt – wie beim experimentellen V4-Flash-Vision-Exp – nachträglich ergänzt zu werden.

Die Responses API stammt aus der Zeit vor V4.1 Flash; DeepSeek hat während des früheren V4-Rollouts native Unterstützung hinzugefügt. Die eingestellten Modellnamen deepseek-v4-flash und deepseek-v4-flash-vision-exp leiten nun auf V4.1 Flash um.

Was kostet DeepSeek V4.1 Flash?

DeepSeeks Preise richten sich nach Peak-Zeiten, mit Off-Peak-Tarifen zu 50% der Peak-Preise. Als ich den Agenten laufen ließ, kosteten gecachte Eingaben $0,003 pro Million Tokens Off-Peak und $0,006 Peak, nicht gecachte Eingaben $0,15 Off-Peak und $0,30 Peak, und Ausgaben $0,60 Off-Peak und $1,20 Peak – jeweils laut Preisseite von DeepSeek. 

Peak-Zeiten sind Montag bis Freitag 01:00–04:00 und 06:00–10:00 UTC, ausgenommen chinesische Feiertage. Alle anderen Stunden sind Off-Peak, chinesische Feiertage sind vollständig Off-Peak.

Was wir bauen: Der Launch-Metrics-Visual-Repair-Agent

Nimbus Analytics Launch Metrics ist ein Flask-Dashboard für Gesamtbesucher, Sign-ups, Conversion-Rate, Umsatz und tägliche Sign-ups. Ich habe drei Bugs über drei Dateien verteilt und dem Agenten nicht verraten, welche. Code und defektes Dashboard findest du in diesem GitHub-Repository.

Defektes Dashboard neben dem Referenzdesign. Bild: Autor.

Die drei Bugs benötigen unterschiedliche Belege. Einer ist im Screenshot sichtbar, einer beeinflusst das Browserverhalten, und einer fällt in pytest durch. Der Agent erhält keine Bugliste.

Bevor ich das dem Agenten übergebe, definiere ich, was „fixed“ bedeutet: Die pytest-Suite muss bestehen und ein frischer Screenshot muss visuell mit einer Referenz übereinstimmen. Die Meinung des Modells allein reicht nicht – der Runner prüft beide Nachweise.

So funktioniert der Reparaturloop

Der Loop wechselt zwischen einem Modellaufruf und der Ausführung lokaler Tools. V4.1 Flash liefert Reasoning, eine Nachricht oder Tool-Calls; Python führt die angeforderten Tools aus und hängt die Ergebnisse an die Historie. Der Loop endet, wenn das Modell ohne weiteren Tool-Call antwortet oder das Limit von vierzehn Turns erreicht ist.

Reparaturloop zwischen Modell, Tools und Browser. Bild: Autor.

DeepSeek V4.1 Flash API einrichten

Du brauchst Python 3.10 oder neuer und einen DeepSeek-API-Schlüssel mit Guthaben. DeepSeeks API folgt dem OpenAI-Anfrageformat, daher nutzt dieses Projekt das openai Python-Paket mit base_url auf DeepSeek gesetzt.

Erstelle eine virtuelle Umgebung und installiere, was das Projekt benötigt.

python3 -m venv .venv
source .venv/bin/activate
pip install openai flask playwright pytest python-dotenv requests streamlit
playwright install chromium

Getestet mit openai 3.14.1, flask 3.1.3 und playwright 1.63.0. Speichere den Schlüssel in einer .env-Datei im Projektroot als DEEPSEEK_API_KEY=sk-... und lade ihn mit python-dotenv. Wenn dein Schlüssel bereits mit der Responses API funktioniert, überspringe den nächsten Codeblock; andernfalls prüft die Anfrage Schlüssel und Base-URL.

from openai import OpenAI
import os
from dotenv import load_dotenv

load_dotenv()
client = OpenAI(api_key=os.environ["DEEPSEEK_API_KEY"], base_url="https://api.deepseek.com")

response = client.responses.create(model="deepseek-flash", input="Say hi in five words.")
print(response.output_text)

Wenn das einen kurzen Gruß ausgibt, funktionieren Schlüssel und Base-URL.

Schritt 1: Zeig dem Modell, wie „fixed“ aussieht

Die erste Eingabe des Agenten enthält einen Referenz-Screenshot, eine kurze Aufgabe und die Live-URL. Das ist das einzige Bild, das in einer User-Message gesendet wird. Alle späteren Screenshots kommen aus einem Tool.

Der Runner sendet das Referenzbild bei jeder Anfrage als Base64-Data-URL. DeepSeek empfiehlt die Files API, wenn ein Bild wiederverwendet wird. Eine file_id vermeidet das wiederholte Senden derselben Bilddaten.

Erste Reaktion einholen, bevor Änderungen erlaubt sind

Im angehängten Bild habe ich gefragt, was das Modell zuerst prüfen würde – aber es gab noch keine Tools. So konnte ich den Plan ansehen, bevor irgendetwas geändert wurde. Die Antwort schlug vor, die Projektdateien aufzulisten, CSS-Variablen nachzuverfolgen und einen Screenshot zu machen; ich nutzte reasoning: {"effort": "high"}, DeepSeeks Standard-Denkstufe.

Schritt 2: Gib dem Agenten nutzbare Tools

Der Agent erhält vier Function-Tools und ein benutzerdefiniertes Tool. 

• list_files und read_file inspizieren das Projekt, beide beschränkt auf dashboard/ und tests/. 

• run_tests führt pytest aus.

• capture_dashboard_screenshot startet headless Chromium über Playwright.

Das Custom-Tool ist apply_patch, deklariert als {"type": "custom", "name": "apply_patch"} und „for Codex compatibility“ akzeptiert. Jeder andere Custom-Tool-Name liefert einen 400-Fehler, während eingebaute Typen wie Websuche und Computersteuerung still ignoriert werden.

Funktionsargumente kommen als JSON-Text und werden geprüft, bevor Python sie ausführt. apply_patch kommt als Custom-Tool-Eingabe, daher behandelt der Code es separat und prüft den Patch, bevor Dateien geschrieben werden. Toolfehler gehen zurück ans Modell, statt den Loop zu stoppen.

Playwright-Screenshots als Tool-Ausgabe zurücksenden

Wenn capture_dashboard_screenshot läuft, wird das Ergebnis nicht auf der Festplatte gespeichert. Python gibt es als input_image-Teil innerhalb von function_call_output zurück. DeepSeek liest den Screenshot dann als Bild statt als Textbeschreibung.

history.append({
    "type": "function_call_output",
    "call_id": item.call_id,
    "output": [{"type": "input_image", "image_url": f"data:image/png;base64,{png_b64}"}],
})

Der Agent kann das CSS patchen, einen weiteren Screenshot machen und prüfen, ob die Zahlen lesbar sind.

Schritt 3: Baue den Agenten-Loop und verwalte die Historie selbst

Die Historie lebt in einer Python-Liste, weil die API weder previous_response_id noch serverseitige Konversationen unterstützt. Der Denkmodus erfordert außerdem alle Reasoning-Items aus früheren Tool-Turns.

Wichtig: Wenn die Toolausgabe zwischen zwei Calls desselben Turns eingefügt wird, liefert die nächste Anfrage einen 400-Fehler. Hänge jedes Item aus response.output der Reihe nach an, führe dann die Tools aus und hänge deren Ergebnisse an.

Der Runner begrenzt den Agenten auf vierzehn Turns und die Verzeichnisse dashboard/ und tests/. Es gibt keinen Shell-Zugriff, Toolargumente werden geprüft, und pytest dient der Verifikation.

Unterstützt DeepSeek V4.1 Flash strukturierten Output?

Ja. Über die Responses API akzeptiert DeepSeek V4.1 Flash ein JSON Schema via text.format. Die Chat Completions- response_format unterstützt JSON-Mode, aber keine Schemas. Nach dem Stopp des Loops zeichnet die Abschlussanfrage Bugs, Fixes, Testergebnisse, Screenshot-Ergebnisse und die Verifikationsmethode auf.

Das Projekt enthält außerdem eine Streamlit-App in app_streamlit.py. Derselbe Agent läuft als Generator mit stream=True, sodass die Seite Reasoning-Text und Tool-Calls in Echtzeit zeigt. In der Sidebar kannst du Denkaufwand und Bilddetail anpassen.

Streamlit-UI streamt den Agentenlauf. Video: Autor.

Schritt 4: Starte den visuellen Bugfixing-Agenten

Nach einem Patch sah der Lauf fertig aus – aber die Live-Seite war anderer Meinung.

Bugs finden und beheben

Der Agent schaute in den ersten zwei Turns, bevor er etwas anfasste: Turn eins listete die Dateien auf und erstellte einen Baseline-Screenshot, Turn zwei las app.py, index.html, style.css und die Testdatei.

Turn drei startete pytest, dann brachte Turn vier einen Patch, der die Conversion-Formel korrigierte, die Metrikfarbe änderte und das JavaScript-Lookup an die Canvas-ID anpasste.

-    conversion_rate = data["conversions"] / data["signups"] * 100
+    conversion_rate = data["conversions"] / data["total_visitors"] * 100

Die Tests in Turn fünf zeigten: alle fünf bestanden. Hier wurde der Lauf unordentlich. Jeder neue Screenshot zeigte weiterhin 15% Conversion-Rate und ein leeres Chart.

Systemstau erkennen und beheben

Der Agent bestätigte, dass die Dateien auf der Platte die Fixes enthielten, versuchte den Screenshot erneut und prüfte, ob der Server die geänderten Python- und Template-Dateien lud. Zwei temporäre Freshness-Checks tauchten ebenfalls nicht auf der Live-Seite auf.

Bis Turn vierzehn hatte der Loop sein Budget erreicht und die Ursache identifiziert: run_tests prüft Code auf der Platte, während der Screenshot einen laufenden Prozess mit veraltetem Zustand prüft. Flask startete mit debug=False, also lud kein Reloader das geänderte Python-Modul, und Template-Autoreload war nicht aktiv.

Die CSS-Änderung war sichtbar, während der Python-abgeleitete Wert und das Template-gestützte Chart veraltet blieben. Pytest importierte app.py von der Platte, also garantierten grüne Tests keine frische Seite.

Nachdem ich Flask neu gestartet hatte, entsprach das Dashboard der Referenz. Das fehlende Puzzleteil war ein restart_server-Tool, nicht ein weiterer Code-Patch.

Neustart macht die gepatchten Dashboard-Änderungen sichtbar. Bild: Autor.

Hat der Agent das Dashboard gefixt?

Ja, der Agent hat das Dashboard auf der Platte repariert. Er änderte nur die drei fehlerhaften Dateien, und pytest wechselte von vier Fehlern zu fünf bestandenen Tests. Nach dem Flask-Neustart zeigte auch die Live-Seite alle Fixes.

Schritt 5: Nutzung, Caching und Kosten messen

Weil der Agent seine Historie erneut sendet, wiederholen spätere Anfragen viel Eingabe aus früheren Turns. DeepSeek vergleicht dieses wiederholte Präfix mit seinem automatischen Cache. Der Cache arbeitet nach Best-Effort, daher gelten diese Zahlen nur für diesen Lauf.

Über vierzehn Reparatur-Turns plus die abschließende JSON-Report-Anfrage meldete die API 156.724 Eingabetokens, davon 137.088 gecacht – 87% Trefferquote. Der Output lag bei 11.497 Tokens, davon 9.362 Reasoning-Tokens. Der Lauf fiel in Off-Peak-Stunden, daher kosteten alle fünfzehn Requests zusammen nur etwa $0,0103.

Reasoning-Output ist die größte Kostenkategorie. Bild: Autor.

Eine größere Codebasis, mehr Screenshots oder weniger Cache-Treffer würden Tokenanzahl und Kosten verändern.

Wichtige Grenzen der DeepSeek V4.1 Flash API

Drei API-Grenzen sind relevant, bevor dieser Runner über die Demo hinauswächst.

• Hintergrundantworten werden nicht unterstützt, lange Turns blockieren bis zum Abschluss.

• parallel_tool_calls und max_tool_calls werden ignoriert; parallele Tool-Calls bleiben aktiviert.

• Automatisches Truncating wird nicht unterstützt, Anfragen über dem Kontextlimit liefern einen 400-Fehler.

Checkliste für den Einsatz von DeepSeek V4.1 Flash-Agenten

Bevor du dieses Muster in einem Live-Service nutzt, verankere die Kontrollen im Anwendungscode statt in Modellinstruktionen.

• Turn- und Kostenlimits durchsetzen und bei Erreichen benachrichtigen
• Dateizugriff beschränken und jedes Toolargument prüfen
• Tools zum Neustarten und Prüfen des Dienstes bereitstellen, damit die Verifikation mit dem aktuellen Code arbeitet
• Tokenverbrauch, Tool-Calls, Testergebnisse und Endstatus protokollieren

Wann apply_patch statt einzelner Function-Tools verwenden?

Nutze apply_patch, wenn eine Änderung mehrere Dateien gleichzeitig aktualisieren muss – so wie hier. Führe nach dem Patch Tests aus, denn ein fehlerhafter Call kann mehrere Dateien beschädigen.

Nutze read_file und write_file wenn jeder Edit einen separaten Check oder ein Approval braucht. Das kostet mehr Turns, aber ein schlechter Edit betrifft jeweils nur eine Datei.

Abschließende Gedanken

Der visuelle Reparaturloop hat alle drei Bugs mit einem Patch gefixt, aber der Lauf war kein sauberer Erfolg. Pytest bestand, während Flask noch den alten Python- und Template-Output auslieferte, sodass der Agent die finale Seite erst nach meinem Serverneustart bestätigen konnte.

Ich würde vor einer größeren App ein restart_server -Tool und einen Pixelvergleich ergänzen. Die Dateigrenzen und das Turn-Limit würde ich beibehalten und pytest sowie den Screenshot-Vergleich als getrennte Checks behandeln. Besteht das eine, darf es nie für das andere stehen.