Google Gemini-Argon-4 tool-call replay drops thought_signature in openai-completions

[qaica]

Problem

Using a Google Argon 4 model through the OpenAI-compatible endpoint
(https://generativelanguage.googleapis.com/v1beta/openai/), the second turn of
a tool call fails with HTTP 400:

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:get_weather`, position 2.

Google streams the required signature inside the tool-call delta:

"tool_calls":[{
  "extra_content":{"google":{"thought_signature":"ElkKVwFpFH0TGJVw..."}},
  "function":{"arguments":"{\"city\":\"Toronto\"}","name":"get_weather"},
  "id":"call_3209665","type":"function"
}]

pi-ai's openai-completions adapter drops extra_content while streaming and
never re-emits it when replaying the assistant tool call, so the signature is lost
and Google rejects turn 2.

A second, smaller issue: Google returns error bodies as a one-element JSON array
[{error:{...}}] rather than {error:{...}}. The OpenAI SDK reads
errorResponse['error'], gets undefined, and the whole turn collapses into the
opaque 400 status code (no body).

Proposed patch

Two pnpm patches, both verified with git apply --check against the published
tarballs (@earendil-works/pi-ai@1.1.0, openai@7.19.0).

1. Extend patches/@earendil-works__pi-ai@1.1.0.patch

In dist/api/openai-completions.js, capture the signature in
ensureToolCallBlock:

@@ -348,6 +348,16 @@ export const stream = (model, context, options) => {
                     delete block.partialArgs;
                 }
+                // Google streams the thought_signature in
+                // extra_content.google.thought_signature. Capture it for replay.
+                const extraThoughtSignature = toolCall.extra_content?.google?.thought_signature;
+                if (extraThoughtSignature && !block.thoughtSignature) {
+                    block.thoughtSignature = extraThoughtSignature;
+                }
                 return block;

and re-emit it in convertMessages:

@@ -1038,6 +1047,13 @@ export function convertMessages(model, context, compat, options) {
                             arguments: JSON.stringify(tc.arguments),
                         },
+                        ...(tc.thoughtSignature
+                            ? { extra_content: { google: { thought_signature: tc.thoughtSignature } } }
+                            : {}),
                     };

block.thoughtSignature already exists on ToolCall, is already persisted by the
assistant-message frame, and is already stripped by transform-messages.ts when
the model changes -- so no new serialization or cross-model guard is needed.

2. New patches/openai@7.19.0.patch

In core/error.mjs (and core/error.js), unwrap the array in
APIError.generate:

-        const error = errorResponse?.['error'];
+        const body = Array.isArray(errorResponse) ? errorResponse[0] : errorResponse;
+        const error = body?.['error'];

Register it in pnpm-workspace.yaml:

  openai@7.19.0: patches/openai@7.19.0.patch

Verification

• Both patches pass git apply --check against the published tarballs.
• End-to-end in a local DSH install: a Google tool call now survives turn 2, and a
  forced failure surfaces Function call is missing a thought_signature ...
  instead of 400 status code (no body).
• patchedDependencies and pnpm-lock.yaml (patch hashes + snapshot patch_hash
  values) were regenerated to match; the lockfile parses cleanly.

Ask

Either apply the two patches at the pinned versions, or take the equivalent change
upstream in earendil-works/pi (packages/ai/src/api/openai-completions.ts) so a
future pin bump carries it. Happy to split this into the pi-ai-only change if the
openai patch is out of scope.

[PerryLink]

Your diagnosis is correct, and it is confirmed directly against the published @earendil-works/pi-ai@1.1.0 tarball.

The drop is real

In dist/api/openai-completions.js, the stream loop builds each tool call through ensureToolCallBlock (:296), used at :428. Searching the whole file for extra_content and thought_signature returns zero hits — the adapter never reads the field while streaming and has nowhere to keep it, so it cannot re-emit it on replay. That matches your read exactly.

The consequence is structural rather than incidental: the signature arrives on the same delta that creates the block, and the block is the only thing carried forward, so the information is destroyed at first contact rather than lost on the way back out.

One correction to the patch framing

Your diff extends patches/@earendil-works__pi-ai@1.1.0.patch, which is the right short-term move, but note that the repo's dependency is "@earendil-works/pi-ai": "^1.1.0" and npm's latest for that package is now 1.3.0. A patch pinning 1.1.0 fixes your install and silently stops applying for anyone resolving to 1.2.x/1.3.x — pnpm will either refuse the patch or, worse, apply it to a file whose offsets have moved. Check the same three regions in 1.3.0 before you propose carrying it; for what it is worth, the clamp and estimator code I compared between 1.1.0 and 1.3.0 was byte-identical, so the openai-completions stream loop may well be unchanged too.

On the second issue (error body shape)

The one-element array [{error:{...}}] collapsing into 400 status code (no body) is a plausible read of the SDK path, but I would separate it in the report. The first issue is a data-loss bug in the adapter you can patch; the second is an error-surfacing weakness in the OpenAI SDK (openai@7.19.0) plus how pi-ai consumes it. Different upstream, different fix, and bundling them makes the patch look like it changes two unrelated things.

A cheaper alternative worth mentioning alongside the patch

toolCall blocks already carry optional adapter metadata in this harness — replay.ts round-trips thoughtSignature and namespace per block (:104-105, restored at :212-213 in the tool-call case). So the harness side is not what is blocking you; the field never reaches it because pi-ai dropped it first. That is worth stating explicitly, because it rules out "the harness lost my signature" as a hypothesis for anyone else hitting this, and it tells the pi-ai maintainer that the fix belongs entirely on their side of the seam.