bug(model): OpenAI-compatible streaming fails after tool calls when assistant content is omitted

[DemonswhisperYe]

Problem

OpenAI-compatible streaming requests can fail on the second turn after a tool call when the historical assistant tool-call message omits content.

Observed provider error:

{"error":{"message":"Instructions are required","type":"invalid_request_error"}}

The error is misleading: the request does include a system message/instructions. The failure is triggered by the serialized assistant tool-call history shape.

Reproduction shape

A multi-turn streaming request after one tool call can contain a historical assistant message like this:

{
  "role": "assistant",
  "tool_calls": [
    {
      "id": "call_test_1",
      "type": "function",
      "function": {
        "name": "noop",
        "arguments": "{}"
      }
    }
  ]
}

When sent to an OpenAI-compatible provider in stream: true mode, this can fail with HTTP 400 and Instructions are required.

Adding an explicit empty content field fixes the same request:

{
  "role": "assistant",
  "content": "",
  "tool_calls": [
    {
      "id": "call_test_1",
      "type": "function",
      "function": {
        "name": "noop",
        "arguments": "{}"
      }
    }
  ]
}

Local verification

With the same OpenAI-compatible provider and request body:

• stream: true + assistant tool_calls + content: "" → 200 OK
• stream: true + assistant tool_calls without content → 400 Instructions are required

Non-streaming mode may be more permissive, which makes this easy to miss if only non-streaming compatibility is tested.

Root cause

src/model/providers/openai/request.ts serializes assistant messages that only contain tool calls without setting content.

Current behavior is effectively:

content: normalContent.length > 0
  ? toOpenAIContent(normalContent)
  : (message.role === "assistant" && thinkingBlocks.length > 0 ? "" : undefined),

So assistant messages with assistantToolCalls.length > 0 and no normal text content get content: undefined.

Expected behavior

For OpenAI-compatible request serialization, assistant messages with tool_calls should include explicit empty string content:

"content": ""

This is more compatible across OpenAI-compatible providers and avoids streaming failures after tool calls.

Suggested fix

Set content: "" for assistant messages when either thinking blocks or tool calls are present but normal content is empty, for example:

content: normalContent.length > 0
  ? toOpenAIContent(normalContent)
  : (message.role === "assistant" && (thinkingBlocks.length > 0 || assistantToolCalls.length > 0) ? "" : undefined),

Impact

This affects any agent flow that performs a tool call and then continues with a streaming OpenAI-compatible provider. In Always-On discovery, the run failed immediately after a simple glob tool call because the follow-up streaming request hit this provider validation error.

[houleixx]

This looks like the right root cause to me. For OpenAI-compatible providers, the safest serialization shape is usually to keep an explicit empty string on assistant messages that contain `tool_calls` but no visible text:

```json
{
  "role": "assistant",
  "content": "",
  "tool_calls": [
    {
      "id": "call_test_1",
      "type": "function",
      "function": {
        "name": "noop",
        "arguments": "{}"
      }
    }
  ]
}

The important thing I would verify is the actual request body sent on the second turn, not only the in-memory message object. A few OpenAI-compatible providers are stricter in streaming mode than non-streaming mode, so this kind of bug can be hidden unless you compare the raw wire payload.

Suggested validation checklist:

1. Run the same tool-call conversation in non-streaming and streaming mode.
2. Capture the follow-up request after the first tool result.
3. Confirm whether the historical assistant message includes:
   • role: "assistant"
   • tool_calls: [...]
   • content: ""
4. Confirm the tool role message has the matching tool_call_id.
5. Replay the same body with and without content: "" to confirm the provider behavior.

For request/response inspection, a local proxy can help here. I use ccglass for this kind of OpenAI-compatible agent debugging because it shows the real request body, tool schema, response body/SSE reassembly, tool calls/tool results, latency, and usage in a local dashboard. It can also export a raw HTTP transcript or cURL-style replay, which is useful for proving whether the failure is in PilotDeck serialization or in the upstream provider.

Project: https://github.com/jianshuo/ccglass