#need help

4 messages · Page 1 of 1 (latest)

half hollyBOT
#

I'm an AI assistant - my answers may be incorrect and I cannot see screenshots. Please verify information with the OpenRouter docs.

Thanks for your detailed report! To help debug and escalate this Gemini tool/function-calling issue, I need a bit more information:

  1. What is the exact model identifier you're using (e.g., google/gemini-3.1-pro-preview, google/gemini-2.5-pro-preview, etc.)?
  2. Can you provide the full error message or API response you receive when function-calling fails?
  3. Could you share the relevant code snippet or API call (especially the payload being sent when tool-calling is enabled)?

These details are critical for the support/mod team to diagnose the compatibility and protocol handling issue. If you need to check exact model names, refer to OpenRouter Models.

-# This is an automated response powered by Answer HQ. Use !mute to stop the bot from responding, or !close when your question is resolved.

#

Thank you for providing detailed diagnostics. Here’s a technical handoff summary for mods/support:

1. Model identifiers used:

  • Before fix/default env: gemini-1.5-flash (stale alias, not supported for function-calling)
  • CLI test: --model gemini (now resolves to gemini-3-flash-preview)
  • Endpoint: Google OpenAI-compatible base (.../v1beta/openai/)

2. Errors during function-calling:

  • error: api returned 404 Not Found
  • models/gemini-1.5-flash is not found for API version v1main, or is not supported for generateContent
  • error: api returned 400 Bad Request
  • Function call is missing a thought_signature in functionCall parts.

3. Example request shape:

{
  "model": "gemini-... (resolved alias)",
  "messages": [...],
  "system": "...",
  "tools": [ { "type": "function", "function": { "name": "...", "parameters": {...} } } ],
  "tool_choice": "auto",
  "stream": true
}

4. Root cause analysis:

  • Initial 404: Alias/model mismatch; gemini-1.5-flash not a valid/active endpoint.
  • 400 Bad Request: Gemini expects a thought_signature in functionCall parts (per protocol), but the runtime sends OpenAI-style tool calls without this, causing incompatibility.

5. Current mitigation:

  • Disable tools for Gemini calls (text-only). Prompt-only requests succeed; tool/function-calling remains unsupported until thought-signature-compatible logic is added.

Relevant documentation:

  • Gemini 3.1 Pro Preview supports advanced tool orchestration, but "Reasoning Details must be preserved when using multi-turn tool calling" Gemini 3.1 Pro Preview
  • Gemini 3 Flash Preview: "supports...tool use," but OpenAI-style tool calls may not be fully compatible [Gemini 3 Fl...
#

...ash Preview](https://openrouter.ai/google/gemini-3-flash-preview)

If you need to check available Gemini models and their exact identifiers, refer to Google Models on OpenRouter.

For runtime maintainers/mods:

  • Tool/function handling with Gemini models requires protocol compatibility (including thought_signature)
  • Until runtime is updated, Gemini models should be used in text-only mode for stability

If further escalation is needed, please share this summary with the mod/dev team.

-# This is an automated response powered by Answer HQ. Use !mute to stop the bot from responding, or !close when your question is resolved.

#

You're correct—Gemini models, especially Gemini 3 Pro and related variants, require that "Reasoning Details must be preserved when using multi-turn tool calling." This means the function-calling protocol must maintain Gemini-specific fields (such as thought_signature) instead of relying solely on the OpenAI-style tool payloads.

If the runtime sends generic OpenAI tool calls without Gemini-compatible reasoning blocks, errors like 400 Bad Request or "Function call is missing a thought_signature" will continue. To avoid these errors, tool-calling should remain disabled for Gemini until thought-signature-compatible support is added in your integration.

Direct quote:
"Reasoning Details must be preserved when using multi-turn tool calling, see our docs here: [https://openrouter.ai/docs/use-cases/reasoning-tokens#preserving-reasoning-blocks](https://openrouter.ai/docs/use-cases/reasoning-tokens#preserving-reasoning-blocks)" Gemini 3 Pro Preview

You can review the full requirements and compatible protocol details in the Reasoning Tokens Docs. Until the runtime natively supports Gemini's tool-call conventions, text-only turns are the stable mitigation.

-# This is an automated response powered by Answer HQ. Use !mute to stop the bot from responding, or !close when your question is resolved.