Documentation example fails because message.content[0] returns a thinking block instead of text #796

Description

I encountered an issue while following the official Python text generation example using the Cohere Python SDK.

The documentation shows the following code:

response = co.chat(
    model="command-a-plus-05-2026",
    messages=[
        {
            "role": "user",
            "content": "I'm joining a new startup called Co1t today. Could you help me write a one-sentence introduction message to my teammates.",
        }
    ],
)


print(response.message.content[0].text)

However, when I run this example, it raises the following error:

AttributeError: 'ThinkingAssistantMessageResponseContentItem' object has no attribute 'text'
Environment
Cohere Python SDK version: 7.0.9
Model: command-a-plus-05-2026

Investigation

To understand the response structure, I inspected all items in response.message.content:

for i, item in enumerate(response.message.content):
    print(f"[{i}] type = {item.type}")
    print(item)

The response consistently returned:

[0] type = thinking
type='thinking' thinking='...'

[1] type = text
type='text' text='Hello!'

I repeated the request 5 times and received the same structure each time:

Run 1:
[0] type = thinking
[1] type = text

Run 2:
[0] type = thinking
[1] type = text

Run 3:
[0] type = thinking
[1] type = text

Run 4:
[0] type = thinking
[1] type = text

Run 5:
[0] type = thinking
[1] type = text

Because the first content item is a thinking block, this documented code:

response.message.content[0].text

attempts to access .text on a ThinkingAssistantMessageResponseContentItem, which causes the AttributeError.

Accessing the second item works for this response:

print(response.message.content[1].text)

However, I am unsure whether the position of the text block is guaranteed to always be index 1.

I also tested selecting the content based on its type:

for item in response.message.content:
    if item.type == "text":
        print(item.text)

This successfully prints the assistant's final response.

Expected behavior

The code example in the documentation should run successfully with the documented model and return the assistant's text response.

Question

Could you confirm whether the current response structure, where a thinking block appears before the text block, is expected behavior for command-a-plus-05-2026?

If so, what is the recommended way to access the final text response? Should the documentation be updated to select the text content block rather than assuming response.message.content[0] always contains text?

I would be happy to submit a documentation and my first PR once I know the intended approach.