Fix response content handling in text generation tutorial

[Rishabh-k-Paliwal]

Summary

This PR fixes additional occurrences of direct response.message.content[0].text access in the text generation tutorial.

This follows the issue discussed in #796, where message.content[0] could contain a thinking block rather than a text block. The initial snippets were addressed in #797, but I found additional examples in the tutorial with the same assumption.

Changes

• Updated additional response handling examples to account for different content item types.
• Replaced direct response.message.content[0].text access where appropriate.
• Updated related documentation that assumed the first content item always contained text.

Related

Related to #796.

---

Note

Low Risk
Documentation-only changes to tutorial code samples; no runtime or API behavior.

Overview
Updates the v2 text generation tutorial so sample code no longer assumes the first message.content entry is always text—matching the fix from #797 for the rest of the doc (#796).

Non-streaming examples now iterate response.message.content and branch on type (thinking vs text) instead of using response.message.content[0].text. Temperature and structured-output snippets only read text items (JSON parsing uses the first text block). The streaming section is aligned with current event shape: prose refers to event.type, and the loop prints content-delta deltas with a guard and flush=True.

A short note that pointed readers only at message.content[0].text was removed.

^{Reviewed by Cursor Bugbot for commit 96b3cc4. Bugbot is set up for automated code reviews on this repo. Configure here.}

[LouayYa]

I ran into the same error just now and happy that you picked it up, thanks!

One thing that's still left: the streaming example at the bottom of the same file has the same problem, just in a different shape. Your last hunk stops at the structured output snippet, so this one is untouched:

for event in response:
    if event:
        if event.type == "content-delta":
            print(event.delta.message.content.text, end="")

Thinking blocks fire content-delta events too. They put the reasoning on .content.thinking and leave .content.text as None, so the filter passes but you end up printing None once per thinking token. Here's what I got running it against command-a-plus-05-2026:

NoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneExcited to join Co1t today—looking forward to collaborating with all of you and building something amazing together!

Something like this fixes it:

for event in response:
    if event and event.type == "content-delta":
        text = event.delta.message.content.text
        if text:
            print(text, end="", flush=True)

The flush=True is probably worth adding either way. Without it stdout buffers and the output can land all at once, which kind of ruins the point of a streaming example.

Small one in the same section: the text above that snippet still says event_type, which was the v1 field name. The code uses event.type.

Happy to push a commit to your branch or send a follow up PR after this merges, whatever works. Didn't want to open a competing PR on the same file.

[Rishabh-k-Paliwal]

@LouayYa Thanks for catching this and for the detailed reproduction. I've updated the streaming example to avoid printing None for thinking chunks, added flush=True for incremental output, and corrected event_type to event.type. The changes are now pushed to the PR for review. Appreciate you pointing this out!