Skip to main content

Was Extra Content ist

Manche Provider hängen an eine Antwort einen undurchsichtigen Zustand an und erwarten ihn im nächsten Turn unverändert zurück. Gemini 3 signiert seine Function Calls mit einer Thought Signature und lehnt einen Verlauf ab, der den Call ohne sie erneut sendet. Anthropic verlangt die Thinking-Blöcke eines Assistant-Turns, einschließlich Signaturen, vor einem fortgesetzten Tool-Use-Turn. Für einen solchen Zustand gibt es kein OpenAI-kompatibles Feld, daher transportiert GoModel ihn an einer einzigen Stelle: in einem extra_content-Objekt, das nach Anbieter (Vendor) geschlüsselt ist.
GoModel speichert nichts. Der Zustand reist in der Response zum Client und kommt im Nachrichtenverlauf des Clients zurück. Clients, die Assistant-Nachrichten unverändert in den Verlauf kopieren, wie es die SDKs für OpenAI, Anthropic und die Responses API tun, benötigen keine Änderungen. Die Struktur entspricht Googles eigenem OpenAI-kompatiblen Endpunkt, sodass Clients, die dafür entwickelt wurden, unverändert funktionieren.

Wo es vorkommt

Der Zustand sitzt auf der Einheit, die genau einem Provider-Part entspricht. Ein Tool Call wird zu einem Gemini-part, daher liegt eine Signatur pro Call auf dem Tool Call. Thinking-Blöcke gehören zum gesamten Assistant-Turn, daher liegen sie auf der Nachricht.

Regeln

  • Jede Übersetzung reicht es durch. Eingehende Chat-, Responses- und Anthropic-Messages-Requests, Streaming und das Echo des Assistant-Turns transportieren extra_content, ohne hineinzusehen.
  • Nur der zuständige Provider sieht seinen eigenen Vendor. Bevor ein Request an einen Provider geht, entfernt GoModel jedes Vendor-Objekt, das nicht zu diesem Provider gehört. Eine Gemini-Signatur erreicht nie Anthropic oder OpenAI, und ein Verlauf, der zwischen Providern gewechselt ist, scheitert nicht an fremden Feldern.
  • Nur der zuständige Adapter liest oder schreibt darin. Nichts anderes im Gateway interpretiert den Inhalt.
  • Geben Sie es unverändert zurück. Schreiben Sie das Feld nicht um, ordnen Sie es nicht neu und kürzen Sie es nicht.

Erhalt von Thought Signatures

Gemini 3 hängt an die von ihm erzeugten Function Calls eine verschlüsselte thoughtSignature an. Der nächste Request muss dieselbe Signatur auf demselben Call mitführen, sonst antwortet Gemini mit HTTP 400 „Function call is missing a thought_signature“. Ein Tool-Call-Turn über Chat Completions sieht so aus. Gezeigt werden nur die relevanten Felder.
1

Der Client stellt eine Frage, für die ein Tool verfügbar ist

2

Gemini antwortet mit einem Function Call und einer Signatur

GoModel übersetzt den Request in Geminis natives generateContent-Format. Gemini gibt einen functionCall-Part zurück, der die Signatur trägt.
3

GoModel gibt den Call mit der Signatur unter extra_content zurück

4

Der Client führt das Tool aus und sendet den vollständigen Verlauf zurück

Die Assistant-Nachricht wird so angehängt, wie sie empfangen wurde, daher kommt extra_content automatisch mit.
5

GoModel spielt die Signatur auf dem passenden Gemini-Part erneut ein

Gemini akzeptiert das Replay und antwortet mit Text. GoModel gibt eine normale Chat Completion zurück.
Dasselbe Feld erscheint auf gestreamten tool_calls-Deltas, auf function_call-Items der Responses API, auf tool_use-Blöcken der Anthropic Messages API und, bei reinen Text-Turns, auf der Assistant-Nachricht selbst. In der Responses API reist die Signatur eines reinen Text-Turns auf einem reasoning-Output-Item vor der Nachricht, ohne eigenen Reasoning-Text; geben Sie das Item zurück, und die Signatur landet auf dem Assistant-Turn. Nur der erste Call eines parallelen Batches trägt eine Signatur. Eine flache thought_signature oder thoughtSignature auf dem Tool Call wird ebenfalls akzeptiert, sodass Clients, die für andere Gateways entwickelt wurden, weiterhin funktionieren. Enthält ein Gemini-3-Verlauf einen Function Call ganz ohne Signatur, weil die Konversation bei einem anderen Provider begonnen hat oder ein Client das Feld verworfen hat, sendet GoModel den von Google dokumentierten Platzhalter, statt den Fehler 400 durchzureichen. Geben Sie den echten Wert zurück, wann immer Sie ihn haben; der Platzhalter kostet für diesen Turn die Reasoning-Kontinuität. Provider-Details finden Sie unter Gemini-Thought-Signatures.

Thinking-Blöcke

Anthropics Extended Thinking liefert thinking- und redacted_thinking-Content-Blöcke in einem Assistant-Turn. Endet dieser Turn mit einem Tool Call, muss der Folge-Request diese Blöcke, einschließlich Signaturen, vor dem tool_use-Block erneut senden. Über die Anthropic Messages API sieht der Ablauf so aus:
1

Der Client sendet einen Verlauf, der Thinking-Blöcke enthält

2

GoModel bewahrt die Blöcke unter extra_content.anthropic auf

Intern hat der Verlauf Chat-Form. Die Thinking-Blöcke reisen auf der Assistant-Nachricht mit und is_error auf dem Tool-Ergebnis. Für keines von beiden gibt es ein OpenAI-kompatibles Feld, daher liegen beide unter dem Vendor anthropic. is_error wird nur geschrieben, wenn das Ergebnis fehlgeschlagen ist.
3

Anthropic erhält die Blöcke unverändert

Landet die Route bei Anthropic, werden die Thinking-Blöcke genau so, wie sie gesendet wurden, wieder vor den tool_use-Block gesetzt, und is_error wird auf dem tool_result wiederhergestellt. Jeder andere Provider erhält nur den Tool Call und den Ergebnistext.

Auf dem Rückweg

Anthropic signiert jeden Thinking-Block, den es zurückgibt, und lehnt einen späteren Turn ab, der einen solchen Block ohne seine Signatur erneut sendet:
Deshalb reisen die Blöcke auf demselben Weg zum Client hinaus, auf dem sie hereinkommen. Die Anthropic Messages API gibt sie als echte Content-Blöcke einschließlich Signatur aus, denn genau das sendet ein Anthropic-Client zurück:
Beim Streaming wird die Signatur als signature_delta innerhalb des Thinking-Blocks gesendet, bevor dieser geschlossen wird, genau wie bei Anthropic.

Reasoning von Providern, die es nicht signieren

DeepSeek, Fireworks und andere Provider liefern Reasoning-Text ohne etwas, das ihn authentifiziert. Die Anthropic Messages API gibt ihn trotzdem als thinking-Block aus, mit signature: "" – das Schema kennzeichnet das Feld als erforderlich, sodass ein streng typisierter Client einen Block ohne dieses Feld ablehnen würde. Beim Streaming wird der Block mit einer leeren Signatur geöffnet und kein signature_delta gesendet; das ist die Form, die Anthropic selbst streamt, bevor die echte Signatur eintrifft. Geben Sie den Turn unverändert zurück: Der Block wird an diesen Provider wie jeder andere erneut gesendet. Anthropic akzeptiert nur Signaturen, die es selbst ausgestellt hat (eine fehlende scheitert mit signature: Field required, alles andere mit Invalid `signature` in `thinking` block). Wird ein solcher Verlauf zu Anthropic geroutet, wird der unsignierte Block daher verworfen und der Rest des Turns wie gewohnt gesendet. Die anderen Dialekte haben keinen Thinking-Block, daher transportieren sie dieselben Daten unter extra_content.anthropic.thinking_blocks – in Chat Completions auf der Assistant-Nachricht, in der Responses API auf dem reasoning-Output-Item. Gestreamte Chat-Deltas tragen den Wert, sobald der Thinking-Block abgeschlossen ist, vor jeglichem Text, und er ist kumulativ: Der zuletzt gesehene Wert enthält den gesamten Turn.
reasoning_content bleibt, was es immer war: der lesbare Text, der nicht erneut gesendet werden muss. Ein redacted_thinking-Block hat überhaupt keinen lesbaren Text, daher ist extra_content das Einzige, was ihn transportiert. Hängen Sie den Assistant-Turn so an den Verlauf an, wie Sie ihn empfangen haben, dann erfolgt das Replay automatisch. Wird dieser Verlauf zu einem anderen Provider geroutet, wird das Feld verworfen, wie jedes fremde Vendor-Objekt, und die Konversation läuft ohne es weiter.

Einen Verlauf zwischen Providern verschieben

Eine Konversation kann bei einem Provider beginnen und bei einem anderen fortgesetzt werden. Die Regel ist einfach: Jedes Vendor-Objekt, das nicht zum Ziel-Provider gehört, wird vor dem Versand entfernt, auf jeder Route und in jedem Dialekt. Der eigene Verlauf des Clients wird nie verändert. Die Filterung erfolgt auf der Kopie, die GoModel an den Upstream sendet.

Vendor-Referenz

Zuletzt geändert am 24. Oktober 2026