thought_signature

[mohamedDev]

Hello,

With ai-proxy, since the OpenAI-compatible API does not expose an equivalent field, the gateway cannot currently generate or reconstruct this value automatically during request translation.

Supporting this would require provider-specific state management within the gateway to capture the thought_signature from Gemini responses and re-inject it into subsequent tool calls, which is not supported today.

@dosu, how can we move forward?

[dosubot[bot]]

Hey @mohamedDev,

You've correctly identified the core challenge — the ai-proxy plugin is stateless by design, processing each request independently with no session-level context preserved between calls [1]. There's no mechanism today to capture a field like thought_signature from a Gemini response and automatically re-inject it into a subsequent request.

Here are the potential paths forward:

1. Client-side management (workaround, works today)
The simplest approach: have your client capture thought_signature from Gemini responses and include it in the next request body. Since model_options allows arbitrary key-value pairs via additionalProperties = true [2], and the plugin merges these into the upstream request [3], the field can pass through to Gemini if the client includes it explicitly.

2. Provider-specific hook in the newer architecture
The plugin's recent three-layer architecture [4] introduced provider-aware rewrite_request_body hooks [5] and explicit field whitelisting [6]. A Gemini-specific hook could potentially be written to handle thought_signature mapping — but this still wouldn't solve the statefulness problem since hooks operate per-request.

3. Feature request for stateful session support
Supporting this properly would require a new capability: request-scoped or session-scoped state storage within the gateway (e.g., using shared memory or an external store like Redis) to persist provider-specific response fields and inject them into subsequent requests. This would be a significant architectural addition.

If you'd like to move this forward as a feature, I'd suggest opening a GitHub issue describing the use case (Gemini tool calls requiring thought_signature continuity) and proposing either option 2 or 3. There are no existing issues or PRs tracking this specific need today.

In the meantime, option 1 (client-side management) is the most practical path.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.