Issue Station
Sign In
Tools hereToolbox

crewai - ✅(Solved) Fix [FEATURE] Add native responses API support for other providers than OpenAI [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
crewAIInc/crewAI#4974•Fetched 2026-04-08 01:07:00
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
ktruchczktruchcz
Participants
JairoohJairoohktruchczktruchcz
Timeline (top)
commented ×1cross-referenced ×1labeled ×1referenced ×1

Root Cause

Adding proper Responses API support for Azure OpenAI would:

  • Enable enterprises on Azure to benefit from CrewAI’s latest OpenAI-native improvements
  • Align CrewAI with the industry shift away from Chat Completions toward Responses API
  • Allow seamless use of GPT‑4o/5 deployments on Azure without custom patches
  • Improve compatibility across cloud providers hosting OpenAI models
  • Reduce the need for provider-specific hacks in Crew configurations

Fix Action

Fix / Workaround

  • CrewAI does not recognize Azure as a provider eligible for Responses API mode

  • Requests generated in Responses API format are incompatible with Azure’s deployment‑based endpoint structure

  • Users must implement workarounds or fall back to legacy Chat Completions behavior

  • Enable enterprises on Azure to benefit from CrewAI’s latest OpenAI-native improvements

  • Align CrewAI with the industry shift away from Chat Completions toward Responses API

  • Allow seamless use of GPT‑4o/5 deployments on Azure without custom patches

  • Improve compatibility across cloud providers hosting OpenAI models

  • Reduce the need for provider-specific hacks in Crew configurations

PR fix notes

PR #4977: feat: add Responses API support for Azure OpenAI provider

Description (problem / solution / changelog)

Summary

Closes #4974. Adds native Responses API support to AzureCompletion using a composition/delegation pattern: when api="responses" is specified, an internal OpenAICompletion instance is created and its clients are replaced with AzureOpenAI/AsyncAzureOpenAI from the openai SDK (which natively supports the Responses API on Azure). All Responses API calls are then delegated to this internal instance.

This avoids reimplementing all Responses API logic (tool format conversion, structured output, auto-chaining, reasoning items, streaming, etc.) and reuses the existing OpenAICompletion implementation.

Key changes to AzureCompletion:

  • New __init__ parameters: api, instructions, store, previous_response_id, include, builtin_tools, parse_tool_outputs, auto_chain, auto_chain_reasoning, seed, reasoning_effort, max_completion_tokens
  • _init_responses_delegate() creates OpenAICompletion and swaps in AzureOpenAI/AsyncAzureOpenAI clients
  • call()/acall() delegate to the internal instance when api="responses"
  • Pass-through properties: last_response_id, last_reasoning_items
  • Pass-through methods: reset_chain(), reset_reasoning_chain()
  • AZURE_RESPONSES_API_VERSION = "2025-03-01-preview" default
  • Interceptors now permitted in responses mode (handled by OpenAI SDK)

Review & Testing Checklist for Human

  • self.client / self.async_client not set in responses mode: When api="responses", the Azure AI Inference ChatCompletionsClient is never created. Verify that no code path (e.g., supports_function_calling(), aclose(), supports_stop_words(), event emission, or BaseLLM base class) accesses self.client on a responses-mode instance — this would raise AttributeError.
  • Client monkey-patching fragility: The delegate is constructed as a normal OpenAICompletion (creating default OpenAI/AsyncOpenAI clients), then its .client and .async_client are immediately replaced with AzureOpenAI instances. Confirm OpenAICompletion.__init__ doesn't perform any network calls or store client references elsewhere that would bypass this swap.
  • is_azure_openai_endpoint is False in responses mode: Since self.endpoint is the raw base URL (e.g., https://test.openai.azure.com without /openai/deployments/), the is_azure_openai_endpoint flag will be False. Verify this doesn't break supports_stop_words(), get_context_window_size(), or _prepare_completion_params() behavior for responses-mode instances.
  • Error handling gap: In call()/acall(), the delegation to the responses delegate happens before the try/except block and llm_call_context(). Errors from the delegate won't go through _handle_api_error or emit call_failed events. Consider whether this is acceptable.
  • E2E validation: All tests are unit tests with mocks. Test against a real Azure OpenAI endpoint with api="responses" to confirm the delegation actually produces correct Responses API calls over the wire.

Notes

  • The uv.lock file was not modified (it was temporarily regenerated locally for test runs but reverted before commit).
  • 30+ new tests added covering initialization, delegation, parameter forwarding, auto-chaining, reasoning items, interceptors, endpoint handling, and backward compatibility.
  • The self.endpoint → self.base_endpoint rename preserves backward compat by still setting self.endpoint — but the initialization order changed, which is worth a quick check.

Link to Devin session: https://app.devin.ai/sessions/01c25abb1a1849918399731940f82443

Changed files

  • lib/crewai/src/crewai/llms/providers/azure/completion.py (modified, +245/-18)
  • lib/crewai/tests/llms/azure/test_azure.py (modified, +591/-0)
RAW_BUFFERClick to expand / collapse

Feature Area

Core functionality

Is your feature request related to a an existing bug? Please link it here.

No

Describe the solution you'd like

OpenAI Responses API support in 1.9.0 does not work with other providers (e.g., Azure)

Why

  • CrewAI 1.9.0 introduced native support for the OpenAI Responses API, which is great — but this functionality currently only works when using OpenAI’s own API.

  • Other OpenAI‑compatible providers such as Azure OpenAI cannot use this feature, even though they expose the same model families (GPT‑4o, GPT‑4o‑mini, GPT‑5, etc.) and are widely used in enterprise environments.

  • Azure is one of the largest enterprise providers running OpenAI models, yet at the moment.

  • CrewAI does not recognize Azure as a provider eligible for Responses API mode

  • Requests generated in Responses API format are incompatible with Azure’s deployment‑based endpoint structure

  • Users must implement workarounds or fall back to legacy Chat Completions behavior

Why this matters

Adding proper Responses API support for Azure OpenAI would:

  • Enable enterprises on Azure to benefit from CrewAI’s latest OpenAI-native improvements
  • Align CrewAI with the industry shift away from Chat Completions toward Responses API
  • Allow seamless use of GPT‑4o/5 deployments on Azure without custom patches
  • Improve compatibility across cloud providers hosting OpenAI models
  • Reduce the need for provider-specific hacks in Crew configurations

Describe alternatives you've considered

No response

Additional context

No response

Willingness to Contribute

Yes, I'd be happy to submit a pull request

extent analysis

Fix Plan

To add support for Azure OpenAI in CrewAI's Responses API, follow these steps:

  • Modify the OpenAIProvider class to recognize Azure as a valid provider
  • Update the ResponsesAPI class to handle Azure's deployment-based endpoint structure
  • Add Azure-specific configuration options to the crewai.config file

Example code changes:

# In OpenAIProvider class
def __init__(self, provider_name):
    if provider_name == "azure":
        self.endpoint = "https://azure-openai-api.com"
        self.model_families = ["GPT-4o", "GPT-4o-mini", "GPT-5"]

# In ResponsesAPI class
def generate_request(self, prompt, model):
    if self.provider == "azure":
        # Handle Azure's deployment-based endpoint structure
        endpoint = f"{self.endpoint}/deployments/{model}"
        return {"prompt": prompt, "deployment": model}
    else:
        # Handle OpenAI's endpoint structure
        endpoint = f"{self.endpoint}/completions"
        return {"prompt": prompt, "model": model}

# In crewai.config file
[azure]
endpoint = "https://azure-openai-api.com"
model_families = ["GPT-4o", "GPT-4o-mini", "GPT-5"]

Verification

To verify the fix, test the Responses API with Azure OpenAI by:

  • Setting the provider option to azure in the crewai.config file
  • Sending a request to the Responses API with a valid prompt and model
  • Verifying that the response is generated correctly and matches the expected output

Extra Tips

  • Make sure to update the documentation to reflect the added support for Azure OpenAI
  • Consider adding additional logging and error handling to handle any potential issues with the Azure OpenAI integration.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error#configuration error#environment variable#network issue#logging issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING