fix(responses-bridge): encode assistant text as output_text, not input_text#129
Merged
teamchong merged 1 commit intoJul 21, 2026
Conversation
…t_text When a Claude Code /v1/messages request is bridged to a GPT model on the Responses path (bridgedGptMessages), prior assistant text turns were lowered to content parts of type input_text. The OpenAI Responses API requires assistant-role message content to be output_text; input_text under role:assistant is rejected with 400, breaking every multi-turn session to a Responses-routed GPT model after the first assistant reply. The bridge's read side already maps assistant text to/from output_text — only the write side was wrong. Thread the role into inputParts and pick the text type accordingly; user/system stay input_text. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When a Claude Code
/v1/messagesrequest is bridged to a GPT model on the Responses path (bridgedGptMessages,proxy.ts), prior assistant text turns were encoded as content parts of typeinput_text. The OpenAI Responses API only acceptsoutput_text(orrefusal) forrole:assistantcontent —input_textthere is a hard 400, so any multi-turn conversation to a Responses-routed GPT model failed after the first assistant reply.The bug is confirmed by the bridge's own asymmetry: the read side (
openAIResponseToAnthropicMessage) already maps assistant text ↔output_text; only the write side (inputParts) was wrong. The branch had no test coverage.Fix
Thread the message
roleintoinputPartsand select the text part type:output_textfor assistant,input_textfor user/system (unchanged). Added a regression test inresponses-bridge-roles.test.ts.Full suite passes (804/804);
typecheckclean.🤖 Generated with Claude Code