feat: adds logprobs to OpenAi response

[eliassoares]

This PR solves the #1228.

[hyperlint-ai]

PR Change Summary

This PR introduces the addition of logprobs to the OpenAI response handling across multiple documentation files.

• Added logprobs parameter to the response model in various documentation files.
• Updated examples to include logprobs in the response structure.

Modified Files

• docs/agents.md
• docs/message-history.md
• docs/models.md
• docs/tools.md

---

How can I customize these reviews?

Check out the Hyperlint AI Reviewer docs for more information on how to customize the review.

If you just want to ignore it on this PR, you can add the hyperlint-ignore label to the PR. Future changes won't trigger a Hyperlint review.

Note specifically for link checks, we only check the first 30 links in a file and we cache the results for several hours (for instance, if you just added a page, you might experience this). Our recommendation is to add hyperlint-ignore to the PR to ignore the link check for this PR.

What is Hyperlint?

Hyperlint is an AI agent that helps you write, edit, and maintain your documentation.

Learn more about the Hyperlint AI reviewer and the checks that we can run on your documentation.

[dmontagu]

Suggested change

	logprobs: list[ChatCompletionTokenLogprob] = field(default_factory=lambda: [])
	logprobs: list[ChatCompletionTokenLogprob] | None = field(None, repr=False)

Let's exclude from the repr. I also feel like it's worth using None to indicate whether it was included in the response. I guess that will make the ergonomics a bit worse; I'd be okay always including it if it doesn't have performance consequences for non-users and will be empty if and only if it wasn't returned.

[dmontagu]

While I definitely would like to better-support extracting arbitrary data from the vendor response into the ModelResponses, I am not totally sure the right way to do it is to add a field to ModelResponse which affects all users.

I think we need to think a bit about how this should work, but in the mean time, I'd be more keen on an approach that retained a(n optional) reference to the underlying vendor-specific response object, which you could use to read the relevant data. Would that be an acceptable alternative? Or do you really need to retain the logprobs etc. during serialization etc.? (I think we could find a way to support that, but if it's not necessary, then it may significantly simpler to just have a way to retain references to the source vendor response)