Requests and responses captured via mitmweb from interacting with the GH Copilot agent in VSCode. Some of the implications I discuss are Zed-specific but the behavior itself should be replicable for the OpenCode issue.

Note that responses, of course, used SSE, but I took the liberty of converting them to JSON lists so I could have syntax highlighting and Prettier.

Conversation basically went like this, by request:

1. I asked the query "Read the README (only make ONE tool call) and tell me what the next item on roadmap is". The agent thought for a bit then responded with a tool call to read the README file.
2. The harness filled in the tool call output and called the completions API again. The agent responded with the correct response, "The next item on the roadmap is Python V5 API."
3. (intermediate query by the harness to generate a "pithy" title for the chat, not included)
4. I responded with the query "Thanks!", to which the model thought for a bit then responded with "You're welcome! Let me know if you have any other questions about the roadmap or the codebase."

I asked a few other queries afterwards to ensure the observed behaviors were consistent but this is the core stuff.

Here's the core behavior, from VSCode's point of view:

• During one query: (By query, I refer to the time between a user query and the final agent turn, this includes all tool calls. a query can contain multiple requests based on tool calls.)
  • Keep track of the reasoning_text of model parts, joining them into a single string (they each have newlines on the end so no need to add a separator).
  • Keep track of the reasoning_opaque property of the final SSE packet ONLY if the finish reason is tool_calls (otherwise, returning them is not mandatory).
  • Once the response is complete, add the assistant tool call message as usual to the list of messages, BUT add the reasoning_opqaue property with the signature collected in the previous step, and add the reasoning_text property with the joined texts from the first step. See 2-req.json:24-39.
  • Once the tool call result is computed, add the result message to the list of messages as usual and send back to the model provider.
• Notably, this doesn't require persisting thought signatures across queries, or even requests, afaict; they just need to be stored locally before the response ends, after which they are added to the message list and can be forgotten forever. I confirmed this; in all requests in my testing, only the most recent assistant message will have the reasoning_opaque and reasoning_text properties, and even then, only if it is a tool call message, although I assume it will be fine for us to keep the properties in previous assistant messages since it's simpler for implementation.
• Obviously, refer to the logs for precise implementation information.

TL;DR: Keep track of the text and signatures from the response and incorporate them into the tool call request message that you add to your message list for the next response (separate from the tool call output message).

Some other notes

• As seen in 4-res, there is also opaque reasoning for the end of a turn where no function calls occurred, but VSC doesn't seem to do anything with that. I confirmed it's not sent again in the next request. This matches the Gemini docs:

Gemini 3 Pro and Gemini 2.5 models behave differently with thought signatures in function calls:

• If there are function calls in a response,
  • Gemini 3 Pro will always have the signature on the first function call part. It is mandatory to return that part.
  • Gemini 2.5 will have the signature in the first part (regardless of type). It is optional to return that part.
• If there are no function calls in a response, * Gemini 3 Pro will have the signature on the last part if the model generates a thought. [implied that it is not mandatory to return]
  • Gemini 2.5 won't have a signature in any part.

• As noted above, this can be used to implement thinking traces for Gemini 3 Pro on Copilot! It's worth looking into whether other Copilot models return thinking traces so we can add them as appropriate.