feat: return logprobs in OpenAIChatGenerator and OpenAIResponsesChatGenerator

[Amnah199]

Related Issues

• fixes Getting logprobs for OpenAI models #9914

Proposed Changes:

• Return logprobs in ChatMessage.meta for both OpenAI and OpenAIResponses chat generators
• Make serialize_usage generic as it can be used to serialize multiple OpenAI specific objects

How did you test it?

Update few tests with logprobs enabled

Notes for the reviewer

Checklist

• I have read the contributors guidelines and the code of conduct
• I have updated the related issue with new insights and changes
• I added unit tests and updated the docstrings
• I've used one of the conventional commit types for my PR title: fix:, feat:, build:, chore:, ci:, docs:, style:, refactor:, perf:, test: and added ! in case the PR includes breaking changes.
• I documented my code
• I ran pre-commit hooks and fixed any issue

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
haystack-docs	Ignored	Preview		Nov 11, 2025 11:57am

[coveralls]

Pull Request Test Coverage Report for Build 19171927776

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 88 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-0.1%) to 91.468%

---

Files with Coverage Reduction	New Missed Lines	%
components/generators/chat/openai.py	2	97.85%
components/generators/utils.py	7	82.86%
components/generators/chat/openai_responses.py	79	52.56%

Totals
Change from base Build 19138199775:	-0.1%
Covered Lines:	13722
Relevant Lines:	15002

---

💛 - Coveralls

[sjrl]

Looks good!

[Amnah199]

Thanks for the review @sjrl. Will wait until we merge PR #10036 to make sure there are no conflicts.

[sjrl]

@Amnah199 for the failing test I might recommend using a bigger model or improving the instructions to the LLM to only extract the city name when calling the tool.

[Amnah199]

@Amnah199 for the failing test I might recommend using a bigger model or improving the instructions to the LLM to only extract the city name when calling the tool.

@sjrl In essence is it necessary to check this? As its more of a model performance thing rather than an error on our end?
I removed the assertion to check if city names are returned properly.

[sjrl]

@Amnah199 for the failing test I might recommend using a bigger model or improving the instructions to the LLM to only extract the city name when calling the tool.

@sjrl In essence is it necessary to check this? As its more of a model performance thing rather than an error on our end? I removed the assertion to check if city names are returned properly.

I'd say it's necessary for us to test whether we can handle two tool calls being returned in a single response from an LLM. So as long as we are able to test that behavior then specifically testing the values of what city the LLM extracted is not important. But we don't want the test to pass whether only one or two tool calls are returned if we specifically ask for two to be returned by the LLM.

[sjrl]

Looks good!