fix(realtime): include tool arguments in RealtimeToolStart/RealtimeToolEnd events

[ruskaruma]

What I changed

I added an arguments field to RealtimeToolStart events so developers can see the parameters passed when a tool is invoked.
The tool_end event already exposes the tool’s output, so adding arguments makes the start and end events more consistent and useful.

What I did

1. Added the arguments field to the RealtimeToolStart dataclass in events.py.
   It’s stored as a JSON string, following the same convension used by the model layer.
2. Updated the event emission logic in session.py to include the arguments from the tool call event.
3. Extended the test suit to check that arguments are correctly included — covering normal, empty, and nested JSON cases.

Testing

All existing realtime tests passed (156/156).
The new tests verify that arguments are properly included in all scenerios.

This is a simple, low-risk update that fits cleanly into the existing structure of the codebase.

Fixes #1663

[ruskaruma]

Hello @seratch. I’ve created this pull request. would really appreciate it if you could take a quick look when you get a chance. Please let me know if there’s anything I should fix or improve here.

Thanks a lot for your time and feedback!

[seratch]

Thanks for sending this patch! It seems to be good to go, but I will do manual testing before merging it

[seratch]

These changes look good to me. Can you add the same to RealtimeToolEnd events for consistency?

[ruskaruma]

Thank you for reviewing the changes. I’ll make sure to apply the same updates to the RealtimeToolEnd events to keep everything consistent.

[ruskaruma]

@seratch I’ve added the arguments field to RealtimeToolEnd events for consistency with RealtimeToolStart. All tests passed.

Are there any other issues you’d recommend I look into? I’m free through Friday and would love to spend the time contributing here . Really excited to keep going!

[seratch]

Thank you so much for working on this! LGTM

[ruskaruma]

Thank you so much for working on this! LGTM

Anything else you think I could help with next? I’d love to keep contributing while I have some free time.

[Sourav-Nandy-ai]

Hi Ishaan,

This is a nice fix. Adding arguments to RealtimeToolStart and RealtimeToolEnd is small on the diff, but it is the kind of additive schema change that can still break a downstream consumer that pattern-matches on the event's field set (such as strict validation or dataclasses.asdict()). It is definitely worth having a way to check that nothing downstream shifted.

I build agent-eval, an open-source tool for statistically comparing agent behavior across versions (using Mann-Whitney U, bootstrap CI, and Cohen's d instead of simply eyeballing runs). While looking at how it would handle a PR like yours, I found two real gaps:

The basic OpenAI Agents SDK runner was calling a method that does not exist on Agent (agent.run() instead of the real Runner.run()).

Separately, there was no support at all for the realtime and session API. There was no way to drive a RealtimeSession or read its event stream, meaning nothing about tool-argument changes in that surface could be exercised.

Both of these issues are now fixed. The runner call site is corrected, and there is a new openai_agents_realtime_runner() that drives a session and collects RealtimeToolStart and RealtimeToolEnd events (including .arguments) via a duck-typed session interface. I successfully checked this against a fake-session test double.

If you are doing more realtime-API work, I would love your feedback on whether this runner shape actually matches how you would want to test something like this.

You can find the repository here: https://github.com/RudrenduPaul/agent-eval

Best,
Sourav