Bug: OpenAI Responses API rejects text-only messages with 'input_text' type

[jmarx]

Description

When sending text-only messages to the OpenAI Responses API (/v1/responses), the API returns a 400 error:

Bad Request (400) - Invalid value: 'input_text'. Supported values are: 'output_text' and 'refusal'.

Before fix:

After Fix:

Root Cause

The getMessageInputItem() method in OpenAiTextGenerationModel.php sends text-only messages as objects with a type field:

// Current (broken) behavior
'content' => [
    'type' => 'input_text',  // ❌ API rejects this
    'text' => $text
]

However, the OpenAI Responses API expects text-only messages to have the text sent directly as a string in the content field, not as an object.

Expected Behavior

For text-only messages, the content field should be a plain string:

// Correct format
'content' => $text  // ✅ Plain string, not an object

Steps to Reproduce

1. Create a text-only UserMessage with a single text part
2. Send it via OpenAiTextGenerationModel::generateTextResult()
3. API returns 400 error: "Invalid value: 'input_text'"

Proposed Fix

In src/ProviderImplementations/OpenAi/OpenAiTextGenerationModel.php, modify getMessageInputItem() to handle text-only messages specially:

protected function getMessageInputItem(Message $message): ?array
{
    $parts = $message->getParts();

    if (empty($parts)) {
        return null;
    }

    // Special handling for text-only messages: send text directly as a string
    if (count($parts) === 1 && $parts[0]->getType()->isText()) {
        $text = $parts[0]->getText();
        return [
            'role' => $this->getMessageRoleString($message->getRole()),
            'content' => $text, // Send text directly as a string
        ];
    }

    // ... rest of the method for messages with files, function calls, etc.
}

Environment

• php-ai-client version: 0.4.0
• OpenAI API: Responses API (/v1/responses)
• PHP version: 7.4+

Additional Notes

• Messages with files or multiple parts should continue to use the object format with type fields
• Only single-part text messages need this special handling
• This is specific to the Responses API - Chat Completions API may have different requirements

Related

This issue was discovered when upgrading from 0.3.x to 0.4.0 (which switched from Chat Completions to Responses API).

[felixarntz]

@jmarx Thanks for raising this issue. I have taken a closer look at the problem, and while it's definitely a bug on our end, the solution you're proposing in #183 does not truly address the problem, it only works around it.

The root of the problem is that the OpenAI Responses API requires different message part types for assistant messages than it requires for user messages, and our implementation currently does not handle that. Whenever we send message parts, we always send text with a type of input_text, but for assistant messages that type needs to be output_text. So as soon as there's a multi-turn conversation being sent to the Responses API, our implementation fails. Passing a string instead avoids the problem, but doesn't fix it, as more complex messages with different parts would still run into the issue.

@JasonTheAdams Unfortunately, https://platform.openai.com/docs/api-reference/responses/create does not document this nuance at all, but you can at least tell from the example response that assistant messages use the other types (and I know we already have it in the output handling, but we don't consider it when passing the messages back to the API). Fortunately, we can simply look at the AI SDK implementation of this and take over all those types - FWIW it's used by a lot more people than our PHP SDK, so it's safe to assume a bug like that would have been caught there a long time ago if it was incorrect.