[pcbeingused333]

Chat conversions already report a token-limit stop (length / max_tokens), but the Responses API ones did not: a truncated answer looked like a normal completion.

• Claude -> Responses (non-stream and stream) and Gemini -> Responses (non-stream and stream): when the upstream stopped on max_tokens / MAX_TOKENS, the result now has status: "incomplete" with incomplete_details.reason: "max_output_tokens", and the stream ends with a response.incomplete event instead of response.completed. The Claude stream context now keeps the stop_reason from message_delta for that.
• Responses -> Claude (non-stream and stream): an incomplete result with that reason, or a response.incomplete event, becomes stop_reason: "max_tokens". The stream handler used to ignore response.incomplete entirely.
• proxy/streaming.go: a Responses stream is considered finished on response.incomplete as well as response.completed. Without this the proxy reported "stream closed before response.completed" for a truncated Responses stream.

Six new tests in internal/transformer/convert cover each conversion, and TestHandleStreamingResponseRequiresResponsesCompletion gets a response.incomplete case. All of them fail on master and pass with the change, together with the rest of ./internal/proxy/ and ./internal/transformer/.... Not run against a live upstream.

This change was prepared with AI assistance (Claude Code).

🤖 Generated with Claude Code