GPT-5 für Entwickler freigegeben

• Die GPT-5 API wurde offiziell veröffentlicht und bietet Entwicklern ein neues Leistungsniveau für Coding- und Agentenaufgaben.
• In zentralen Benchmarks wie SWE-bench Verified und Aider polyglot wurden State-of-the-Art-Leistungen (SOTA) erzielt, und in mehreren Kundenbeispielen wie Cursor, Windsurf, Vercel wurde die Überlegenheit bestätigt.
• Bei komplexen realen Aufgaben wie langlaufenden Agentenaufgaben, ausgefeilter Tool-Integration und der Verarbeitung langer Kontexte zeigte sich besondere Stärke.
• Mit fein granularen Parametern wie verbosity, reasoning_effort und eigenen Tools ist eine Entwicklerspezifische Feinkontrolle möglich.
• Mit gpt-5, gpt-5-mini, gpt-5-nano stehen verschiedene Kosten-/Leistungs-Optionen zur Verfügung, und die Modelle wurden in Microsoft sowie in diversen Entwicklerwerkzeugen integriert.

---

Veröffentlichung von GPT-5 und Bedeutung

• OpenAI hat GPT-5 auf der API-Plattform veröffentlicht und betont, dass es das leistungsstärkste bisher veröffentlichte Modell für Coding und Agentenarbeit sei.
• Es erzielte im Bereich der wichtigsten Coding-Benchmarks SOTA (State of the Art) und wurde in Zusammenarbeit mit tatsächlichen Startup- und Enterprise-Testern trainiert.
• Es zeigt sich als starker Partner in realen Entwicklungsaufgaben wie Codegenerierung, Bugfixing, Codebearbeitung und komplexen Codebase-Abfragen.
• Die Fähigkeit, detaillierte Anweisungen präzise zu befolgen, und die verbesserte Erklärung von Aktionen sowie Planungen vor und nach Tool-Aufrufen wurde gesteigert.
• Auch die Frontend-Entwicklung ist stark: in internen Tests wurde ein Vorteil von 70 % gegenüber bisherigen Modellen gemessen.

Hauptkunden und Praxisfälle

• Cursor, Windsurf, Vercel, Manus, Notion, Inditex bewerteten GPT-5s Intelligenz, einfache Steuerbarkeit, den Umgang mit Tool-Fehlern und die Codequalität sehr hoch.
• In realen Ausrollungsszenarien zeigte es bei komplexen Hintergrundaufgaben, langlaufenden Agentenrollen und ausgefeilter Tool-Integration deutlich bessere Stabilität und Effizienz als frühere Modelle.

Benchmarks und Leistungskennzahlen

• SWE-bench Verified (Patching echter Software-Issues): 74,9 % Leistung versus o3 mit 22 % weniger Tokens und 45 % weniger Tool-Aufrufen als Effizienzsteigerung.
• Aider polyglot (Code-Editing-Benchmark): 88 % erreicht, was etwa ein Drittel der Fehlerrate von o3 bedeutet.
• Bei der Analyse komplexer Codebasen können große LLMs auf die jeweilige Anfrage der Nutzer zugeschnitten werden, sodass Entwickler und Forscher sie leichter nutzen können.
• Bei der Frontend-Code-Generierung erzielte GPT-5 in Tests einen Vorteil von 70 % sowohl bei ästhetischer Qualität als auch bei Genauigkeit.

Agentische Arbeit und langfristiger Kontext

• Im τ2-bench telecom (Tool-Calling-Benchmark) wurde mit 96,7 % der aktuelle SOTA-Wert erreicht.
• Hohe Aufgabenabdeckung bei der Ausführung von dutzenden Tool-Aufrufen, sequentiell oder parallel.
• Beste Werte bei der Umsetzungsvorgaben-Bewertung in COLLIE, Scale MultiChallenge.
• In OpenAI-MRCR und BrowseComp Long Context bei Long-Context-Q&A werden o3 und GPT-4.1 übertroffen.
• Bis zu 400.000 Token Kontextlänge werden unterstützt, geeignet für die Analyse großer Dokumente und längerer Gespräche.

Zuverlässigkeit und Sicherheit

• In den Bewertungen LongFact und FactScore wurden gegenüber o3 über 80 % weniger Faktfehler erreicht.
• Das Modell erkennt und meldet eigene Grenzen und stärkt die Genauigkeit, insbesondere im Gesundheitsbereich.
• Bei der realen Nutzung wird in sicherheitskritischen Bereichen weiterhin eine Verifikation durch Entwickler empfohlen.

Entwicklersteuerung und neue API-Funktionen

• reasoning_effort: Mit den Werten minimal, low, medium, high kann das Verhältnis aus Antwortgeschwindigkeit und Schlussfolgerungsqualität gesteuert werden.
  • minimal: schnelle Reaktion, high: qualitativ hochwertige logische Schlussfolgerung
• verbosity: Mit low, medium, high kann die Ausgabelänge geregelt werden.
  • Explizite Anweisungen haben bei Bedarf Vorrang vor den Parametern.
• Custom Tools: Neben JSON wird auch Klartext (Plaintext) unterstützt; die Eingabeformate lassen sich mit regulären Ausdrücken oder einer Context-Free Grammar einschränken.
• Das Risiko von JSON-Escape-Problemen in großen Codefragmenten oder Berichten wird reduziert und die Integration von Entwicklertools wird einfacher.

Verschiedene API-Modelle und Preisgestaltung

• gpt-5: $1.25 pro 1 Million Input-Token, $10 pro 1 Million Output-Token
• gpt-5-mini: $0.25 pro 1 Million Input-Token, $2 pro 1 Million Output-Token
• gpt-5-nano: $0.05 pro 1 Million Input-Token, $0.40 pro 1 Million Output-Token
• Alle Modelle unterstützen reasoning_effort, verbosity, Custom Tools, parallele Tool-Aufrufe, Web-/Datei-/Bild-Tools und Streaming.
• gpt-5-chat-latest wird als Nicht-Reasoning-Modell für ChatGPT zum gleichen Preis veröffentlicht.

Integration und Skalierbarkeit

• Microsoft 365 Copilot, GitHub Copilot, Azure AI Foundry und weitere Microsoft-Plattformen integrieren GPT-5.
• Cursor, Windsurf, GitHub Copilot, Codex CLI nutzen es als Kern-Engine für Entwickler-Agentensysteme.
• In Alpha-Tests und in internen Evaluierungen verschiedener Code- und Automatisierungsprodukte im Produktivbetrieb setzte GPT-5 neue Maßstäbe gegenüber früheren Modellen.

Sicherheit, Zuverlässigkeit und Zusatzmaterialien

• Die Rückgabe von Halluzinationen wurde deutlich reduziert; das Modell beschreibt Arbeitsprozess und Grenzen offener und ehrlicher.
• Implementierungs- und Evaluierungsdetails sowie Sicherheitsmaßnahmen werden transparent in der System Card und im internen Research-Blog bereitgestellt.
• Es ist ein hochgradiger automatisierter Coding-Partner und spezialisiert auf komplexe agentische Workflow-Automatisierung.

Fazit

• GPT-5 ist das derzeit stärkste auf Coding und agentische Arbeit zugeschnittene LLM und ein innovativer Partner, der für reale Entwicklungsumgebungen und Arbeitsautomatisierung optimiert ist.
• Mit der fortentwickelten API-/Tool-Landschaft, den unterschiedlichen Modellgrößen und Preisstufen sowie starken Benchmarks eröffnet GPT-5 für Entwickler und Organisationen eine neue Ära der Produktivität.

[GN⁺]

Hacker News Kommentar

• Zwischen Opus und GPT-5 merke ich im Bereich Software-Entwicklung bislang keinen spürbaren praktischen Unterschied. Für mich ist in der Praxis entscheidend, wie gut ein Modell über lange Zeit den Kontext hält und sich konsequent auf ein gegebenes Ziel zubewegt — ich glaube, genau das ist in realer Software-Engineering-Arbeit am wichtigsten. Ich frage mich, welche Metriken diese Fähigkeit wirklich präzise messen und verifizieren.
  • In den letzten Wochen habe ich in Experimenten von Charlie Labs zur Langzeit-Kontext-Erhaltung mit GPT-5 ausgesprochen gute Ergebnisse gesehen. Als ich GPT-5 dazu brachte, 10 GitHub-Issues zu bearbeiten, und es mit Claude Code verglich, war der Leistungsunterschied erstaunlich groß. Die Details stehen hier. Selbst bei komplexen 30–45-Minuten-Kontexten folgt das Modell auch bei Richtungswechseln gut und verarbeitet große Threads in Linear oder GitHub stabil. Die Anzahl der getesteten Issues ist noch gering, aber der Eindruck war sehr stark; ich plane, die Messungen mit einem größeren Umfang fortzusetzen.
  • Ich erzeuge täglich häufig Ziele mit komplexen und oft wechselnden Kontexten, also Situationen, in denen Kontexttreue zwingend ist. Daher ist es schade, dass GitHub Copilot unter klassischen Coding-Assistenten eigentlich etwas wie „zu kurz gekommen“ wirkt: Im Vergleich zu Modellen von Anthropic, OpenAI oder Google bekommt es deutlich weniger Aufmerksamkeit. Als ich die webbasierte Funktion Spaces ausprobiert habe, war sie für größere Aufgaben besser als im IDE-Kontext. Nachteilig war allerdings, dass das Sammeln des Kontexts und die Ergebnisprüfung länger dauerten als bei meiner eigenen Arbeit; dafür sehe ich schon das Potenzial in der Vorarbeit beim Kontextaufbau.
  • Mit den aktuellen Frontier-LLMs lassen sich die meisten Probleme lösen, wenn der bereitgestellte Kontext ausreichend ist. Bei jedem Fehlschlag nutze ich den Großteil der Zeit darauf, herauszufinden, welche Kontextinformationen fehlen. Deshalb brauche ich vor allem die Fähigkeit, Kontext gezielter zu sammeln. In meinen Anwendungsfällen ist es wichtig, sich auf wirklich relevante Informationen aus Code-Dateien, Issues, PRs und Diskussionen zu konzentrieren. Ich erwarte einen Schritt nach vorne von GPT-5 genau in diesem Punkt. Und je ähnlicher oder besser die Performance im Vergleich zu Opus ist, desto attraktiver ist es — besonders wenn es günstiger ist.
  • Die Preisgestaltung von GPT-5 ist gegenüber Opus deutlich verbessert; sie ist inzwischen auf einem Niveau, das in die Nähe von Gemini 2.5 Pro rückt.
  • Wenn GPT-5 wirklich mit 400k Kontextfenstern arbeiten würde, dürfte es Opus eindeutig deutlich übertreffen.
• Ich teste gerade RAG-Szenarien mit gpt-5-mini, und bisher ist das wirklich beeindruckend. Mit der Option reasoning_effort="minimal" habe ich in Bereichen, in denen vorher alle anderen Modelle Halluzinationen erzeugt haben, als Einzige keine falschen Antworten gesehen. Einen Screenshot dazu habe ich hier gepostet; formelle Evaluierungen folgen noch.
  • Bei der Frage „Was macht ein Produktmanager?“ lieferte GPT-4 rhetorische Floskeln wie „Abteilungsübergreifende Zusammenarbeit“, während GPT-5 schlicht antwortete: „Ich weiß es nicht.“ Allein dieser eine Satz fühlte sich an wie ein echter Augenblick, in dem die KI wirklich „aufwacht“.
  • Auch phi-4 und gemma-3n nutzen im RAG-Kontext nur die gegebenen Informationen und verweigern Antworten außerhalb des Kontextes zunehmend sauberer — ein klarer Fortschritt bei der Vermeidung von Halluzinationen.
  • Für mich ist das die größte Veränderung: Ich arbeite viel mit Workflows mit vielen Tool Calls, und ein großes Problem war bislang, dass das Modell Fake-Tools halluziniert hat. Teilweise wurde sogar der Tool-Aufruf übersprungen und direkt eine unbelegte Antwort ausgegeben. In den jüngsten Trainings-Belohnungs-Mechaniken scheint die Reduktion von Halluzinationen und das Verhindern von Tool-Skips deutlich voranzukommen.
• Die letzten rund 70 Stunden habe ich in der letzten Woche mit verschiedenen Tools wie Cursor und Claude Code experimentiert. Das war wirklich beeindruckend und deutlich zuverlässiger, aber in der Praxis funktioniere die Claude-Familie für mich am konstantesten gut. In realer Nutzung ist das für mich wichtiger als reine Benchmarks. Ich hoffe, dass das neue GPT-Modell in solchen Fällen gut performt — die Konkurrenz wird ja stärker und die Preise sind interessant.
  • Durch das neueste Tool-Update von Cursor (1.4) arbeiten auch Modelle wie Gemini bei Tool Calls jetzt deutlich verlässlicher als früher. Früher passierten selbst bei grundlegenden Sachen wie Dateianpassungen noch häufig Fehler; inzwischen klappt es fast immer.
  • Ich glaube, das hängt auch stark vom eingesetzten Stack ab. Ich habe mir kürzlich das Convex-Vorstellungsvideo von t3.gg angesehen (Video, Convex); dessen Struktur sorgt tatsächlich dafür, dass der erste Versuch besser aus dem Gate kommt. Wenn man es selbst nutzt, bestätigt sich das. Ich glaube, Entwicklungs-Workflows werden sich künftig so entwickeln, dass man nicht sofort in den Code springt. Stattdessen erstellt man mehrere Tickets in PM-Tools (Linear scheint gerade der Standard zu sein), lässt per KI prüfen, welche davon parallel ausführbar sind, und bearbeitet dann in IDE oder Warp mehrere Tickets parallel. Ich mache das selbst noch nicht vollständig so, aber ich denke, ich muss umstellen. Dafür ist git worktree meiner Meinung nach Pflicht: Ressourcen, Dokumentation, Blog
  • Ich frage mich, wie weit ein Produkt wirklich gebaut sein muss, damit man sagen kann: „Das ist gut, es ist verlässlich.“ Mit 70 Stunden schafft man vielleicht eine PoC, doch in der Phase, in der immer mehr Funktionen nachgerüstet werden, interessiert mich die Qualitätsstufe.
  • Obwohl OpenAIs reasoning-basierte Modelle oft besseren Code und bessere Problemlösung liefern, habe ich das Gefühl, Claude Code ist in der Praxis nutzbarer. Selbst ein schwächeres Basismodell kann in realer Anwendung oft die passendere Wahl sein.
• Wenn die Benchmark-Leistung stimmt, ist auch das Preismodell extrem attraktiv: 1,25 USD pro Mio. Eingabetokens, 0,125 USD pro Mio. gecachten Eingabetokens und 10 USD pro Mio. Ausgabetokens. Zum Vergleich: Claude Opus 4.1 kostet 15 USD pro Mio. Input und 75 USD pro Mio. Output. Entscheidend wird jetzt sein, wie gut es Tool Calls im Vergleich zu Claude Code beherrscht. Die Demo war gut, aber beim Tau2-bench-airline-Benchmark lag es unter o3, daher kann man noch keine endgültigen Schlüsse ziehen.
  • In den letzten Stunden bei eigenen Tests habe ich gespürt, dass GPT-5 gegenüber Opus 4.1 zunehmend überzeugt. Nach einigen Monaten Nutzung des Claude Code 200-Plans wurde der Output dort immer weniger zufriedenstellend; GPT-5 wirkt hier einen Schritt vor.
  • Spannend finde ich auch, dass trotz eines Zusammenspiels aus zwei oder mehr Untermodellen ein einheitlicher Token-Preis gilt. Das wirkt wie eine Preiskalkulation, die darauf basiert, dass in der Praxis häufiger günstigere Modelle genutzt werden. Wenn Nutzer aber öfter die leistungsstärkere Variante wählen, frage ich mich, ob das Preismodell dann stabil bleibt — oder ob einfach genügend Marge eingebaut ist, sodass es unkritisch ist.
  • Preis ist nicht gleich Kosten. Der aktuelle Preis wirkt für mich bewusst niedrig gesetzt, um Marktanteile zu sichern; er dürfte nicht direkt die tatsächlichen Betriebsaufwendungen widerspiegeln. Ich erwarte, dass ein großer Teil der 40 Milliarden Dollar, die im März hereinkamen, in diesen Preiswettbewerb fließt.
• Es wird gesagt, GPT-5 habe den Rekord im agentischen Tool-Call-Benchmark „τ2-bench telecom“ auf 96,7 % gesetzt, im airline-Benchmark war es aber schwächer als o3 — klingt so, als würden in der Ankündigung vor allem die für OpenAI günstigen Kennzahlen hervorgehoben.
  • Als jemand, der die betreffende Grafik und den Abschnitt selbst erstellt hat, möchte ich betonen, dass eigentlich die guten Daten bei telecom liegen. Bei den Benchmarks retail und airline bewertet die automatische Auswertung sehr streng nur eine einzige Lösung als korrekt, sodass mehrere gute Ansätze trotz Qualität keine Punkte erhalten. telecom bewertet stattdessen anhand des Ergebniszustands und akzeptiert mehrere Lösungen, wodurch ein offensichtliches Problem des automatisierten Scorings abgefedert wird und das eigentliche Leistungssignal eines Modells klarer hervortritt. Deshalb ist der Fokus auf telecom sinnvoll. Dazu gibt es auch das tau2-bench-Paper. Außerdem gibt es in solchen Evaluierungen keine Teilpunkte; ein kleiner Fehler kann die Gesamtwertung stark drücken, deshalb kann die echte Leistung auch ober- oder unterhalb der Benchmark-Note liegen.
  • Mich interessiert auch der Kostenaspekt: Wenn o3 ziemlich teuer zu betreiben ist und GPT-5 günstiger, ist das selbst bei ähnlicher Performance bereits eine spürbare Verbesserung.
  • Dass im Originaltext selbst erwähnt wird, dass es bei airline schlechter abschneidet, macht diese Frage für mich keine Fangfrage.
• Ich finde die Unterstützung für CFG (kontextfreie Grammatik) und Regex spannend — besonders ob und wie sie sich von der Lark-ähnlichen CFG in llguidance unterscheiden, die in der OpenAI-API zur Implementierung von JSON-Schema-Constraints genutzt wird. Referenzcode
  • Der Teil, auf den ich am meisten freue, ist die CFG- und strukturierte Ausgabe. Bei anderen Stellen (API, Google, OpenAI) gab es da im echten Einsatz ständig Reibung. Ich will das so schnell wie möglich ausprobieren.
• Cursor ist derzeit einige Tage kostenlos nutzbar; ich war schon vorher ein Power-User für agentisches Coden in verschiedenen IDEs/CLIs, und die Kombination Cursor + GPT-5 fühlt sich wirklich gut an. Wenn du Zeit hast, nutz es unbedingt einmal selbst aus.
• Es ist ziemlich cool und spannend, dass es jetzt eine Funktion gibt, mit der man direkt kontextfreie Grammatik in der Ausgabe erzwingen kann. Ich frage mich, wie die korrekte Grammatik auf der Sampling-Ebene durchgesetzt wird.
  • Ich vermute, es handelt sich um „strukturierte Generierung“ bzw. „guided generation“. Für alle, die mit LLMs arbeiten, ist das keine neue Idee — Beispiele sind z. B. Beispiel 1, Beispiel 2. Kernidee: Bei jedem Tokengeneration-Schritt erhält das Modell nicht das komplette Vokabular, sondern nur die Menge an Tokens, die von der aktuellen Grammatik erlaubt ist. Beispiel: Nach { in JSON werden nur die syntaktisch gültigen Tokens als Auswahl angeboten.
  • Die Ausgabe entsteht also mit einem Sampling-Space, der nur grammatisch gültige Tokens enthält; die Beschränkung wird also als harte Restriktion direkt im reinen Inferenzprozess gesetzt.
• Dass im Benchmark nur mit GPT-5 selbst verglichen wird, ohne Wettbewerber, erinnert mich an Apples Strategie, das iPhone nur mit der eigenen Vorgängergeneration zu vergleichen.
• Als ich GPT-5 mit einem schwierigen Problem getestet habe, hat es eine Sache richtig analysiert und gelöst, die Gemini nicht schaffte. Bei der anschließenden Codeänderung scheiterte es aber sechs Mal. Als ich die Ergebnisanalyse von GPT-5 dann in Google Gemini gegeben habe, hat Gemini sofort den passenden Fix-Code erzeugt. Fazit: ChatGPT kann Analyse und Code-Review gut, aber beim tatsächlichen Coden bin ich noch unzufrieden.
  • Mir ist mit Gemini (GCA) und auch mit CoPilot (Claude) dasselbe passiert: In demselben Problem haben beide dieselbe Analyse mit derselben falschen Lösung geliefert. Selbst nach Korrekturhinweisen kamen noch schlechtere Lösungswege raus. ChatGPT habe ich noch nicht genutzt, aber plane es in Kürze.