Drei Regeln, bevor man die Tabelle liest

1. Benchmark-Familien messen unterschiedliche Fähigkeiten. Terminal‑Bench testet andere Dinge als SWE‑Bench, BrowseComp, OSWorld, GPQA oder HLE. Ein starkes Coding-Modell ist nicht automatisch das beste Web-Recherche-, Long-Context- oder Computer-Use-Modell.
2. Tools und Inferenzaufwand verändern Ergebnisse. Die OpenAI-Systemkarte beschreibt GPT‑5.5 Pro als dieselbe zugrunde liegende Modellbasis mit einer Einstellung, die parallelen Test-Time-Compute nutzt. GPT‑5.5 und GPT‑5.5 Pro sollten daher nicht als Ergebnisse mit identischem Rechenbudget gelesen werden.
3. Öffentliche Benchmarks sind Shortlist-Hilfen, keine Beschaffungsentscheidung. Weil unabhängige Runs von Herstellerangaben abweichen können, braucht jede ernsthafte Produktentscheidung interne Tests mit den eigenen Aufgaben, Tools, Timeouts und Kostenlimits.

Die Modelle auf einen Blick

Head-to-Head: die wichtigsten Benchmarks

Welches Modell für welchen Einsatz?

1. Terminal-lastige autonome Coding-Agenten: GPT‑5.5

Wenn Ihr Workload aus Terminal-Aktionen, Browser-Nutzung, OS-Level-Aufgaben, Tool-Orchestrierung und mehrstufigen Agenten-Loops besteht, wirkt GPT‑5.5 in diesem Datensatz am stärksten. OpenAI meldet 82,7 % auf Terminal‑Bench 2.0, 78,7 % auf OSWorld‑Verified, 84,4 % auf BrowseComp und 55,6 % auf Toolathlon.

Der hohe BrowseComp-Wert von GPT‑5.5 Pro mit 90,1 % ist interessant, sollte aber nicht wie ein regulärer GPT‑5.5-Wert gelesen werden: Laut OpenAI-Systemkarte nutzt GPT‑5.5 Pro dieselbe Modellbasis mit parallelem Test-Time-Compute.

Passt besonders zu: Coding-Agenten, Browser-Recherche-Agenten, Computer-Use-Automatisierung und Tool-lastigen Enterprise-Assistenten.

2. Produktive Codebase-Reparatur: Claude Opus 4.7

Wenn der wichtigste KPI lautet, echte Repository-Probleme zu lösen, Pull Requests vorzubereiten, Tests zum Laufen zu bringen und große Codebasen zu verstehen, gehört Claude Opus 4.7 ganz nach oben auf die Shortlist. Die gemeldeten 87,6 % auf SWE‑Bench Verified und 64,3 % auf SWE‑Bench Pro sind in diesem Vergleich das stärkste Coding-Signal.

Anthropic beschreibt Claude Opus 4.7 zudem als Hybrid-Reasoning-Modell für Coding und KI-Agenten mit 1-Million-Token-Kontextfenster. Das macht es besonders naheliegend, es in Large-Codebase-Workflows zu testen.

Passt besonders zu: Repository-Wartung, Code Reviews, komplexen Refactorings, Developer-Copilots und Engineering-Agenten.

3. Open-Weights-Coding-Stack: Kimi K2.6

Wenn Open Weights, mehr Hosting-Kontrolle oder ein selbst verwaltbarer Coding-Stack wichtig sind, ist Kimi K2.6 einer der stärksten Kandidaten. Die offiziellen Kimi-Angaben nennen 66,7 % auf Terminal‑Bench 2.0, 58,6 % auf SWE‑Bench Pro, 80,2 % auf SWE‑Bench Verified, 52,2 % auf SciCode und 89,6 auf LiveCodeBench v6.

Auch für agentische Such- und Recherche-Workloads sieht Kimi gut aus: In den öffentlichen Materialien stehen 83,2 % auf BrowseComp und 86,3 % für Agent Swarm BrowseComp. Artificial Analysis nennt außerdem native Bild- und Videoeingabe sowie 256k maximale Kontextlänge.

Passt besonders zu: Open-Model-Deployments, Coding-Agenten, Recherche-Agenten und Teams, die Hosting und Modellbetrieb stärker kontrollieren wollen.

4. Long-Context- und Open-Source-Experimente: DeepSeek V4

DeepSeek bezeichnete V4 Preview am 24. April 2026 als offiziell live und open-sourced. Die DeepSeek-V4-Pro-Modellkarte stellt die V4-Serie als Mixture-of-Experts-Sprachmodelle dar.

Für DeepSeek V4-Pro/Pro-Max werden unter anderem 67,9 auf Terminal Bench 2.0, 80,6 auf SWE Verified, 55,4 auf SWE Pro und 90,1 auf GPQA Diamond gemeldet. Das macht DeepSeek V4 zu einem strategischen Kandidaten für Open-Source/Open-Weights-Tests und Long-Context-Anwendungen — aber nur, wenn die genaue Variante sauber getrennt bewertet wird.

Passt besonders zu: Long-Context-Anwendungen, Open-Source/Open-Weights-Experimenten und Teams, die gehostete Frontier-Modelle mit deploybaren Alternativen vergleichen.

5. Wissenschaft und Mathematik: Claude führt bei GPQA, aber nicht überall

Bei den verfügbaren gemeldeten Werten kommt Claude Opus 4.7 auf 94,2 % bei GPQA Diamond. Kimi K2.6 meldet 90,5 % bei GPQA-Diamond und 96,4 % bei AIME 2026. DeepSeek V4-Pro/Pro-Max meldet 90,1 bei GPQA Diamond.

Das macht Claude für Science-Reasoning sehr stark. Trotzdem sollte man bei Mathematik- und Wissenschafts-Workloads nicht auf einen einzelnen Benchmark setzen: Tool-Zugriff, Effort-Modus und Evaluationssetup können die Rangfolge verändern.

Praktische Evaluations-Checkliste

• Nicht nach einem einzigen Leaderboard entscheiden. Nutzen Sie öffentliche Benchmarks als Vorauswahl, aber testen Sie intern mit denselben Prompts, Tools, Timeouts, Kostenlimits und Bewertungskriterien.
• GPT‑5.5 und GPT‑5.5 Pro getrennt erfassen. Pro nutzt parallelen Test-Time-Compute; reguläre und Pro-Ergebnisse sind daher nicht automatisch dasselbe Rechenbudget.
• Open-Weights-Anforderungen vorab definieren. Wenn Datenkontrolle, eigenes Hosting oder Anpassbarkeit zwingend sind, sollten Kimi K2.6 und DeepSeek V4 in einer separaten Evaluationsspur laufen.
• Long Context nicht nur an der Fenstergröße messen. Claude Opus 4.7 ist mit 1-Million-Token-Kontextfenster klar positioniert, Kimi K2.6 mit 256k maximaler Kontextlänge; DeepSeek-V4-Materialien setzen ebenfalls auf Long-Context-Positionierung. Entscheidend sind aber Recall, Instruktionsbefolgung und Kosten auf Ihren eigenen Dokumenten.
• Coding-Agenten zusätzlich auf echten Repos testen. SWE‑Bench-Scores sind nützlich, aber Produktions-Repositories bringen eigene Abhängigkeiten, flaky Tests, Coding-Styles und Review-Regeln mit.

Grenzen dieser Einordnung

• In den vorliegenden öffentlichen Quellen gibt es keinen vollständigen Vergleich, der alle vier Modelle in derselben unabhängigen Umgebung, mit identischem Harness, identischem Tool-Zugriff und gleicher Effort-Einstellung testet; LM Council warnt zudem vor Abweichungen zwischen unabhängigen und selbst gemeldeten Benchmarks.
• GPT‑5.5 Pro und GPT‑5.5 sollten nicht gleichgesetzt werden, weil OpenAI GPT‑5.5 Pro als dieselbe Modellbasis mit parallelem Test-Time-Compute beschreibt.
• DeepSeek-V4-Scores sind variantenspezifisch. V4 Preview, V4-Pro und Pro-Max-artige Ergebnisse sollten nicht zu einem einzigen DeepSeek-V4-Wert vermischt werden.
• Bei Open-Weights-Deployments wie Kimi K2.6 und DeepSeek V4 können Serving-Stack, Hardware, Quantisierung und Kontext-Settings die reale Leistung beeinflussen; veröffentlichte Benchmarks ersetzen daher keine Deployment-Evaluation.

Bottom Line

GPT‑5.5 gehört nach oben auf die Shortlist, wenn Agentic Computer-Use, Browsing, Tool-Orchestrierung und terminal-lastiges Coding im Mittelpunkt stehen.

Claude Opus 4.7 ist die stärkste Wahl für die erste Testphase, wenn der Produktwert vor allem in Repo-Level-Bugfixing, Codebase-Reparatur und SWE‑Bench-artigem Software Engineering liegt.

Kimi K2.6 ist besonders interessant, wenn ein Open-Weights-Coding-Modell mit starken SWE‑Bench-, Terminal‑Bench- und agentischen Search-Signalen gebraucht wird.

DeepSeek V4-Pro/Pro-Max sollte auf die Liste, wenn Long-Context-Experimente, Open-Source/Open-Weights-Deployability und Variantenvergleich zentrale Kriterien sind.

Die robusteste Entscheidung entsteht nicht aus einer einzelnen Zahl, sondern aus einer Kombination: öffentliche Benchmarks für die Shortlist, danach interne Tests mit realen Aufgaben, Kosten-, Latenz-, Datenschutz- und Failure-Mode-Prüfung.

Drei Regeln, bevor man die Tabelle liest

1. Benchmark-Familien messen unterschiedliche Fähigkeiten. Terminal‑Bench testet andere Dinge als SWE‑Bench, BrowseComp, OSWorld, GPQA oder HLE. Ein starkes Coding-Modell ist nicht automatisch das beste Web-Recherche-, Long-Context- oder Computer-Use-Modell.
2. Tools und Inferenzaufwand verändern Ergebnisse. Die OpenAI-Systemkarte beschreibt GPT‑5.5 Pro als dieselbe zugrunde liegende Modellbasis mit einer Einstellung, die parallelen Test-Time-Compute nutzt. GPT‑5.5 und GPT‑5.5 Pro sollten daher nicht als Ergebnisse mit identischem Rechenbudget gelesen werden.
3. Öffentliche Benchmarks sind Shortlist-Hilfen, keine Beschaffungsentscheidung. Weil unabhängige Runs von Herstellerangaben abweichen können, braucht jede ernsthafte Produktentscheidung interne Tests mit den eigenen Aufgaben, Tools, Timeouts und Kostenlimits.

Die Modelle auf einen Blick

Head-to-Head: die wichtigsten Benchmarks

Welches Modell für welchen Einsatz?

1. Terminal-lastige autonome Coding-Agenten: GPT‑5.5

Wenn Ihr Workload aus Terminal-Aktionen, Browser-Nutzung, OS-Level-Aufgaben, Tool-Orchestrierung und mehrstufigen Agenten-Loops besteht, wirkt GPT‑5.5 in diesem Datensatz am stärksten. OpenAI meldet 82,7 % auf Terminal‑Bench 2.0, 78,7 % auf OSWorld‑Verified, 84,4 % auf BrowseComp und 55,6 % auf Toolathlon.

Der hohe BrowseComp-Wert von GPT‑5.5 Pro mit 90,1 % ist interessant, sollte aber nicht wie ein regulärer GPT‑5.5-Wert gelesen werden: Laut OpenAI-Systemkarte nutzt GPT‑5.5 Pro dieselbe Modellbasis mit parallelem Test-Time-Compute.

Passt besonders zu: Coding-Agenten, Browser-Recherche-Agenten, Computer-Use-Automatisierung und Tool-lastigen Enterprise-Assistenten.

2. Produktive Codebase-Reparatur: Claude Opus 4.7

Wenn der wichtigste KPI lautet, echte Repository-Probleme zu lösen, Pull Requests vorzubereiten, Tests zum Laufen zu bringen und große Codebasen zu verstehen, gehört Claude Opus 4.7 ganz nach oben auf die Shortlist. Die gemeldeten 87,6 % auf SWE‑Bench Verified und 64,3 % auf SWE‑Bench Pro sind in diesem Vergleich das stärkste Coding-Signal.

Anthropic beschreibt Claude Opus 4.7 zudem als Hybrid-Reasoning-Modell für Coding und KI-Agenten mit 1-Million-Token-Kontextfenster. Das macht es besonders naheliegend, es in Large-Codebase-Workflows zu testen.

Passt besonders zu: Repository-Wartung, Code Reviews, komplexen Refactorings, Developer-Copilots und Engineering-Agenten.

3. Open-Weights-Coding-Stack: Kimi K2.6

Wenn Open Weights, mehr Hosting-Kontrolle oder ein selbst verwaltbarer Coding-Stack wichtig sind, ist Kimi K2.6 einer der stärksten Kandidaten. Die offiziellen Kimi-Angaben nennen 66,7 % auf Terminal‑Bench 2.0, 58,6 % auf SWE‑Bench Pro, 80,2 % auf SWE‑Bench Verified, 52,2 % auf SciCode und 89,6 auf LiveCodeBench v6.

Auch für agentische Such- und Recherche-Workloads sieht Kimi gut aus: In den öffentlichen Materialien stehen 83,2 % auf BrowseComp und 86,3 % für Agent Swarm BrowseComp. Artificial Analysis nennt außerdem native Bild- und Videoeingabe sowie 256k maximale Kontextlänge.

Passt besonders zu: Open-Model-Deployments, Coding-Agenten, Recherche-Agenten und Teams, die Hosting und Modellbetrieb stärker kontrollieren wollen.

4. Long-Context- und Open-Source-Experimente: DeepSeek V4

DeepSeek bezeichnete V4 Preview am 24. April 2026 als offiziell live und open-sourced. Die DeepSeek-V4-Pro-Modellkarte stellt die V4-Serie als Mixture-of-Experts-Sprachmodelle dar.

Für DeepSeek V4-Pro/Pro-Max werden unter anderem 67,9 auf Terminal Bench 2.0, 80,6 auf SWE Verified, 55,4 auf SWE Pro und 90,1 auf GPQA Diamond gemeldet. Das macht DeepSeek V4 zu einem strategischen Kandidaten für Open-Source/Open-Weights-Tests und Long-Context-Anwendungen — aber nur, wenn die genaue Variante sauber getrennt bewertet wird.

Passt besonders zu: Long-Context-Anwendungen, Open-Source/Open-Weights-Experimenten und Teams, die gehostete Frontier-Modelle mit deploybaren Alternativen vergleichen.

5. Wissenschaft und Mathematik: Claude führt bei GPQA, aber nicht überall

Bei den verfügbaren gemeldeten Werten kommt Claude Opus 4.7 auf 94,2 % bei GPQA Diamond. Kimi K2.6 meldet 90,5 % bei GPQA-Diamond und 96,4 % bei AIME 2026. DeepSeek V4-Pro/Pro-Max meldet 90,1 bei GPQA Diamond.

Das macht Claude für Science-Reasoning sehr stark. Trotzdem sollte man bei Mathematik- und Wissenschafts-Workloads nicht auf einen einzelnen Benchmark setzen: Tool-Zugriff, Effort-Modus und Evaluationssetup können die Rangfolge verändern.

Praktische Evaluations-Checkliste

• Nicht nach einem einzigen Leaderboard entscheiden. Nutzen Sie öffentliche Benchmarks als Vorauswahl, aber testen Sie intern mit denselben Prompts, Tools, Timeouts, Kostenlimits und Bewertungskriterien.
• GPT‑5.5 und GPT‑5.5 Pro getrennt erfassen. Pro nutzt parallelen Test-Time-Compute; reguläre und Pro-Ergebnisse sind daher nicht automatisch dasselbe Rechenbudget.
• Open-Weights-Anforderungen vorab definieren. Wenn Datenkontrolle, eigenes Hosting oder Anpassbarkeit zwingend sind, sollten Kimi K2.6 und DeepSeek V4 in einer separaten Evaluationsspur laufen.
• Long Context nicht nur an der Fenstergröße messen. Claude Opus 4.7 ist mit 1-Million-Token-Kontextfenster klar positioniert, Kimi K2.6 mit 256k maximaler Kontextlänge; DeepSeek-V4-Materialien setzen ebenfalls auf Long-Context-Positionierung. Entscheidend sind aber Recall, Instruktionsbefolgung und Kosten auf Ihren eigenen Dokumenten.
• Coding-Agenten zusätzlich auf echten Repos testen. SWE‑Bench-Scores sind nützlich, aber Produktions-Repositories bringen eigene Abhängigkeiten, flaky Tests, Coding-Styles und Review-Regeln mit.

Grenzen dieser Einordnung

• In den vorliegenden öffentlichen Quellen gibt es keinen vollständigen Vergleich, der alle vier Modelle in derselben unabhängigen Umgebung, mit identischem Harness, identischem Tool-Zugriff und gleicher Effort-Einstellung testet; LM Council warnt zudem vor Abweichungen zwischen unabhängigen und selbst gemeldeten Benchmarks.
• GPT‑5.5 Pro und GPT‑5.5 sollten nicht gleichgesetzt werden, weil OpenAI GPT‑5.5 Pro als dieselbe Modellbasis mit parallelem Test-Time-Compute beschreibt.
• DeepSeek-V4-Scores sind variantenspezifisch. V4 Preview, V4-Pro und Pro-Max-artige Ergebnisse sollten nicht zu einem einzigen DeepSeek-V4-Wert vermischt werden.
• Bei Open-Weights-Deployments wie Kimi K2.6 und DeepSeek V4 können Serving-Stack, Hardware, Quantisierung und Kontext-Settings die reale Leistung beeinflussen; veröffentlichte Benchmarks ersetzen daher keine Deployment-Evaluation.

Bottom Line

GPT‑5.5 gehört nach oben auf die Shortlist, wenn Agentic Computer-Use, Browsing, Tool-Orchestrierung und terminal-lastiges Coding im Mittelpunkt stehen.

Claude Opus 4.7 ist die stärkste Wahl für die erste Testphase, wenn der Produktwert vor allem in Repo-Level-Bugfixing, Codebase-Reparatur und SWE‑Bench-artigem Software Engineering liegt.

Kimi K2.6 ist besonders interessant, wenn ein Open-Weights-Coding-Modell mit starken SWE‑Bench-, Terminal‑Bench- und agentischen Search-Signalen gebraucht wird.

DeepSeek V4-Pro/Pro-Max sollte auf die Liste, wenn Long-Context-Experimente, Open-Source/Open-Weights-Deployability und Variantenvergleich zentrale Kriterien sind.

Die robusteste Entscheidung entsteht nicht aus einer einzelnen Zahl, sondern aus einer Kombination: öffentliche Benchmarks für die Shortlist, danach interne Tests mit realen Aufgaben, Kosten-, Latenz-, Datenschutz- und Failure-Mode-Prüfung.