Gemini tool calling fails with HTTP 400: `thought_signature` is discarded when decoding `functionCall` parts

[NoWaY233851]

Summary

Multi-turn tool calling with GeminiLanguageModel fails with HTTP 400 on Gemini 2.5+ models. Gemini attaches a thought_signature to each functionCall part and requires it to be echoed back verbatim when function results are returned. GeminiPart's decoder explicitly drops it, so the follow-up request is rejected and the tool loop can never complete.

Reproduction

1. Create a GeminiLanguageModel (default init) with a thinking-capable model — reproduced on Gemini 2.5.
2. Create a LanguageModelSession with at least one Tool.
3. Call respond(to:) with a prompt that requires the tool.

The first request succeeds and the tool executes; the second request (returning the function result) fails.

Actual result

{"error":{"code":400,"status":"INVALID_ARGUMENT","message":
 "Function call is missing a thought_signature in functionCall parts.
  This is required for tools to work correctly, and missing thought_signature
  may lead to degraded model performance.
  Additional data, function call `default_api:web_search`, position 2.
  Please refer to https://ai.google.dev/gemini-api/docs/thought-signatures for more details."}}

Root cause

Sources/AnyLanguageModel/Models/GeminiLanguageModel.swift — GeminiPart.init(from:):

} else if container.contains(.functionCall) {
    // Note: thoughtSignature may be present but is ignored
    self = .functionCall(try container.decode(GeminiFunctionCall.self, forKey: .functionCall))
}

CodingKeys declares case thoughtSignature, but it is never decoded, never stored, and never re-encoded. When the request is rebuilt from the transcript, only GeminiFunctionCall(name:args:) is constructed, so there is nowhere for the signature to live.

This code is unchanged on main (verified against 0.9.0 — the file has not been modified since 226542d, 2026-03-23).

Why consumers cannot work around it

The signature never reaches any type visible to library consumers. Unlike the Anthropic path — where the transcript passed to a follow-up session is consumer-constructed and can be adjusted — Gemini requests are assembled entirely inside GeminiLanguageModel, so there is no injection point.

Related: .disabled does not actually disable thinking

The natural workaround is to turn thinking off, since no thinking means no signature. That currently doesn't work through the public API:

if case .disabled = thinking {
    thinkingConfig["includeThoughts"] = .bool(false)
} else {
    thinkingConfig["includeThoughts"] = .bool(true)
    if let budget = thinking.budgetValue { thinkingConfig["thinkingBudget"] = .int(budget) }
}

.disabled only sets includeThoughts: false, which suppresses thought summaries — the model still thinks and still emits signatures. thinkingBudget is never sent on that branch, so Thinking.budgetValue's case .disabled: return 0 is unreachable here. Consumers must pass .budget(0) to get thinkingBudget: 0 onto the wire, which reads as a bug given the case is named .disabled.

(This workaround is also limited: Gemini 2.5 Pro has a minimum thinking budget and Gemini 3 uses thinking_level, so budget 0 is not universally available.)

Suggested fix

Preserve thoughtSignature on GeminiPart.functionCall when decoding, carry it through the transcript representation, and re-encode it on subsequent requests. Google's guidance is that the field must be returned unchanged.

Separately, consider making .disabled send thinkingBudget: 0 so the case matches its name.

Context

This affects every client that manages conversation history itself; several other projects have hit the same wall:

• InvalidArgument: 400 Function call is missing a thought_signature with Gemini 3 and create_react_agent langchain-ai/langchain-google#1364
• [Gemini] Function Calls fail with 400 Error: "missing thought_signature in functionCall parts" aaif-goose/goose#5792
• [Bug]: Gemini 2.5 Flash multi-turn function calling fails with "Please ensure that the number of function response parts is equal to the number of function call parts" BerriAI/litellm#17949
• Gemini API Error 400: Missing thought_signature in functionCall parts musistudio/claude-code-router#1431

Environment: AnyLanguageModel 0.9.0, Swift 6.1, macOS/iOS 27.

[NoWaY233851]

Follow-up: this reproduces on a current model, and the obvious workaround is blocked by a second gap in the same adapter.

Still failing on gemini-3.6-flash

gemini-2.5-flash now 404s for new users ("no longer available to new users… use models/gemini-3.6-flash"), and the failure carries over unchanged:

HTTP 400 {"error":{"code":400,"status":"INVALID_ARGUMENT","message":
 "Function call is missing a thought_signature in functionCall parts...
  Additional data, function call `default_api:web_search`, position 2."}}

Disabling thinking isn't available either

No thinking means no signature, but neither half of that works here:

• .disabled doesn't disable thinking. It only sets includeThoughts: false; thinkingBudget is never sent on that branch, so Thinking.budgetValue's case .disabled: return 0 is unreachable. A consumer must pass .budget(0) to get a budget onto the wire.
• thinkingBudget isn't accepted by Gemini 3, which uses thinking_level. GeminiLanguageModel only ever writes includeThoughts and thinkingBudget, so there is no way to turn thinking off on these models through the library.

Measured both ways

Same model, same tools, one variable:

Request	Result
With thinkingBudget: 0 (via .budget(0))	400 "Request contains an invalid argument."
Without it (default .disabled)	400 missing thought_signature

Tool calling with Gemini is therefore unusable through AnyLanguageModel regardless of configuration. We've had to disable it for Gemini while keeping it for Apple on-device, OpenAI-compatible, Anthropic, and Ollama, which all work.

Suggested scope

1. Preserve thoughtSignature on GeminiPart.functionCall when decoding, carry it through the transcript, re-encode it on subsequent requests.
2. If that isn't quick: add thinking_level support, or make .disabled send thinkingBudget: 0 where accepted — either restores a usable fallback.

[mattt]

Thanks for reporting, @NoWaY233851, and for pinning down the exact line. Would you like to open a PR that preserves thoughtSignature on GeminiFunctionCall and echoes it back? If not, I'll take care of it this week.

[NoWaY233851]

@mattt , Happy to take it. One thing worth settling first: preserving thoughtSignature on GeminiFunctionCall fixes the decode, but the signature is dropped a second time on the way back out. Every iteration of the tool loop rebuilds the request from the transcript, and Transcript.ToolCall has nowhere to hold it (GeminiLanguageModel.swift:789). Later turns too, since LanguageModelSession.respond merges transcriptEntries back into the session.

Two shapes, both implemented and green against main:

1. Adapter-local. Thread the signature from the decoded response to the rebuilt request inside respond(...). No public API change, +55/−12 in one file. Fixes the tool loop, but a transcript that outlives the call — a later turn, or one persisted and restored — still replays its calls unsigned.

2. Transcript-carried. Transcript.ToolCall gains providerMetadata: [String: String]? and the adapter keeps the signature there. It needs no plumbing, so it comes out smaller than (1) — +45/−5 — and covers the later-turn replay too. The cost is one public property on a type that mirrors FoundationModels'. It's optional, so transcripts encoded before it still decode.

I'd send (2): Anthropic's encrypted_content and the Responses API's encrypted reasoning items will want the same slot. But it's your public surface — say which you'd prefer and I'll open the PR. (1) is ready as-is if you'd rather keep Transcript identical.

Either way the tests are offline: a small URLProtocol stub records request bodies and replays canned responses, so the Gemini tool path gets covered without GEMINI_API_KEY and the wire types stay private.