Summary

In @ai-sdk/openai-compatible (v1.0.32), the convertToOpenAICompatibleChatMessages function always outputs content: text (where text is initialized as "") for assistant messages. When an assistant message contains only tool-call parts and no text parts, this results in content: "" being sent in the API request.

Providers backed by AWS Bedrock reject this with:

ValidationException: messages: text content blocks must be non-empty

Root Cause

In dist/index.mjs (line ~103-109):

case "assistant": {
  let text = "";
  // ... loops over content parts ...
  messages.push({
    role: "assistant",
    content: text,  // <-- empty string when no text parts exist
    tool_calls: toolCalls.length > 0 ? toolCalls : void 0,
    ...metadata
  });
}

When the assistant message only contains tool-call parts (no text parts), text remains "" and the output is content: "" rather than content: null.

The same pattern exists in @ai-sdk/openai's convertToOpenAIChatMessages.

Proposed Fix

Change content: text to content: text || null for assistant messages:

messages.push({
  role: "assistant",
  content: text || null,  // null instead of empty string
  tool_calls: toolCalls.length > 0 ? toolCalls : void 0,
  ...metadata
});

This matches the OpenAI API spec where content is nullable for assistant messages with tool calls.

Reproduction

1. Use @ai-sdk/openai-compatible with a Bedrock-backed endpoint
2. Have a multi-turn conversation involving tool calls
3. After 2-5 rounds, an assistant message with only tool-call parts is sent with content: ""
4. Bedrock returns HTTP 400: ValidationException: messages: text content blocks must be non-empty

Environment

• @ai-sdk/openai-compatible: 1.0.32
• @ai-sdk/openai: 2.0.89 (same issue)
• Provider backend: AWS Bedrock Runtime

Related

• anomalyco/opencode#15715
• anomalyco/opencode#5028
• anomalyco/opencode#17742 (opencode-side workaround)