Only force translation for gpt-5* models and /chat/completions (not responses)#344
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ad614a3c02
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "Codex (@codex) review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "Codex (@codex) address that feedback".
| let format = if output_format == ProviderFormat::ChatCompletions | ||
| && provider_formats.contains(&ProviderFormat::Responses) | ||
| && spec.requires_responses_api() |
There was a problem hiding this comment.
Preserve Responses transport for Responses-only models
When the caller requests a non-chat output format (for example the Anthropic-compatible /v1/messages path) for an OpenAI model where spec.requires_responses_api() is true, this new output_format == ChatCompletions guard leaves the route format as the catalog's ChatCompletions format. I checked OpenAIProvider::complete, and any non-Responses format is sent to chat_url, so gpt-5.3+, gpt-5-pro, and codex variants that ModelSpec marks as Responses-only will now be sent to /v1/chat/completions instead of /v1/responses and fail upstream even though the router can still transform the provider response back to the requested output format.
Useful? React with 👍 / 👎.
| if target != ProviderFormat::ChatCompletions { | ||
| return false; |
There was a problem hiding this comment.
Keep applying model transforms to Responses requests
For native /v1/responses requests whose model is gpt-5*/reasoning, returning false here allows same-format passthrough before the ResponsesAdapter can run apply_model_transforms (which its own tests require for stripping fields like top_p/temperature). A Responses payload such as {"model":"gpt-5-mini","input":"hi","top_p":0.9} now goes upstream unchanged, while transformed Responses requests still omit that field, so same-format requests can be rejected by the provider for parameters the adapter already knows to remove.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
This is desired.
Ken Jiang (knjiang)
left a comment
There was a problem hiding this comment.
i made one tiny change to revert the router.rs change since i think it's unnecessary. the passthrough change should only require changes to crates/lingua/src/processing/transform.rs
| @@ -931,8 +931,8 @@ async fn responses_required_model_uses_responses_for_anthropic_messages_output() | |||
| ); | |||
| assert_eq!( | |||
| metadata.provider_format, | |||
| ProviderFormat::Responses, | |||
| "gpt-5.5 should use Responses transport even when the caller uses /v1/messages" | |||
| ProviderFormat::ChatCompletions, | |||
| "Responses transport override should only apply to chat completions output" | |||
There was a problem hiding this comment.
this change feels like a regression to me. we should always be upgrading to responses. i initially made this change because we were running into gpt-5.5 chat completion compatability issues -> #274
i don't rlly see how this code change relates to passthrough/not forcing translation
This stack of pull requests is managed by Graphite. Learn more about stacking. |

No description provided.