### Overview
This PR fixes a typo in the assert statement within the `handoff`
function in `handoffs.py`, changing `'on_input'` to `'on_handoff`' for
accuracy and clarity.
### Changes
- Corrected the word “on_input” to “on_handoff” in the docstring.
### Motivation
Clear and correct documentation improves code readability and reduces
confusion for users and contributors.
### Checklist
- [x] I have reviewed the docstring after making the change.
- [x] No functionality is affected.
- [x] The change follows the repository’s contribution guidelines.
Small fix:
Removing `import litellm.types` as its outside the try except block for
importing litellm so the import error message isn't displayed, and the
line actually isn't needed. I was reproducing a GitHub issue and came
across this in the process.
### Summary
Introduced the `RunErrorDetails` object to get partial results from a
run interrupted by `MaxTurnsExceeded` exception. In this proposal the
`RunErrorDetails` object contains all the fields from `RunResult` with
`final_output` set to `None` and `output_guardrail_results` set to an
empty list. We can decide to return less information.
@rm-openai At the moment the exception doesn't return the
`RunErrorDetails` object for the streaming mode. Do you have any
suggestions on how to deal with it? In the `_check_errors` function of
`agents/result.py` file.
### Test plan
I have not implemented any tests currently, but if needed I can
implement a basic test to retrieve partial data.
### Issue number
This PR is an attempt to solve issue #719
### Checks
- [✅ ] I've added new tests (if relevant)
- [ ] I've added/updated the relevant documentation
- [ ✅] I've run `make lint` and `make format`
- [ ✅] I've made sure tests pass
This PR adds Portkey AI as a tracing provider. Portkey helps you take
your OpenAI agents from prototype to production.
Portkey turns your experimental OpenAI Agents into production-ready
systems by providing:
- Complete observability of every agent step, tool use, and interaction
- Built-in reliability with fallbacks, retries, and load balancing
- Cost tracking and optimization to manage your AI spend
- Access to 1600+ LLMs through a single integration
- Guardrails to keep agent behavior safe and compliant
- Version-controlled prompts for consistent agent performance
Towards #786
## Summary
- mention MCPServerStreamableHttp in MCP server docs
- document CodeInterpreterTool, HostedMCPTool, ImageGenerationTool and
LocalShellTool
- update Japanese translations
PR to enhance the `Usage` object and related logic, to support more
granular token accounting, matching the details available in the [OpenAI
Responses API](https://platform.openai.com/docs/api-reference/responses)
. Specifically, it:
- Adds `input_tokens_details` and `output_tokens_details` fields to the
`Usage` dataclass, storing detailed token breakdowns (e.g.,
`cached_tokens`, `reasoning_tokens`).
- Flows this change through
- Updates and extends tests to match
- Adds a test for the Usage.add method
### Motivation
- Aligns the SDK’s usage with the latest OpenAI responses API Usage
object
- Supports downstream use cases that require fine-grained token usage
data (e.g., billing, analytics, optimization) requested by startups
---------
Co-authored-by: Wulfie Bain <wulfie@openai.com>
Added missing word "be" in prompt instructions.
This is unlikely to change the agent functionality in most cases, but
optimal clarity in prompt language is a best practice.
When an input image is given as input, the code tries to access the
'detail' key, that may not be present as noted in #159.
With this pull request, now it tries to access the key, otherwise set
the value to `None`.
@pakrym-oai or @rm-openai let me know if you want any changes.
When using the voice agent in typed code, it is suboptimal and error
prone to type the TTS voice variables in your code independently.
With this commit we are making the type exportable so that developers
can just use that and be future-proof.
Example of usage in code:
```
DEFAULT_TTS_VOICE: TTSModelSettings.TTSVoice = "alloy"
...
tts_voice: TTSModelSettings.TTSVoice = DEFAULT_TTS_VOICE
...
output = await VoicePipeline(
workflow=workflow,
config=VoicePipelineConfig(
tts_settings=TTSModelSettings(
buffer_size=512,
transform_data=transform_data,
voice=tts_voice,
instructions=tts_instructions,
))
).run(audio_input)
```
---------
Co-authored-by: Rohan Mehta <rm@openai.com>
In response to issue #587 , I implemented a solution to first check if
`refusal` and `usage` attributes exist in the `delta` object.
I added a unit test similar to `test_openai_chatcompletions_stream.py`.
Let me know if I should change something.
---------
Co-authored-by: Rohan Mehta <rm@openai.com>
Per
https://modelcontextprotocol.io/specification/draft/basic/lifecycle#timeouts
"Implementations SHOULD establish timeouts for all sent requests, to
prevent hung connections and resource exhaustion. When the request has
not received a success or error response within the timeout period, the
sender SHOULD issue a cancellation notification for that request and
stop waiting for a response.
SDKs and other middleware SHOULD allow these timeouts to be configured
on a per-request basis."
I picked 5 seconds since that's the default for SSE
Now that `ModelSettings` has `Reasoning`, a non-primitive object,
`dataclasses.as_dict()` wont work. It will raise an error when you try
to serialize (e.g. for tracing). This ensures the object is actually
serializable.
Fix for #574
@rm-openai I'm not sure how to add a test within the repo but I have
pasted a test script below that seems to work
```python
import asyncio
from openai.types.responses import ResponseTextDeltaEvent
from agents import Agent, Runner
async def main():
agent = Agent(
name="Joker",
instructions="You are a helpful assistant.",
)
result = Runner.run_streamed(agent, input="Please tell me 5 jokes.")
num_visible_event = 0
async for event in result.stream_events():
if event.type == "raw_response_event" and isinstance(event.data, ResponseTextDeltaEvent):
print(event.data.delta, end="", flush=True)
num_visible_event += 1
print(num_visible_event)
if num_visible_event == 3:
result.cancel()
if __name__ == "__main__":
asyncio.run(main())
````
## Summary
This replaces the default model provider with a `MultiProvider`, which
has the logic:
- if the model name starts with `openai/` or doesn't contain "/", use
OpenAI
- if the model name starts with `litellm/`, use LiteLLM to use the
appropriate model provider.
It's also extensible, so users can create their own mappings. I also
imagine that if we natively supported Anthropic/Gemini etc, we can add
it to MultiProvider to make it work.
The goal is that it should be really easy to use any model provider.
Today if you pass `model="gpt-4.1"`, it works great. But
`model="claude-sonnet-3.7"` doesn't. If we can make it that easy, it's a
win for devx.
I'm not entirely sure if this is a good idea - is it too magical? Is the
API too reliant on litellm? Comments welcome.
## Test plan
For now, the example. Will add unit tests if we agree its worth mergin.
---------
Co-authored-by: Steven Heidel <steven@heidel.ca>
Only the file name is needed since graphviz's `render()` automatically
adds the file extension.
Also, unnecessary .gv (.dot) files are output, so the `cleanup=True`
option has been modified to prevent them from being saved.
Here is a similar modification, but in a different content.
- https://github.com/openai/openai-agents-python/pull/451
See #528, some folks are having issues because their output types are
not strict-compatible.
My approach was:
1. Create `AgentOutputSchemaBase`, which represents the base methods for
an output type - the json schema + validation
2. Make the existing `AgentOutputSchema` subclass
`AgentOutputSchemaBase`
3. Allow users to pass a `AgentOutputSchemaBase` to
`Agent(output_type=...)`
This pull request introduces the following changes:
1. **Exclude translated pages from search**: I explored ways to make the
search plugin work with the i18n plugin, but it would require extensive
custom JavaScript hacks. So for now, I’m holding off on this work.
2. **Switch from GPT-4.1 to o3 for even better translation quality**:
While 4.1 performs well, o3 shows even greater quality for this task,
and there’s no reason to avoid using it.
litellm is a library that abstracts away details/differences for a lot
of model providers. Adding an extension, so that any provider can easily
be integrated.
---
[//]: # (BEGIN SAPLING FOOTER)
* #532
* __->__ #524
