feat: Add OpenAI Responses API Integration#4248
feat: Add OpenAI Responses API Integration#4248VedantMadane wants to merge 7 commits intocrewAIInc:mainfrom
Conversation
Implements native support for OpenAI's Responses API (/v1/responses) as a new LLM provider in CrewAI, addressing feature request crewAIInc#4152. The Responses API offers advantages for agent workflows including: - Simpler input format (strings or structured input vs message arrays) - Built-in conversation management via previous_response_id - Native support for o-series reasoning models (reasoning_effort param) - Cleaner function calling semantics Usage: # Option 1: Using provider parameter llm = LLM(model='gpt-4o', provider='openai_responses') # Option 2: Using model prefix llm = LLM(model='openai_responses/gpt-4o') # With o-series reasoning models llm = LLM(model='o3-mini', provider='openai_responses', reasoning_effort='high') Key implementation details: - New OpenAIResponsesCompletion class extending BaseLLM (~850 lines) - Message conversion: system messages -> instructions param, other -> input - Tool calling support with strict: true by default - Streaming support (sync and async) - Support for stateful conversations via previous_response_id Closes crewAIInc#4152
Ensure async call paths run before/after hooks with the original messages and skip tool execution when argument parsing fails, matching streaming behavior.
|
Fixed Bugbot findings:
Pushed in 57843a2. |
greysonlalonde
left a comment
There was a problem hiding this comment.
Hey @VedantMadane , thanks! This is super helpful. For usage, can we refactor away from passing openai_responses as a provider? I think there is some confusion that could arise there.
|
@greysonlalonde Models like o1, o3, gpt-4o could default to Responses API. I am picking strict validation over auto-correction based on model capabilities or graceful fallback with warning because: The embeddings system in crewAI is actually designed better. OpenAI currently only has one embeddings API (/v1/embeddings), so there's no equivalent confusion to the LLM case. |
That'll be a breaking change, we need to provide a deprecation notice prior to doing that. I'm all for being explicit, but it's better as a flag, or as an additional options key - the current provider/model syntax doesn't really align provider_api/model |
|
LLM(model="gpt-4o", provider="openai", api="responses") (or api="chat" default if none specified) or LLM(model="gpt-4o", provider="openai", options={"api": "responses"}) ? |
|
Removed openai_responses provider alias - Now raises an error with guidance: All tests have been updated to use the new api='responses' flag. |
|
Previous commit already supports the explicit syntax: Implemented CrewAI’s preferred deprecation approach (no hard-break) Per CrewAI’s conventions (warnings.warn(..., DeprecationWarning, stacklevel=2)),
|
|
@greysonlalonde Agreed on avoiding a breaking change here. I updated the PR so the legacy provider="openai_responses" and the openai_responses/ prefix continue to work for now, but they emit a DeprecationWarning (stacklevel=2) directing users to the explicit syntax provider="openai", api="responses". The default remains unchanged (no implicit model based switching), and conflicting combinations like provider="openai_responses", api="chat" still error to keep things explicit. This keeps backwards compatibility today while giving a clear migration path before any removal. |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
|
Hi @VedantMadane , we ended up implementing the a different pr for the responses api here - had an urgent need for it. We really appreciate the work you put in on this |
|
No worries at all, glad I could be of help even if just for brainstorming. |
Summary
Implements native support for OpenAI's Responses API (/v1/responses) as a new LLM provider in CrewAI, addressing feature request #4152.
The Responses API offers significant advantages over the traditional Chat Completions API for agent-based workflows:
Key Benefits
easoning_effort\ parameter for o1/o3/o4 models
Usage
\\python
from crewai import Agent, LLM
Option 1: Using provider parameter
llm = LLM(model='gpt-4o', provider='openai_responses')
Option 2: Using model prefix
llm = LLM(model='openai_responses/gpt-4o-mini')
With o-series reasoning models
llm = LLM(model='o3-mini', provider='openai_responses', reasoning_effort='high')
Works with all CrewAI components
agent = Agent(
role='Research Analyst',
goal='Find and summarize information',
backstory='Expert researcher',
llm=llm,
)
\\
Implementation Details
Files Changed
Testing
Added comprehensive unit tests covering:
Checklist
Closes #4152
Note
Adds native support for OpenAI’s Responses API and updates provider routing to select it via
provider='openai'withapi='responses'(with deprecation warnings foropenai_responses/prefix andprovider='openai_responses').OpenAIResponsesCompletionwith sync/async calls, streaming, tool calling (strict mode), structured output via JSON schema, statefulprevious_response_id, and o‑seriesreasoningsupportLLM): resolvesprovider+api, validates models/patterns, supportsopenai_responsesin native registry, and filtersprovider/apifrom kwargs; expanded context-pattern checks and supported lists (including Bedrock/Azure nuances)instructions, user/assistant →input; manual stop-word handling for Responses APIWritten by Cursor Bugbot for commit 3273d0a. This will update automatically on new commits. Configure here.