„Unterstützt dieses Modell Tool-Calls?“ klingt nach einer Frage zum Modell. Das ist sie nicht. Es ist eine Frage zum Modell und zu dem Endpunkt, über den Sie es aufrufen — und dasselbe Modell kann auf dem einen mit Ja und auf dem anderen mit Nein antworten. Diese Seite erklärt, warum das so ist und wie Entity Enricher die Frage klärt: durch Messen statt durch Vertrauen auf einen Katalog.
Schicken Sie der gpt-6-Familie von OpenAI eine Anfrage mit Function Tools an den klassischen Endpunkt /v1/chat/completions, wird die Anfrage rundweg abgelehnt:
400 Bad Request Function tools with reasoning_effort are not supported. Use /v1/responses or set reasoning_effort to 'none'.
Schicken Sie dasselbe Modell, dieselben Tools und denselben Prompt an /v1/responses, antwortet es ganz normal — auf beiden Kanälen für strukturierte Ausgabe, mit oder ohne Reasoning-Effort. Am Modell hat sich nichts geändert. Nur die Adresse.
Die Folge
Eine Fähigkeit ist keine Eigenschaft des Modells allein. Sie ist eine Eigenschaft eines (Modell, Endpunkt)-Paares. Jeder Katalog, der ein einziges Wahr/Falsch pro Modell speichert, beantwortet daher eine Frage, die er gar nicht sehen kann.
Eine Route ist schlicht der Endpunkt, an den eine Anfrage geschickt wird. Gleicher Anbieter, gleiches Modell, gleicher API-Schlüssel — aber ein anderes Übertragungsformat, eine andere Anfragestruktur und andere Regeln dazu, was miteinander kombiniert werden darf. OpenAI bietet zwei davon an, und der Großteil der Branche hat die ältere kopiert.
| Route | Form des Austauschs | Wer sie spricht |
|---|---|---|
Chat Completions /v1/chat/completions2023 | Zustandslos: Sie senden die komplette Liste der Nachrichten und erhalten die nächste Nachricht zurück. Zwischen den Aufrufen wird auf dem Server nichts gespeichert. | OpenAI sowie der De-facto-Industriestandard, den fast alle anderen übernommen haben — xAI, DeepSeek, Alibaba, Groq, Together, Ollama und die meisten OpenAI-kompatiblen Gateways. |
Responses API /v1/responses2025 | Gibt eine Liste typisierter Elemente zurück — ein Reasoning-Element, eine Nachricht, einen Function-Tool-Aufruf, einen Hosted-Tool-Aufruf —, hält den Zustand serverseitig und kann Reasoning von einem Zug in den nächsten übertragen. | Nur OpenAI. Ein nachgebauter Endpunkt, der das Chat-Completions-Format spricht, bedient diesen hier nicht automatisch. |
Deshalb ist „die OpenAI API“ heute mehrdeutig: Es gibt zwei davon, sie überschneiden sich, und sie erzwingen nicht dieselben Regeln.
Reasoning-Modelle haben das Nachrichtenmodell gesprengt. Das interne Reasoning eines Modells ist keine Nachricht: Es ist nichts, was das Modell Ihnen gesagt hat, und nichts, was Sie ihm gesagt haben. Chat Completions kennt nur eine Liste von Nachrichten und hat daher keinen Platz für Reasoning — und was es nicht abbilden kann, verwirft es zwischen den Gesprächszügen.
Die Responses API wurde genau um diese Lücke herum entworfen. Reasoning ist ein vollwertiges Element in der zurückgegebenen Liste; es kann verschlüsselt zurückkommen und im nächsten Schritt erneut übergeben werden, sodass das Modell an seinem eigenen Denken anknüpft, statt es zu rekonstruieren.
Ein Function-Tool-Call ist ein Round Trip: Das Modell fordert ein Tool an, Ihr Code antwortet, das Modell macht weiter. Bei Chat Completions gibt es keinen Ort, an dem das Reasoning über diesen Round Trip hinweg erhalten bleibt — die Fortsetzung würde also stillschweigend ohne es weiterlaufen: Das Modell müsste das bereits bezahlte Denken erneut leisten und würde es vermutlich anders leisten.
Deshalb lehnt der Anbieter die Kombination ab, statt stillschweigend abzuspecken. Die Fehlermeldung ist keine Einschränkung des Modells; sie ist das Eingeständnis der älteren API, dass sie keinen Platz für das hat, was dieses Modell erzeugt.
Würden alle Fähigkeiten denselben Endpunkt bevorzugen, wäre eine Route ein Implementierungsdetail, über das niemand nachdenken müsste. Das tun sie aber nicht.
Strukturierte Ausgabe über den Tool-Kanal ist genau die Kombination, die Chat Completions bei einem Reasoning-Modell ablehnt, und das vom Anbieter gehostete Websuche-Tool wird nur dort akzeptiert.
Rohe Audio-Bytes lassen sich über den Pfad der Responses API nicht mitschicken; ein audiofähiges Modell ist daher nur über den älteren Endpunkt erreichbar.
Ein Modell, zwei Fähigkeiten, zwei verschiedene Endpunkte. Es gibt kein einzelnes Wahr/Falsch, das beiden gerecht wird — deshalb führt Entity Enricher eine Fähigkeitskarte pro Route, und deshalb wird ein Durchlauf, der zwei Fähigkeiten auf zwei verschiedenen Routen benötigt, ausdrücklich abgelehnt, statt stillschweigend eine davon fallen zu lassen.
Die Fähigkeitsprüfung sendet keine künstliche, von Hand geschriebene Anfrage. Sie durchläuft den echten Agent-Pfad — denselben Code, den eine Anreicherung nimmt — mit zwangsweise aktivierter zu prüfender Fähigkeit und lässt die Antwort des Anbieters entscheiden. Gemessen wird also, was die Anwendung tatsächlich kann, und nicht, was die API theoretisch akzeptieren könnte.
Die gesamte Kette – Kanäle für strukturierte Ausgaben, Vision, PDF, Audio, Websuche, Reasoning und dessen Effort-Steuerung pro Anfrage – läuft einmal pro Route, die der Router wählen kann. Bei fast jedem Provider ist das eine einzige Route, und die Prüfung kostet genau so viel wie immer; nur die OpenAI-artigen Provider, die tatsächlich auf zwei Wegen erreichbar sind, werden zweimal gemessen.
Eine Route, die ihren ersten Klartext-Aufruf nicht beantwortet, wird schlicht nicht gemessen, und ein getestetes Modell wird anschließend nur über die Routen geleitet, die geantwortet haben — es gibt kein Ausweichen auf einen anderen Endpunkt, weder bei der Auswahl noch wenn ein Lauf fehlschlägt. Ein Modell, für das keine Route antwortet, wird stillgelegt, ebenso eines, dessen Routen keinen der beiden Kanäle für strukturierte Ausgabe bieten: Text ist niemals ein Ersatz, ein solches Modell könnte also keine einzige Anreicherung bedienen. Nur ein späterer Test, der einen Kanal nachweist, holt es zurück. Fähigkeiten werden niemals geändert, weil ein Lauf fehlgeschlagen ist — gemessen werden sie ausschließlich durch den Test.
Die Anfrage wurde akzeptiert und das Modell hat die erwartete Art von Antwort geliefert.
Wird als gemessenes Wahr für diese Route festgehalten — und hat Vorrang vor jeder ausgelesenen Angabe.
Der Provider hat die Fähigkeit ausdrücklich abgelehnt, oder der Client hat die Anfrage gar nicht erst erstellt.
Das einzige Ergebnis, das ein false schreiben darf. Eine Ablehnung ist zudem kostenlos: Sie wird nie abgerechnet.
Alles andere: ein Rate-Limit, eine fehlende Zugriffsstufe, ein Timeout, ein 5xx des Anbieters, ein unbekannter Fehler.
Es wird nichts geschrieben, und die nächste Prüfung kann es klären.
Die beiden Fehler kosten nicht dasselbe. Ein falsches unknown kostet eine erneute Prüfung: Die Fähigkeit wird später einfach noch einmal gemessen. Ein falsches no ist unsichtbar und dauerhaft – es stuft das Modell überall herab, entfernt es aus den Auswahllisten und aus der Routing-Entscheidung, und niemand erfährt je, warum. Ein unerkannter Fehlschlag beweist daher nichts und wird auch als Beweis für nichts festgehalten.
Ein HTTP 200 beweist, dass die Anfrage angenommen wurde. Es beweist nicht, dass das Modell den Anhang tatsächlich gelesen hat — ein Anbieter kann ein Bild bereitwillig annehmen und es an ein Modell übergeben, das es nie ansieht. Deshalb trägt jeder Test mit Nutzlast eine, deren Antwort sich überprüfen lässt:
| Fähigkeit | Gesendete Payload | Gestellte Frage |
|---|---|---|
| Vision | Ein einfarbig rotes Bild | „Welche Farbe dominiert es?“ |
| PDF-Eingabe | Ein PDF mit genau einem Wort | „Welches Wort steht im Dokument?“ |
| Audioeingabe | Eine Audiodatei mit einer abzählbaren Anzahl von Tönen | „Wie viele einzelne Pieptöne?“ |
Zwei getrennte Ergebnisse – ganz bewusst
Die inhaltliche Antwort wird neben dem Befund festgehalten und kippt nie das Fähigkeits-Flag. Ein kleines Modell, das ein rotes Quadrat falsch liest, unterstützt trotzdem Vision — die Übertragung hat funktioniert, die Modalität wurde transportiert, das Modell war schlicht schwach. „Kann nicht“ mit „hat es schlecht gemacht“ gleichzusetzen, würde eine funktionierende Fähigkeit wegen eines falschen Wortes stillschweigend löschen; beides auseinanderzuhalten, sagt Ihnen beides zugleich.
Öffentliche Modellkataloge wie LiteLLM oder PricePerToken geben Fähigkeiten als schlichte Eigenschaft eines Modells an, ohne Bezug zu einem Endpunkt. Das ist keine Nachlässigkeit — dafür gibt es schlicht kein Feld. Es bedeutet aber, dass eine Angabe allgemein völlig richtig und für den Endpunkt Ihres Durchlaufs trotzdem falsch sein kann.
„Dieses Modell unterstützt Tool-Calls.“ Irgendwo wahr. Schweigt darüber, wo. Nützlich als Ausgangspunkt für ein Modell, das noch niemand getestet hat.
„Auf diesem Endpunkt hat dieses Modell zu diesem Zeitpunkt Tool-Calls angenommen.“ Die Aussage nennt ihre Route und lässt sich deshalb mit der Route vergleichen, die ein Lauf tatsächlich nehmen wird.
Die Route zu benennen hält eine Messung auch über die Zeit hinweg ehrlich. Ein Befund, der an einem Endpunkt erhoben wurde, den das Modell nicht mehr nutzt, ist kein besserer Beleg als eine bloße Angabe — er belegt etwas anderes. Ohne die mitgespeicherte Route wäre eine alte Messung von einer aktuellen nicht zu unterscheiden und hätte für den falschen Endpunkt Vorrang vor dem Katalog. Ist die Route festgehalten, greift die Messung dort schlicht nicht, und die Angabe gilt weiter, bis eine Messung am richtigen Endpunkt sie ersetzt.
Sowohl der Modellkatalog in der App als auch der öffentliche Modellkatalog haben neben den Filtern einen Route-Selektor. Er bestimmt, für welche Route die Fähigkeitssymbole in jeder Zeile antworten.
Jede Zeile bezieht sich auf den Endpunkt, über den das jeweilige Modell tatsächlich bereitgestellt wird. Diese Ansicht entspricht dem, was Sie bei einer Anreicherung erhalten, und ist die maßgebliche Ansicht, sofern Sie nicht einen bestimmten Endpunkt untersuchen.
Fixieren Sie die gesamte Tabelle auf einen Endpunkt, beziehen sich die Symbole nur auf diesen Endpunkt — so sehen Sie, wie eine Fähigkeit beim Wechsel auftaucht oder verschwindet, und so vergleichen Sie zwei Modelle unter gleichen Bedingungen.
Ein Modell mit nur einer erreichbaren Route zeigt gar keinen Selektor: Es gibt nichts zu wählen, und seine Symbole antworten bereits für den einzigen Endpunkt, den es hat. Der Selektor erscheint genau dann, wenn die Mehrdeutigkeit real ist.
Meistens nichts — und genau das ist der Sinn. Sie wählen nie eine Route. Sie wählen ein Modell und beschreiben Ihren Durchlauf, und der Router wählt den Endpunkt, der leisten kann, was der Durchlauf braucht: Tools und Websuche gehen dorthin, wo sie akzeptiert werden, ein Audio-Anhang dorthin, wo Audio übertragen wird.
Der einzige Fall, der Ihnen auffallen wird, ist ein echter Konflikt – etwa wenn Sie für dasselbe OpenAI-Modell eine Websuche anfordern und zugleich eine Audiodatei anhängen, da kein einzelner Endpunkt beides bedient. Dieser Durchlauf wird ausdrücklich abgelehnt, unter Nennung der beiden Fähigkeiten und dessen, was jede Route übertragen kann – statt ihn auszuführen und eine davon stillschweigend zu verwerfen. Lassen Sie eine Anforderung weg oder wählen Sie ein Modell, das beides bedient, dann läuft er durch.
Und wenn Sie ein Fähigkeitssymbol überrascht, liefert der Route-Selektor die Erklärung: Fast immer sehen Sie ein Modell, dessen Antwort davon abhängt, wo die Frage gestellt wurde.