feat(azure): add Responses API support for Azure OpenAI provider#8598
feat(azure): add Responses API support for Azure OpenAI provider#8598spawn08 wants to merge 1 commit into
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 16a438f764
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| .with_retry(|| async { | ||
| let payload_clone = payload.clone(); | ||
| let resp = api_client | ||
| .response_post(Some(session_id), &deployment_path, &payload_clone) | ||
| .await?; |
There was a problem hiding this comment.
When the deployment-specific Responses endpoint is unsupported, this probe returns a 404 that is mapped to ProviderError::RequestFailed; with_retry retries RequestFailed by default (see retry::should_retry), so every request to environments that only support /openai/responses incurs multiple unnecessary failed attempts and backoff delays before fallback. This creates avoidable latency and extra load in the exact fallback path this change adds; make the first probe non-retrying for 404s (or use transient-only retry) so fallback happens immediately.
Useful? React with 👍 / 👎.
| Err(_) => {} | ||
| } | ||
| } | ||
| Err(_) => {} |
There was a problem hiding this comment.
fetch_supported_models now ignores both transport/status errors and JSON handling errors and always returns the static known-model list, which masks bad credentials or endpoint misconfiguration as a successful model fetch. In flows like provider model discovery, this prevents callers from surfacing actionable auth/config errors and can mislead users into proceeding with an invalid setup; restrict fallback to expected endpoint-not-found cases and return other errors unchanged.
Useful? React with 👍 / 👎.
The Azure OpenAI provider was hardcoded to use the Chat Completions API,
which does not support newer models like gpt-5.x-codex, o1, and o3 that
require the Responses API endpoint.
This rewrites the Azure provider to:
- Dynamically detect models that need the Responses API (codex, o1, o3)
and route them to the correct endpoint
- Maintain two separate API clients with appropriate api-version params:
Chat Completions (2024-10-21) and Responses (2025-04-01-preview)
- Handle both Azure URL patterns for the Responses API:
/openai/deployments/{name}/responses (deployment-specific) with
automatic fallback to /openai/responses (model-in-body) on 404
- Gracefully handle missing /models endpoint during configuration by
falling back to a static list of known models
- Add gpt-5.1-codex, gpt-5.2-codex, gpt-5.3-codex to known models
Closes aaif-goose#5270 (Azure aspect)
Related: aaif-goose#7427, aaif-goose#2564
Made-with: Cursor
spawn08
force-pushed
the
feat/azure-openai-responses-api
branch
from
16a438f to
39a42e7
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 39a42e7135
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| let use_responses = is_responses_api_model(&deployment_name) | ||
| || is_responses_api_model(&model.model_name); |
There was a problem hiding this comment.
Use of deployment_name in use_responses can force Responses API even when the selected model is a Chat Completions model, because Azure deployment names are user-defined aliases and may contain codex/o1/o3 regardless of the actual deployed model. In that case stream() is pinned to the wrong API path for the lifetime of the provider, creating a regression for otherwise valid chat deployments that previously worked; routing should be based on the request model (or explicit endpoint capability), not alias text.
Useful? React with 👍 / 👎.
|
@michaelneale can you please review this PR. The PR adds support for Azure OpenAI models for Codex, O-series models |
|
This pull request has been automatically marked as stale because it has not had recent activity for 23 days. What happens next?
Thank you for your contribution! 🚀 |
1 participant
Summary
The Azure OpenAI provider (
azure.rs) was hardcoded to use the Chat Completions API viaOpenAiCompatibleProvider. This meant models that only support the Responses API (likegpt-5.x-codex,o1,o3) would fail with a 404 during configuration and usage.This PR rewrites the Azure OpenAI provider to dynamically select between Chat Completions and Responses API based on the model name, matching the behavior already present in the
OpenAiProvider(openai.rs).Changes
Dynamic API routing: Detect models requiring the Responses API (
codex,o1,o3) and route requests to the correct endpoint automaticallyDual API clients: Maintain separate
ApiClientinstances with appropriateapi-versionquery parameters --2024-10-21for Chat Completions,2025-04-01-previewfor Responses APITwo URL pattern support: Azure exposes two URL patterns for the Responses API:
/openai/deployments/{deployment}/responses(deployment-specific)/openai/responses(model name in request body)The provider tries the deployment-specific path first and falls back to the non-deployment path on 404. This handles different Azure deployment configurations gracefully.
Graceful model listing:
fetch_supported_models()now handles the common case where Azure deployments do not expose a/modelsendpoint -- falls back to a static list of known models instead of failing the configuration wizardKnown models: Added
gpt-5.1-codex,gpt-5.2-codex,gpt-5.3-codexto the Azure known models listMotivation
While the
OpenAiProvideralready supports the Responses API (via PR #5783 and #7254), theAzureOpenAiProviderwas still usingOpenAiCompatibleProviderwhich only knows about Chat Completions. This is a gap because:Testing
Tested with
gpt-5.3-codexdeployed on Azure OpenAI:goose configure-> selects Azure OpenAI -> model fetch succeeds -> entersgpt-5.3-codex-> configuration test passesgoosesession with streaming responses works correctlygpt-4o) continue to work unchangedRelated Issues
/modelsendpoint 404 issue from Cannot use Azure OpenAI deployment endpoints (no/modelsendpoint) #7427 for the built-in Azure provider