-
Notifications
You must be signed in to change notification settings - Fork 50
Description
Description
Gemini 3 models (Flash and Pro) fail on multi-turn tool calling through OpenRouter. The root cause is that OpenRouter's OpenAI-compatible format translation strips thought_signature and reasoning_details from Gemini responses. When the client sends tool results back, Gemini rejects the request with MALFORMED_FUNCTION_CALL because the required thought_signature is missing.
This affects every framework using the OpenAI-compatible API with Gemini 3 via OpenRouter (CrewAI, LangChain, Cline, Cursor, Roo-Code, LobeHub, etc.).
How It Fails
- Client sends request with tool definitions to
google/gemini-3-flash-previewvia OpenRouter - Gemini responds with a function call +
thought_signaturein its native format - OpenRouter translates to OpenAI format, dropping
thought_signature - Client sends tool result back (without signature, since it was never received)
- Gemini rejects with
MALFORMED_FUNCTION_CALL— response is:
{
"choices": [{
"finish_reason": "error",
"native_finish_reason": "MALFORMED_FUNCTION_CALL",
"message": {"role": "assistant", "content": null}
}]
}Affected Models
google/gemini-3-flash-previewgoogle/gemini-3.1-pro-preview- Any Gemini 3+ model that requires
thought_signaturefor tool calling
Expected Behavior
OpenRouter should preserve thought_signature / reasoning_details in the OpenAI-compatible response format (e.g., via a provider_specific_fields or similar mechanism) so clients can echo them back in subsequent requests.
Impact
This is widely reported across the ecosystem:
- Cline #8850
- Roo-Code #10307
- LobeHub #10986
- Cherry Studio #11418
- Continue #8980
- Cursor Forum
- Google AI Forum
Gemini 3 tool calling is effectively unusable through OpenRouter's OpenAI-compatible API for any multi-turn agentic workflow.
Workaround
The only current workaround is to use Gemini's native API directly (bypassing OpenRouter), which preserves thought_signature natively.