DeepSeek V4-Flash vs GPT-6 Sol: Welches Modell liefert brauchbare Daten für eine Aufgaben-App?

Ein deutscher API-Vergleich: gültiges JSON, richtige Zuständigkeiten, Änderungen und auffindbare Quellenstellen.

Eine Aufgaben-App muss aus „Clara übernimmt die Tabelle“ ein verlässliches Feld machen. Sie muss aber auch erkennen, dass „Ben könnte den Probelauf übernehmen“ noch keine Zuweisung ist. Welches Modell liefert dafür die brauchbareren Daten: DeepSeek V4-Flash oder GPT-6 Sol?

Ich habe zwei fiktive deutsche Notizfolgen geprüft: ein Büroprojekt und eine Lerngruppe. Beide Modelle sollten JSON liefern und anschließend neue Beschlüsse einarbeiten. Ein zusätzlicher Durchlauf verwendete genauer definierte Felder. Verglichen wurden die ausgegebenen Aufgabenfelder und ihre Belege.

📊 Ergebnis für die Aufgaben-App

Prüfung	DeepSeek V4-Flash	GPT-6 Sol
Direkt mit JSON.parse lesbar	6/6 ausgewertete Antworten	6/6 ausgewertete Antworten
Neue Beschlüsse eingearbeitet	Beide Fälle korrekt aktualisiert	Beide Fälle korrekt aktualisiert
Aufgaben-ID, Person, Termin und Status nach präziser Felddefinition	Alle 8 Aufgaben korrekt	Alle 8 Aufgaben korrekt
Quellenfeld als zusammenhängende Originalstelle auffindbar, präziser Durchlauf	3/8; übrige Stellen zusammengesetzt	8/8
⚡ Erste Antwort: Büro / Lerngruppe	4,64 / 4,06 Sekunden	7,11 / 7,21 Sekunden

Für eine App mit anklickbarem Originalbeleg würde ich in diesem Test GPT-6 Sol wählen. Für vorab geprüfte Aufgabenfelder ist DeepSeek V4-Flash ebenfalls ein Kandidat: Nach der Präzisierung waren die Werte gleich richtig, und seine Antworten kamen schneller. Die 3/8 beziehen sich auf die direkte Textsuche, nicht auf eine Faktenquote.

Mit gpt-image-2 erzeugte Konzeptillustration; keine Produktoberfläche.

Gleiche Eingabe, direkt verwendbares JSON

Der Bürofall enthielt diese vollständige Notizfolge:

Notizen, Jahr 2026:
8. Oktober: D1 Datentabelle — Anna, Abgabe 14. Oktober. D2 Folien — Ben, Abgabe 16. Oktober. D3 Live-Demo — 18. Oktober; vorführende Person nicht festgelegt.
10. Oktober, verbindliche Korrektur: D1 Datentabelle — Clara, Abgabe 16. Oktober; frühere Zuständigkeit und Frist sind ersetzt. D3 Live-Demo — 21. Oktober; vorführende Person weiterhin offen. D2 unverändert.
Ben schlägt für D4 Probelauf den 20. Oktober vor. Noch kein Beschluss, keine Person zugewiesen.

Das verlangte Format war ein Objekt mit tasks und open_questions. Jede Aufgabe erhielt id, owner, due, status und evidence. Nicht zugewiesene Personen sollten null bleiben; Vorschläge den Status proposed erhalten. Die Antwort durfte weder Markdown-Zaun noch zusätzlichen Erklärungstext enthalten. Das Format wurde per Textanweisung verlangt, nicht durch einen serverseitigen JSON-Schema-Modus erzwungen.

Beide Modelle lieferten ohne Nachbearbeitung gültiges JSON. Beide übernahmen Clara und den 16. Oktober für D1 sowie den 21. Oktober für D3. Keines machte Ben allein wegen seiner Folienarbeit zum Vorführenden. Bei D3 blieb owner: null.

Ein Unterschied steckte im Beleg für D2. DeepSeek gab zunächst nur D2 unverändert. aus. GPT zitierte D2 Folien — Ben, Abgabe 16. Oktober. Beide hatten die richtigen Feldwerte, aber nur der zweite Ausschnitt zeigt für sich genommen, woher Person und Termin stammen.

Beim Status war zunächst auch die Anweisung ungenau

Der zweite Fall beschrieb eine Lerngruppe: Mira sollte eine Literaturübersicht erstellen, Leon die Folien. Ein Vortrag am 16. November war vorgesehen, die vortragende Person aber offen. Für eine Übungssitzung gab es nur Leons bedingten Vorschlag.

DeepSeek markierte den Vortrag zunächst als proposed, GPT als confirmed. Für die nur vorgeschlagene Übungssitzung setzte DeepSeek den 15. November als due; GPT ließ das Feld leer. Im Bürofall übernahmen dagegen beide das vorgeschlagene Datum des Probelaufs.

Das ursprüngliche Schema erklärte nicht ausreichend, ob status die Durchführung oder die vollständige Personalplanung meint. Ebenso blieb offen, ob due auch Terminvorschläge enthalten darf. Diese Unterschiede sind deshalb kein sauberer Beleg für einen eindeutigen Modellfehler. Eine Anwendung muss die Bedeutung der Felder festlegen, bevor sie solche Werte bewertet.

Für einen getrennten Durchlauf bekamen beide Modelle die vollständigen ursprünglichen Notizen und dieselbe Präzisierung:

status beschreibt die Durchführung der Aufgabe, nicht den Besetzungsstand.
D3 beziehungsweise S3 ist confirmed, auch wenn owner=null.
due enthält nur verbindlich beschlossene Termine.
Bei D4 beziehungsweise S4 muss due=null bleiben,
solange der Termin nur vorgeschlagen ist.
Korrekturen innerhalb der Notizfolge ersetzen ältere Angaben.
evidence muss die Werte durch wörtliche Textstellen belegen;
ein bloßes „unverändert“ ohne die ursprünglichen Werte reicht nicht.

Danach lieferten beide Modelle für alle acht Aufgaben die erwarteten IDs, Personen, Termine und Statuswerte. Die Datums- und Statusregeln waren hier ausdrücklich vorgegeben; das Ergebnis belegt die Ausführung dieser Regeln, keine selbstständige Lösung jeder mehrdeutigen Notiz.

Was passiert, wenn jemand die Aufgabe später übernimmt?

Unabhängig von diesem präzisierten Durchlauf wurde jede ursprüngliche Unterhaltung mit einem neuen Beschluss fortgesetzt. Im Bürofall übernahm David die Demo am 21. Oktober. Der Probelauf wurde für den 19. Oktober mit Anna beschlossen.

Beide Modelle aktualisierten D3 und D4 korrekt, behielten D1 und D2 bei und leerten die offenen Fragen. Auch im Lernfall setzten beide die neue Besetzung des Vortrags und den bestätigten Termin der Übungssitzung korrekt um.

In diesen zwei Fällen gab es damit keinen Qualitätsvorsprung bei der Aktualisierung. DeepSeek war schneller: 3,37 und 3,16 Sekunden gegenüber 4,71 und 3,95 Sekunden bei GPT. Gemessen wurde jeweils die vollständige Antwort einschließlich Netzwerk, Gateway und Generierung; es gab keine Messung der menschlichen Nacharbeit.

Gleiche Aufgabenfelder, andere Möglichkeiten für Quellenbelege

Im präzisierten Durchlauf waren alle acht evidence-Felder von GPT direkt als zusammenhängende Zeichenfolge in den jeweiligen Notizen auffindbar. Bei DeepSeek galt das für drei. Es verband unter anderem Aussagen aus verschiedenen Stellen mit … oder stellte einen Datumspräfix vor einen Satz aus einem anderen Abschnitt.

Beispiel aus DeepSeeks Lernfall:

S2 Folien — Leon, Abgabe 13. November. … S2 und S3 unverändert.

Die beiden Aussagen stehen tatsächlich in der Quelle. Die gesamte Zeichenfolge einschließlich Auslassungszeichen steht dort aber nicht. Ein einfacher „Im Original anzeigen“-Button, der source.indexOf(evidence) verwendet, findet sie daher nicht.

Auswertung realer API-Antworten. Zusammengefügte Belege zählen hier nicht als durchgehend auffindbarer Ausschnitt; daraus folgt nicht, dass ihr Inhalt falsch ist.

Wo entsteht zusätzliche Arbeit?

Was die App übernehmen soll	DeepSeek V4-Flash	GPT-6 Sol
Aufgaben nach den präzisierten Regeln importieren	Die geprüften Personen-, Termin- und Statusfelder konnten unverändert übernommen werden	Dasselbe Ergebnis
Eine neue Zuweisung oder Terminänderung einarbeiten	Beide Aktualisierungen korrekt	Beide Aktualisierungen korrekt
Den ausgegebenen Beleg direkt im Original markieren	Bei fünf Belegen reicht die Suche nach der gesamten Zeichenfolge nicht; die Teilstellen müssen getrennt gesucht werden	Alle acht Belege direkt als zusammenhängende Originalstelle auffindbar

Für einen reinen Aufgabenimport ergab der präzisierte Test damit keinen Qualitätsvorsprung. Für eine Quellenansicht lieferte GPT die leichter zuzuordnenden Ausschnitte. Geprüft wurde das anhand der Antworten und der Originaltexte; eine vollständige Aufgaben-App wurde nicht betrieben.

Wie schnell kamen die Antworten?

Jede Kombination einmal gemessen. Unterschiedliche Denk-Einstellungen, keine statistische Leistungsrangliste.

🎓 Studium und 💼 Büro: welcher Vergleich hilft bei der Wahl?

Einsatz	Meine erste Wahl für diesen Ablauf	Grund
Lernprojekt mit Aufgabenplan und nachprüfbaren Originalstellen	GPT-6 Sol	Im präzisierten Lernfall richtige Felder und vier direkt auffindbare Belege
Büro-App mit Anzeige „Quelle öffnen“	GPT-6 Sol	Gleiche richtigen Aufgabenfelder, durchgehend direkt auffindbare Belege
Internes Aufgabenformular mit fester Felddefinition und manueller Quellenprüfung	DeepSeek V4-Flash als schnellere Option testen	Richtige Felder nach Präzisierung; in allen sechs ausgewerteten Aufrufen schneller

Wenn die App mehrere Quellenstellen als Liste statt als einzelne Zeichenfolge unterstützen soll, müsste dieses andere Format gesondert getestet werden. Aus den hier gefundenen zusammengesetzten Belegen lässt sich kein generelles Defizit beim Lesen deutscher Notizen ableiten.

Testbedingungen

Testdatum: 10. Oktober 2026. Die Termine im November gehören zum fiktiven Szenario. Deutsch war sowohl Eingabe- als auch Ausgabesprache. Verwendet wurden deepseek-v4-flash mit thinking: {type: 'disabled'} und gpt-6-sol mit Anbieterstandard, jeweils max_tokens: 2400, ohne Streaming oder Werkzeuge. Die Antworten nannten deepseek-v4-flash-0731 beziehungsweise gpt-6-sol; die Upstream-Zuordnung wurde nicht unabhängig bestätigt. Alle ausgewerteten Antworten endeten mit stop.

Die zwölf ausgewerteten Aufrufe umfassen je zwei Ausgangsfälle, zwei Aktualisierungen und zwei neue Durchläufe mit präzisierten Regeln pro Modell. Vier zusätzliche explorative Antworten auf eine mehrdeutige Formulierung zu „ursprünglichen Notizen“ wurden nicht in die Tabelle aufgenommen; sie vermischte Feldklärung und Auswahl des Dokumentstands. Die präzisierten Durchläufe starteten deshalb neu mit der vollständigen Quelle. Es wurden keine Wiederholungsserien zur Stabilität gemessen; höchstens vier Anfragen liefen gleichzeitig.

Die Verbindung lief über Crazyrouter. Wer dieselbe API-Anbindung einrichten möchte, findet Endpunkt und Authentifizierung in der Crazyrouter-API-Dokumentation.

Dieser Beitrag ist Crazyrouter-bezogener Inhalt und wurde mit KI-Unterstützung verfasst. Die API-Antworten wurden mit den vorgegebenen Aufgabenwerten und den Originaltexten abgeglichen.