Anmerkung des Autors: Weder Codex noch WorkBuddy sind speziell für Claude entwickelt. Die Fehler entstehen fast immer bei der Anbindung. Dieser Artikel ordnet die Originalfehlermeldungen drei Kategorien zu – Endpunkt, Tool-Kommunikation und Denkblöcke – und zeigt die passenden Lösungen.
Wir sind selbst in diese Falle getappt. Anfangs haben wir Claude über ein OpenAI-kompatibles Protokoll aufgerufen, es also wie ein OpenAI-Modell behandelt. Einfache Gespräche funktionierten problemlos. Sobald aber Tools zum Einsatz kamen, gab es Fehler – auch erneute Versuche halfen nicht. Erst der Wechsel zurück zum nativen Anthropic-Protokoll über /v1/messages brachte die Lösung.
Prüfen Sie zuerst, ob Sie betroffen sind: Codex meldet direkt beim Start einen Fehler im Zusammenhang mit wire_api, WorkBuddy chattet problemlos, liefert aber beim Tool-Aufruf einen 400-Fehler, oder die Antwort ist aus unerklärlichen Gründen leer? Dann liegt vermutlich einer der hier beschriebenen Fälle vor.
- Das Modell selbst ist nicht defekt. Das Problem liegt daran, dass bei der Anbindung drei Dinge nicht zusammenpassen: Endpunkt, Tool-Kommunikation und Denkblöcke.
- Am einfachsten lässt sich Kategorie 3 beheben (Denkblöcke und Ausgabebudget): Im Client müssen nur die Art des Auslesens und
max_tokensangepasst werden. - Kategorie 2 (Tool-Kommunikation) ist mittelschwer und lässt sich hauptsächlich über eine Übersetzungsschicht oder ein Gateway korrigieren.
- Am aufwendigsten ist Kategorie 1 (Endpunkt): Hier hilft nur ein anderer Client oder ein zusätzliches Übersetzungs-Gateway.
Das Fazit des Artikels in Kurzform: Natives Anthropic-Protokoll > Gateway-Übersetzung zu Anthropic > OpenAI-kompatibler Chat. Als ersten Schritt können Sie anhand der folgenden Übersicht prüfen, zu welcher Kategorie Ihre Fehlermeldung gehört.
Die drei Hauptursachen für Claude-Fehler in Codex und WorkBuddy
Zunächst ein paar Begriffe: Responses, Messages und Chat Completions kann man sich als drei Arten vorstellen, ein Gericht zu bestellen. Aus der Küche kommt dasselbe Essen, aber die Bestellformulare unterscheiden sich. Codex bestellt nur über Responses, Claude akzeptiert nur Messages und Chat Completions. Ein thinking-Block ist gewissermaßen das Schmierpapier des Modells. Anthropic prüft, ob daran nachträglich etwas verändert wurde.
| Kategorie | Mechanismus in einem Satz | Wer behebt das Problem? | Aufwand |
|---|---|---|---|
| Typ 1: Endpunkte passen nicht zusammen | Codex sendet nur Responses, Claude akzeptiert dieses Format nicht | Tool oder Gateway wechseln | Am höchsten |
| Typ 2: Tool-Anfragen und -Antworten passen nicht zusammen | Bei der Übersetzung werden IDs, Inhaltsblöcke oder thinking-Blöcke verändert | Hauptsächlich das Gateway | Mittel |
| Typ 3: thinking-Blöcke und Budget passen nicht zusammen | Das Modell denkt bei jeder Anfrage nach, der Client liest das Ergebnis aber noch auf die alte Weise | Der Client | Am geringsten |
Kategorie 1: Endpunkte passen beim Aufruf von Claude über Codex nicht zusammen
So sieht die Fehlermeldung aus: Error loading config.toml: wire_api = "chat" is no longer supported. How to fix: set wire_api = "responses".
Das bedeutet: Die Einstellung wire_api = "chat" wird nicht mehr unterstützt und muss auf responses geändert werden.
Warum das passiert: Laut der offiziellen Codex-Konfigurationsreferenz ist für wire_api inzwischen nur noch der Wert responses zulässig. Der frühere Ausweg, wire_api auf chat zu setzen, funktioniert nicht mehr: Neue Codex-Versionen melden bereits beim Laden der Konfiguration einen Fehler. Selbst wenn der betreffende Provider gar nicht verwendet wird, lässt sich dadurch auch codex login status nicht mehr ausführen. Die Claude-Modelle bei APIYI apiyi.com bieten wiederum nur anthropic- und openai-Endpunkte, aber kein /v1/responses. Die Formate passen also nicht zusammen – und ohne eine Übersetzung dazwischen ist ein Fehler unvermeidlich.
So beheben Sie das Problem:
1. Client: Öffnen Sie ~/.codex/config.toml und entfernen Sie wie in der Fehlermeldung angegeben verbliebene chat-Einstellungen, damit Codex wieder startet.
2. Tool wechseln: Wenn Sie Claude nur zum Programmieren nutzen möchten, wechseln Sie direkt zu Claude Code. Es verwendet die native Messages-API.
3. Gateway: Wenn Sie bei Codex bleiben müssen, schalten Sie ein Gateway dazwischen, das Responses in Messages übersetzt. Tragen Sie als Provider-Adresse vorzugsweise den nativen Anthropic-Endpunkt ein.
Erfolgskriterium: codex login status lässt sich ausführen. Beim Einsatz eines Gateways sollte Codex ausserdem eine Anweisung zum Lesen einer Datei mit einem vollständigen Tool-Aufruf ausführen können.
Kategorie 2: Claude-Tool-Aufrufe und -Ergebnisse passen nicht zusammen
So sehen die Fehlermeldungen aus:
– tool_use ids were found without tool_result blocks immediately after
– An assistant message with 'tool_calls' must be followed by tool messages...
– thinking or redacted_thinking blocks in the latest assistant message cannot be modified
– Invalid signature in thinking block. The block is bound to a different conversation.
Die erste Meldung bedeutet, dass auf einen tool_use-Block nicht unmittelbar der zugehörige tool_result-Block folgt. Die zweite beschreibt dasselbe Problem im Chat-Format. Die dritte zeigt an, dass der Thinking-Block der vorherigen Runde verändert wurde. Die vierte bedeutet, dass die Signatur des Thinking-Blocks nicht zur aktuellen Sitzung passt.
Warum das passiert: Die Kompatibilitätsschicht muss Claude-Inhaltsblöcke wie text, tool_use, tool_result und thinking einzeln in tool_calls und role: tool übersetzen und anschließend wieder zurück. Sobald dabei eine ID nicht passt, Inhaltsblöcke zusammengeführt oder Thinking-Blöcke verschoben werden, kommt ein 400-Fehler zurück. In Responses gibt es außerdem die Rolle developer, in Messages dagegen nicht. Ihr Inhalt muss daher in system übernommen werden. Außerdem akzeptiert claude-opus-5-5 folgende ältere Vorgehensweisen nicht: erzwungenes tool_choice (any oder ein bestimmtes Tool), vorab ausgefüllte Assistant-Nachrichten (Prefill) sowie temperature / top_p / top_k.
So beheben Sie das Problem:
1. Gateway: Auf jeden tool_use-Block muss unmittelbar ein tool_result-Block mit derselben ID folgen. Der tool_result-Block muss am Anfang der Inhaltsblöcke der User-Nachricht stehen.
2. Gateway: Die Assistant-Nachricht der vorherigen Runde unverändert zurückgeben, auch Blöcke mit leerem thinking-Feld. Den Inhalt von developer in system übernehmen.
3. Client: Für tool_choice nur auto oder none verwenden. Prefill und Sampling-Parameter entfernen.
4. Client: Wenn bereits ein Signaturfehler aufgetreten ist, direkt eine neue Sitzung starten. Laut den offiziellen FAQ von APIYI wird dieser Fehler manchmal als Request rejected (429) ausgegeben. Es handelt sich aber nicht um eine Ratenbegrenzung; auch erneute Versuche mit Backoff helfen nicht.
5. Tool wechseln: Wenn das Harness ein erzwungenes tool_choice fest vorgibt und Sie das nicht ändern können, wechseln Sie den Client.
Eine Anleitung zur Fehlersuche bei ähnlichen 400-Fehlern finden Sie unter Claude Code: Fehler 400 bei gleichzeitigen Tool-Aufrufen. Der Beitrag erklärt, wie Sie Schritt für Schritt herausfinden, warum tool_use und tool_result nicht zusammenpassen.
Prüfkriterium: Bei mehreren aufeinanderfolgenden Tool-Aufrufen – Datei lesen, Datei ändern, Datei erneut lesen – tritt kein 400-Fehler mehr auf. Auch Signaturfehler erscheinen innerhalb derselben Sitzung nicht mehr.
Kategorie 3: Claude-Thinking-Blöcke und Ausgabebudget passen nicht zusammen
So sieht der Fehler aus: "thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior. Möglich ist auch "thinking.type.disabled" is not supported for this model. Manchmal erscheint keine Fehlermeldung, aber die Antwort ist leer oder wird abgeschnitten.
Warum das passiert: claude-opus-5-5 führt bei jeder Anfrage einen Denkprozess aus. Die Antwort kann daher mit einem Thinking-Block beginnen. Liest der Client content[0].text anhand der Position aus, erhält er einen leeren Wert. Thinking-Token werden als Ausgabe berechnet und beanspruchen ebenfalls max_tokens. Ab dieser Modellgeneration stehen auch die Erläuterungen zwischen Tool-Aufrufen in Thinking-Blöcken. Da display standardmäßig auf omitted steht, erscheinen sie leer.
So beheben Sie das Problem:
1. Client: Lassen Sie den Parameter thinking entweder weg oder setzen Sie ihn auf thinking: {"type": "adaptive"}. Entfernen Sie außerdem budget_tokens.
2. Client: Steuern Sie die Denktiefe stattdessen über output_config.effort. Zur Auswahl stehen low / medium / high / xhigh / max; der Standardwert ist medium.
3. Client: Suchen Sie beim Auslesen der Antwort anhand von type nach dem Textblock, statt ihn über seine Position abzurufen.
4. Client: max_tokens muss sowohl den Denkprozess als auch den Antworttext abdecken. Wenn Sie die Erläuterungen sehen möchten, setzen Sie thinking.display auf summarized.
Wenn Sie den neuen Mechanismus genauer verstehen möchten, lesen Sie Adaptive Thinking erklärt. Dort erfahren Sie auch, wie Sie von budget_tokens auf die effort-Stufen umstellen.
Prüfkriterium: Senden Sie dieselbe Eingabeaufforderung mehrmals hintereinander. Der Antworttext ist jedes Mal nicht leer, und es treten keine Fehler im Zusammenhang mit thinking.type mehr auf.
Claude-Fehlermeldungen im Überblick
| Schlüsselwort der Fehlermeldung | Kategorie | Selbstcheck in 5 Minuten | Weiterführender Artikel |
|---|---|---|---|
wire_api = "chat" is no longer supported |
Kategorie 1 | Prüfen, ob in config.toml noch ein chat-Eintrag steht |
Magpie-Anleitung |
tool_use ids were found without tool_result |
Kategorie 2 | ID und Position von tool_result prüfen |
Claude Code: Fehler 400 bei gleichzeitigen Tool-Aufrufen |
must be followed by tool messages |
Kategorie 2 | Prüfen, ob eine Chat-Kompatibilitätsschicht verwendet wird | Claude Code: Fehler 400 bei gleichzeitigen Tool-Aufrufen |
Invalid signature in thinking block |
Kategorie 2 | Eine neue Sitzung starten und erneut versuchen | Adaptive Thinking erklärt |
thinking.type.enabled / leere Antwort |
Kategorie 3 | budget_tokens entfernen und stattdessen anhand von type auslesen |
Adaptive Thinking erklärt |
| Einfache Gespräche funktionieren, Tool-Aufrufe schlagen fehl | Kategorie 2 | Das Verbindungsprotokoll von WorkBuddy prüfen | Unterstützt WorkBuddy Aufrufe im nativen Claude-Format? |
Zwei Wege, um Claude-Aufruffehler in Codex und WorkBuddy zu beheben
| Weg | Für wen geeignet | Protokollpriorität |
|---|---|---|
| A: Zurück zum nativen Client | Wer mit Claude nur Code schreiben möchte | Höchste Priorität, keine Verluste durch Übersetzung |
| B: Übersetzungs-Gateway hinzufügen | Wer bei Codex oder WorkBuddy bleiben muss | Zweithöchste Priorität, als Anbieteradresse Anthropic eintragen |
| Dauerhaft bei Chat-Kompatibilität bleiben | Nicht empfohlen | Niedrigste Priorität, Tool-Aufrufe und Thinking-Blöcke sind fehleranfällig |
Weg A: Wer Claude in Codex nutzen möchte, wechselt stattdessen zu Claude Code. Die offizielle Modellkonfiguration von WorkBuddy bietet nur /chat/completions und den Schalter „Benutzerdefiniertes Protokoll“, aber keinen nativen Anthropic-Zugang. Natives Thinking ist in WorkBuddy daher nicht zu erwarten. Mehr dazu im Artikel Unterstützt WorkBuddy Aufrufe im nativen Claude-Format?. Er erklärt, warum Gespräche funktionieren, Tool-Aufrufe aber fehlschlagen – und welche Umgehungsmöglichkeiten es gibt.
So richten Sie die direkte Verbindung in WorkBuddy ein: Gehen Sie zu „Einstellungen → Modell → Benutzerdefiniert“. Tragen Sie als Base URL https://api.apiyi.com/v1 und als Modellnamen claude-opus-5-5 ein. Verwenden Sie als Key den Schlüssel, den Sie auf der Token-Seite von APIYI apiyi.com erstellt haben. Die URL endet bei /v1 – hängen Sie /chat/completions nicht selbst an.
Bildunterschrift: Prüfen Sie insbesondere, ob die URL bei /v1 endet, der Modellname claude-opus-5-5 lautet und der Schalter „Benutzerdefiniertes Protokoll“ ausgeschaltet ist.
Weg B: Wenn Sie Codex um ein Gateway ergänzen, bleibt in Codex wire_api = "responses" unverändert. Das Gateway übersetzt die Anfragen in das Messages-Format und leitet sie weiter. In WorkBuddy zeigt die URL des benutzerdefinierten Modells auf das lokale Gateway; als Anbieteradresse für Claude-Modelle tragen Sie den nativen Anthropic-Endpunkt https://api.apiyi.com ein.
🎯 Technischer Tipp: Mit einem einzigen Key können Sie sowohl den nativen Messages-Endpunkt als auch den kompatiblen Chat-Endpunkt testen. Vergleichen Sie zunächst mit Testguthaben auf APIYI apiyi.com, wie Tool-Aufrufe mit beiden Protokollen funktionieren. Entscheiden Sie danach, welchen Weg Sie wählen.
Claude über Magpie mit Codex und WorkBuddy verbinden
Magpie ist ein Open-Source-Tool der Community unter MIT-Lizenz. Es startet lokal unter 127.0.0.1:3425 ein Gateway, das zwischen OpenAI Chat, Responses und Anthropic Messages übersetzt. Damit schliesst es genau die Lücke der ersten Kategorie. Statt alles manuell einzurichten, können Sie die Konfiguration auch über die grafische Oberfläche von Magpie vornehmen. Tragen Sie dort den API-Schlüssel und die Base URL ein und verbinden Sie Codex und WorkBuddy mit demselben Gateway – ohne Konfigurationsdateien von Hand zu bearbeiten. Die vollständige Anleitung finden Sie im Magpie-Tutorial. Dort erfahren Sie, wie Sie die Modellquellen mehrerer Agenten über ein Gateway vereinheitlichen.
- Anbieterseite: Fügen Sie den API-Schlüssel hinzu. APIYI finden Sie in der Gruppe „Proxy“. Alternativ können Sie über „+ Benutzerdefinierter Anbieter“ die Daten manuell eingeben.
- Agentenseite: Wählen Sie für Codex und WorkBuddy jeweils claude-opus-5-5 aus.
- Starten Sie eine neue Sitzung, statt den Verlauf einer alten Sitzung weiterzuverwenden.
Bildunterschrift: Prüfen Sie, ob der Anbieter in der Gruppe „Proxy“ als verfügbar angezeigt wird, ob die Base URL auf die native Anthropic-Adresse verweist und ob auf der Agentenseite beide Schalter aktiviert sind.
Preise für Claude-Aufrufe und Cache-Kosten
Alle Preise sind in US-Dollar pro Million Tokens angegeben. Stand: 28.10.2026. Massgeblich für verfügbare Modelle und Preise ist die Modellliste der jeweiligen Plattform.
| Modell | Eingabe | Ausgabe | Cache-Lesezugriff | Verfügbare Plattform |
|---|---|---|---|---|
| claude-opus-5-5 | $4 | $20 | $0.2 | APIYI apiyi.com |
| claude-sonnet-5-5 | $2 | $10 | $0.1 | APIYI apiyi.com |
| claude-haiku-5-5 | $0.1 | $0.5 | $0.01 | APIYI apiyi.com |
Ein Agent sendet in jeder Runde den vollständigen Verlauf erneut. Die Denk-Token von claude-opus-5-5 werden zum Ausgabepreis abgerechnet. Wenn die Übersetzungsschicht die Reihenfolge von system, tools oder Präfixen verändert, wird der cache_control-Haltepunkt unwirksam. Dadurch steigen sowohl die Kosten als auch die Latenz. Bei einer ungewöhnlichen Cache-Trefferquote hilft der Artikel Claude-Cache-Trefferquote fällt auf 0 (Diagnose). Er erklärt, wie Sie die Ursache für einen unwirksamen Haltepunkt finden.
Risiken und Kontosperrungen auf eigene Verantwortung
Gateways wie Magpie sind Open-Source-Tools aus der Community und keine offiziellen Komponenten von APIYI. Wir sprechen keine Empfehlung dafür aus und bieten keinen technischen Support. Wer Anfragen über solche Tools weiterleitet, riskiert eine Drosselung oder sogar eine Kontosperrung durch den Zieldienst. Die Folgen tragen Sie selbst. Testen Sie am besten zuerst den gesamten Ablauf mit einem Testkonto. Wenn alles funktioniert, können Sie den Einsatz mit einem regulären Konto in Betracht ziehen.
Wann sich der Aufwand nicht lohnt
Wenn Sie Claude nur gelegentlich in Codex nutzen, Ihre Unternehmensumgebung keine zusätzliche Software erlaubt oder Sie ohnehin nur Claude benötigen, müssen Sie kein Gateway einrichten. Wechseln Sie stattdessen zu Claude Code oder nutzen Sie in Codex ein Modell mit nativer Responses-Unterstützung. Das ist deutlich einfacher.
Häufige Fragen (FAQ)
F1: Unterstützt Codex Claude offiziell?
Nein. Codex nutzt ausschließlich Responses, Claude bietet aber keinen solchen Endpunkt an. Für die Nutzung ist daher eine Übersetzungsschicht nötig.
F2: Ist Claude über APIYI unter /v1/responses verfügbar?
Nein. Die Claude-Modelle auf APIYI, apiyi.com, sind nur über die Endpunkte anthropic und openai verfügbar.
F3: Bedeutet ein 429-Fehler, dass eine Ratenbegrenzung greift?
Wenn die Fehlermeldung `Invalid signature in thinking block` enthält, liegt keine Ratenbegrenzung vor. Stattdessen ist die Signaturprüfung des Thinking-Blocks fehlgeschlagen. Öffnen Sie einfach eine neue Sitzung.
F4: Kann WorkBuddy das native Anthropic-Protokoll nutzen?
Die offizielle Konfiguration bietet keinen nativen Anthropic-Zugang. Sie können nur die OpenAI-kompatible Schnittstelle nutzen oder die Anfragen über ein Gateway umwandeln lassen.
F5: Wie lässt sich schnell prüfen, ob das Problem behoben ist?
Öffnen Sie mit dem Testguthaben von APIYI auf apiyi.com eine neue Sitzung und führen Sie mehrere Runden mit Tool-Aufrufen aus. Prüfen Sie dabei auch, dass der Antworttext nicht leer ist.
Checkliste: Claude-Fehler in Codex und WorkBuddy selbst prüfen
- In der Codex-Konfiguration gibt es keine Einträge im Chat-Format mehr.
- Claude-Anfragen nutzen das native Protokoll oder laufen über ein Gateway, das sie ins Anthropic-Format übersetzt – nicht über die Chat-Kompatibilität.
- Auf jeden
tool_usefolgt unmittelbar eintool_resultmit derselben ID. - Der Thinking-Block aus der vorherigen Runde wird unverändert zurückgegeben.
- Es werden weder ein erzwungenes
tool_choicenoch Prefill oder Sampling-Parameter verwendet. - Antworten werden anhand von
typeausgelesen, undmax_tokenslässt genügend Platz für den Denkprozess.
Fazit
Claude-Fehler in Codex und WorkBuddy lassen sich meist auf drei Bereiche zurückführen: Endpunkt, Tool-Aufrufe und ihre Ergebnisse sowie Thinking-Blöcke. Gehen Sie bei der Fehlerbehebung in dieser Reihenfolge vor: Passen Sie zuerst an, wie der Client Antworten ausliest, korrigieren Sie dann die Übersetzungsschicht und ziehen Sie erst zuletzt einen anderen Client oder ein zusätzliches Gateway in Betracht.
Nutzen Sie nach Möglichkeit das native Anthropic-Protokoll. Falls das nicht geht, lassen Sie Anfragen von einem Gateway ins Anthropic-Format übersetzen, statt dauerhaft bei der Chat-Kompatibilität zu bleiben. Über APIYI auf apiyi.com können Sie die Ergebnisse verschiedener Protokolle mit demselben API-Schlüssel vergleichen.
📚 Referenzen
- Codex-Konfigurationsreferenz: Beschreibung der Werte für wire_api
- Link:
developers.openai.com/codex/config-reference - Hinweis: Bestätigt, dass wire_api derzeit nur responses unterstützt
- Beispiel für einen Fehler beim Laden der Codex-Konfiguration
- Link:
github.com/openai/codex/issues/41816 - Hinweis: Quelle der ursprünglichen wire_api-Fehlermeldung
- Migrationsleitfaden für Claude Opus 5.5
- Link:
platform.claude.com/docs/en/models/opus-5-5/migration-guide - Hinweis: Verbindliche Einschränkungen für thinking, tool_choice und Sampling-Parameter
- Fehlerbehebung bei Anthropic-Tool-Aufrufen
- Link:
platform.claude.com/docs/en/agents-and-tools/tool-use/troubleshooting-tool-use - Hinweis: Regeln für die Zuordnung von tool_use und tool_result
- WorkBuddy-Modellkonfiguration
- Link:
www.workbuddy.ai/docs/zh/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Model - Hinweis: Zugang zur Einrichtung eigener Modelle und Schalter für benutzerdefinierte Protokolle
- Magpie-Repository
- Link:
github.com/yetone/magpie - Hinweis: Open-Source-Gateway der Community; bitte bewerten Sie die Risiken vor der Nutzung selbst
Autor: APIYI-Technikteam
Technischer Austausch: Kontaktieren Sie uns gerne über die Startseite von APIYI unter apiyi.com. Weitere Informationen finden Sie im Dokumentationszentrum unter docs.apiyi.com.
