Gemini 3.5 Flash on Vertex keeps warning about missing thought_signature

[andrewesweet]

Description

Using the google-vertex provider with gemini-3.5-flash, I keep getting this warning back from Vertex once a session involves more than one tool call:

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:read, position 11. Please refer to https://ai.google.dev/gemini-api/docs/thought-signatures for more details.

The session keeps working, it just yells about this every time. On 3.5 Flash it hits almost every multi-turn tool session I do. gemini-3-pro-preview gets it too on the same work, but a lot less often. I can't share the screenshot or the session for this report.

Plugins

None

OpenCode version

1.15.4

Steps to reproduce

1. Configure the google-vertex provider with valid Vertex AI credentials.
2. Wire up gemini-3.5-flash via a custom provider entry — OpenCode 1.15.4 doesn't ship the model natively, so it has to be added through opencode's custom provider config.
3. Start a session and do anything that takes two or more tool calls. /commit works, or just ask it to read one file and grep another.
4. Look at the second turn (or any later one). The warning shows up under the tool call.

Screenshot and/or share link

No response

Operating System

macOS

Terminal

tmux inside kitty

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Gemini 3 issue : Function call is missing a thought_signature in functionCall parts #4481: Same error message ("Function call is missing a thought_signature in functionCall parts") with Gemini models and tool calls — closed
• Support for thought_signature in openai-compatible provider #8321: Open issue requesting thought_signature support in the openai-compatible provider, same underlying root cause
• [BUG]: Gemini 3 Pro function calling fails - missing thoughtSignature support #4832: Closed bug report about Gemini 3 Pro function calling failing due to missing thoughtSignature support

If your issue is distinct (e.g. specific to the google-vertex provider or a regression in a newer version), please clarify how it differs from the above.

[rekram1-node]

Can u send me a session this happened in? opencode export > session.json

[bzarboni1]

Can u send me a session this happened in? opencode export > session.json

I'm not OP, but I'm running into the same problem - session attached.

session.json

[rekram1-node]

Okay but ur not using vertex provider directly, what api is ur agentgateway provider using? Because there is a good chance that it is at fault here

[bzarboni1]

Okay but ur not using vertex provider directly, what api is ur agentgateway provider using? Because there is a good chance that it is at fault here

apiVersion: agentgateway.dev/v1alpha1
kind: AgentgatewayBackend
metadata:
  name: agent-platform
  namespace: agentgateway-system
spec:
  ai:
    provider:
      vertexai:
        model: google/gemini-3.1-pro-preview@default
        projectId: prj-host
        region: global
  policies:
    auth:
      gcp:
        type: AccessToken
    ai:
      routes:
        "/v1/chat/completions": "Completions"
        "*": "Passthrough"

[bzarboni1]

FYI - Co-pilot thinks this is a bug. Not sure if its helpful:

Yes — this looks like a real bug in opencode's Gemini protocol adapter.

The short version: thoughtSignature is defined in the Gemini wire schema, but it is never actually preserved when opencode parses Gemini responses and then replays prior assistant/tool-call messages back to Gemini. So when Gemini emits reasoning with a signature and then a tool call, the next request can resend the tool call without the required thought_signature, which matches your Vertex error.

The strongest evidence is here:

const GeminiTextPart = Schema.Struct({
  text: Schema.String,
  thought: Schema.optional(Schema.Boolean),
  thoughtSignature: Schema.optional(Schema.String),
})

const GeminiFunctionCallPart = Schema.Struct({
  functionCall: Schema.Struct({
    name: Schema.String,
    args: Schema.Unknown,
  }),
  thoughtSignature: Schema.optional(Schema.String),
})

But when prior assistant messages are lowered back into Gemini request parts, opencode only sends text/reasoning/tool-call content and drops any signature field:

const lowerToolCall = (part: ToolCallPart) => ({
  functionCall: { name: part.name, args: part.input },
})

...

if (part.type === "reasoning") {
  parts.push({ text: part.text, thought: true })
  continue
}
if (part.type === "tool-call") {
  parts.push(lowerToolCall(part))
  continue
}

That means:

• the schema accepts thoughtSignature
• the stream parser reads Gemini parts
• but the parsed LLMEvents / stored message parts do not carry thoughtSignature
• and later request lowering cannot resend it

The parser path confirms that signatures are not propagated into common events or message parts:

for (const part of candidate.content.parts) {
  if ("text" in part && part.text.length > 0) {
    lifecycle = part.thought
      ? Lifecycle.reasoningDelta(lifecycle, events, "reasoning-0", part.text)
      : Lifecycle.textDelta(lifecycle, events, "text-0", part.text)
    continue
  }

  if ("functionCall" in part) {
    const input = part.functionCall.args
    const id = `tool_${nextToolCallId++}`
    lifecycle = Lifecycle.stepStart(lifecycle, events)
    events.push(LLMEvent.toolCall({ id, name: part.functionCall.name, input }))
    hasToolCalls = true
  }
}

No thoughtSignature is attached to either:

• reasoning events
• tool call events

And the canonical message schema only has generic metadata/providerMetadata fields, with no Gemini-specific first-class signature preservation:

export const ToolCallPart = Object.assign(
  Schema.Struct({
    type: Schema.Literal("tool-call"),
    id: Schema.String,
    name: Schema.String,
    input: Schema.Unknown,
    providerExecuted: Schema.optional(Schema.Boolean),
    metadata: Schema.optional(Schema.Record(Schema.String, Schema.Unknown)),
    providerMetadata: Schema.optional(ProviderMetadata),
  }).annotate({ identifier: "LLM.Content.ToolCall" }),

So my confidence is high: the bug is not that the field is missing from the schema; it's that it is not propagated through the internal event/message model and therefore not replayed on subsequent Gemini requests.

Why your specific config hits it

Your model config enables Gemini thinking:

{
  "provider": {
    "agentgateway": {
      "models": {
        "gemini-3.1-pro-preview": {
          "options": {
            "thinking": {
              "type": "enabled",
              "budgetTokens": 16000
            }
          }
        }
      }
    }
  }
}

When thinking is enabled, Gemini/Vertex can require thought signatures to accompany subsequent tool-call content in multi-turn continuation. If opencode strips them, Vertex rejects the replayed request with exactly the error you saw.

One nuance

Your config is using an OpenAI-compatible provider wrapper (@ai-sdk/openai-compatible) pointed at a Vertex-like endpoint, not the native packages/llm/src/protocols/gemini.ts route directly. So the exact failing path in your runtime may involve the AI SDK adapter too. But the repository code you pointed to does contain a real signature propagation gap in the native Gemini protocol, and that gap is fully consistent with the error. The AI SDK bridge also maps reasoning/tool-call events without any Gemini thought-signature handling. So even if the request enters through another adapter, the same underlying omission likely exists there too.

Practical workaround

Until fixed, try one of these:

1. Disable thinking/reasoning for that Gemini model.
2. Avoid tool use with thinking-enabled Gemini on this path.
3. If possible, use a provider path that does not require replaying Gemini thought signatures.

Proper fix

The fix likely needs all of these:

• parse thoughtSignature from Gemini text/function-call parts
• store it in providerMetadata or a dedicated field on reasoning/tool-call content
• preserve it in session/message persistence
• re-emit it in lowerMessages / lowerToolCall when rebuilding Gemini contents

[rekram1-node]

Lol copilot isnt even reading the right code path, that code path isnt enabled so it's not true

[bzarboni1]

To close the loop - it was an AgentGateway issue. Resolved with this comment: agentgateway/agentgateway#1544 (comment)

[andrewesweet]

I am using the google-vertex provider, so doesn't help me, sadly. My sessions have all been on corporate devices, so I can't share them. I'll try to repro on a personal device.

[rekram1-node]

@andrewesweet ur issue did say this:

Wire up gemini-3.5-flash via a custom provider entry — OpenCode 1.15.4 doesn't ship the model natively, so it has to be added through opencode's custom provider config.

Are u using the native google vertex provider? Gemini 3.5 flash is included for that

[andrewesweet]

It wasn't included when I was trying it the day after GA. It's the native provider.

[rekram1-node]

gotcha