2. April 2026

GPT-5.4 -- Tool Search und die drei Varianten

OpenAI hat am 5. Maerz 2026 GPT-5.4 veroeffentlicht -- nach eigener Aussage das "most capable and efficient frontier model for professional work". Das Modell bringt drei Varianten, ein Kontextfenster von bis zu 1,05 Millionen Token und eine neue Architektur namens Tool Search mit, die das Zusammenspiel zwischen Modell und Werkzeugen grundlegend veraendert.

Die drei Varianten

GPT-5.4 erscheint erstmals in drei klar abgegrenzten Ausfuehrungen:

Standard -- Das Basismodell fuer alltaegliche Produktionslasten. Preislich bei $2.50 / $15 pro Million Token (Input/Output). Deckt die meisten API-Anwendungsfaelle ab, von Textgenerierung bis einfachem Tool-Calling.

Thinking -- Eine Reasoning-Variante mit erweiterter Kette logischer Schritte. Konzipiert fuer mehrstufige Problemloesung: mathematische Beweise, Code-Architektur, Forschungsfragen. Das Modell investiert zusaetzliche Rechenzeit in die Ableitung, bevor es antwortet.

Pro -- Die leistungsfaehigste Variante fuer professionelle Anwendungen, bei denen Qualitaet Vorrang vor Kosten hat. Bei $30 / $180 pro Million Token deutlich teurer, dafuer maximale Performance auf anspruchsvollen Benchmarks.

Benchmark-Ergebnisse

Die Zahlen positionieren GPT-5.4 in der Spitzengruppe:

SWE-bench Verified: ~80% (Claude Opus 4.6: 80,8%)
SWE-bench Pro: 57,7%
HumanEval: 95,1%
OSWorld (Computer Use): 75% -- uebertrifft die menschliche Experten-Baseline von 72,4%
ARC-AGI: 62,1%
Faktenfehler: 33% weniger Falschaussagen und 18% weniger fehlerhafte Antworten gegenueber GPT-5.2

Tool Search: Die eigentliche Neuerung

Tool Search ist die architektonisch interessanteste Aenderung in GPT-5.4. Bisher mussten alle verfuegbaren Tool-Definitionen bei jedem API-Call in den Prompt geladen werden -- ein statischer Ansatz, der bei wachsender Tool-Landschaft immer teurer und ungenauer wird.

Das Problem mit statischem Tool-Loading

Bei 80 Tools mit durchschnittlich 180 Token pro Definition fallen 14.400 Token allein fuer Werkzeugbeschreibungen an -- pro Request, unabhaengig davon, ob das Modell sie braucht. Das verursacht drei Probleme:

Attention Dilution -- Das Modell verteilt Aufmerksamkeit ueber irrelevante Definitionen
Tool Confusion -- Ueberlappende Beschreibungen fuehren zu falscher Tool-Wahl
Lost-in-the-Middle -- Relevante Tools, die in der Mitte einer langen Liste stehen, werden faktisch unsichtbar

Wie Tool Search funktioniert

Tool Search laedt Werkzeugdefinitionen dynamisch zur Laufzeit nach. Das Modell erhaelt zunaechst nur Namen und Kurzbeschreibungen der verfuegbaren Tools. Erst wenn es ein konkretes Werkzeug benoetigt, wird dessen vollstaendige Definition in den Kontext geladen.

Die Aktivierung erfolgt ueber zwei Ergaenzungen im API-Call:

{"type": "tool_search"} wird dem tools-Array hinzugefuegt
Einzelne Funktionen werden mit "defer_loading": true markiert

OpenAI empfiehlt, Tools in Namespaces oder MCP-Server zu gruppieren (maximal 10 Funktionen pro Namespace), da die Modelle primaer auf diesen Oberflaechen trainiert wurden.

Hosted vs. Client-Executed

GPT-5.4 unterstuetzt zwei Varianten von Tool Search:

Hosted Tool Search -- OpenAI uebernimmt die Suche. Das Modell durchsucht automatisch die deklarierten Tools und laedt bei Bedarf nach. Der Ablauf: tool_search_call (Suche) -> tool_search_output (geladene Tools) -> function_call (Ausfuehrung).

Client-Executed Tool Search -- Die Anwendung steuert die Tool-Suche selbst. Das Modell emittiert einen tool_search_call mit einem goal-Parameter, die Anwendung fuehrt die Suche aus (z.B. via Vektor-Datenbank) und gibt die passenden Tool-Definitionen zurueck. Das erlaubt kontextabhaengige Tool-Auswahl basierend auf Projekt, Mandant oder Nutzerstatus.

Messbare Ergebnisse

OpenAIs Benchmarks zeigen bis zu 47% Reduktion des gesamten Prompt-Token-Verbrauchs. Bei einem realistischen Szenario mit 80 statisch geladenen Tools gegenueber 5 dynamisch abgerufenen ergibt sich eine Token-Reduktion von 14.400 auf 900 Token allein fuer die Definitionen. Ueber einen zehnstufigen Agenten-Workflow kumuliert sich das zu einer 8-fachen Reduktion der Tool-Definition-Token.

Wichtig: Die geladenen Tools werden am Ende des Kontextfensters platziert, was den KV-Cache ueber Requests hinweg erhaelt und Latenz weiter reduziert.

Praxistest: Amp und das "Chatty"-Problem

Einen aufschlussreichen Praxisbericht liefert Amp, der Coding-Agent von Sourcegraph. Amp hat GPT-5.4 in seinen "Deep Mode" integriert und beschreibt es als "the best model in the world right now" -- schneller als der bisherige GPT-5.3-Codex bei gleichwertiger Coding-Leistung.

Allerdings offenbarte sich ein fundamentales Problem: Out of the box war GPT-5.4 "too chatty" -- zu gespraechig fuer autonome Coding-Workflows. Deep Mode ist kein Pair Programmer, sondern soll eigenstaendig Probleme loesen. Die ausfuehrlichen Erklaerungen und Rueckfragen des Rohmodells stoerten diesen Workflow massiv.

Amps Loesung: Sie haben GPT-5.4 auf das Verhaltensmuster von GPT-5.3-Codex getunt -- weg vom gespraechigen Assistenten, hin zum fokussierten Problemloeser. Nach dieser Anpassung wurde GPT-5.4 exklusiv eingesetzt, auch fuer interaktive Aufgaben. Amp betreibt es standardmaessig auf Reasoning-Level deep^2, fuer anspruchsvolle Aufgaben auf deep^3.

Das unterstreicht eine Erkenntnis, die sich durch die gesamte Agent-Entwicklung zieht: Ein Modell, das auf Benchmarks dominiert, ist nicht automatisch fuer autonome Workflows geeignet. Die Anpassung -- Systemprompts, Verhaltenssteuerung, Guardrails -- ist eigenstaendige Arbeit.

Was bedeutet Tool Search fuer Agent-Entwickler?

Tool Search adressiert ein reales Problem in der Agent-Entwicklung. Wer Agenten baut, die ueber viele Werkzeuge verfuegen, kennt den Zielkonflikt: Mehr Tools bedeuten mehr Faehigkeiten, aber auch mehr Token-Kosten und schlechtere Genauigkeit bei der Tool-Auswahl.

Wo sich der Einsatz lohnt

Grosse Tool-Bibliotheken (30+ Definitionen) -- hier ist die Token-Ersparnis substantiell
Mehrstufige Workflows -- die Einsparungen kumulieren sich ueber jeden Schritt
Hohe Parallelitaet -- pro-Request-Einsparungen multiplizieren sich ueber parallele Sessions
Hintergrund-Agenten -- reine Kostenreduktion ohne UX-Auswirkung

Worauf man achten muss

Beschreibungsqualitaet ist entscheidend -- vage Beschreibungen wie "verarbeitet Daten" embedden schlecht und fuehren zu Retrieval-Fehlern
Retrieval Misses -- wenn das benoetigte Tool nicht in den Top-k-Ergebnissen landet, schlaegt die Aufgabe still fehl, ohne Fehlermeldung
Index-Aktualisierung -- neue Tools muessen re-indiziert werden, sonst sind sie unsichtbar
Cache-Vertraeglichkeit -- dynamische Tool-Sets brechen die Konsistenz von Prompt Caching, da sich die Tool-Definitionen pro Request aendern

Empfohlene Fallback-Strategie

2-3 "always-on" Tools (z.B. Klaerungsfragen, Hilfe-Funktionen) sollten immer geladen bleiben, damit das Modell bei schlechtem Retrieval nicht ohne Handlungsmoeglichkeit dasteht.

Einordnung

GPT-5.4 ist kein Quantensprung gegenueber GPT-5.3-Codex beim reinen Coding. Die Benchmark-Unterschiede sind marginal, und die Chatty-Problematik zeigt, dass Rohmodell-Performance nicht gleich Agent-Tauglichkeit ist.

Die eigentliche Innovation liegt in Tool Search. Fuer Agent-Entwickler, die mit grossen Tool-Oekosystemen arbeiten, ist das ein konkreter Fortschritt: weniger Token, bessere Tool-Auswahl, niedrigere Kosten. Wer heute Agenten mit 10+ Tools baut, sollte sich mit der Architektur vertraut machen -- unabhaengig davon, ob man bei OpenAI bleibt oder nicht. Das Konzept der dynamischen Tool-Suche wird sich als Pattern durchsetzen.

Quellen

Nach oben