docs: clarify v2 usage for reasoning models

[RitikWeb22]

Description

Summary
This PR improves README guidance for reasoning model usage with the V2 chat flow, while also clarifying legacy compatibility behavior.

Changes

• Updated documentation language for clarity and consistency.
• Added explicit guidance that reasoning-focused usage should use CohereClientV2 and the v2 chat flow.
• Clarified that CohereClient remains backward compatible with the legacy v1 chat endpoint.

Why is this needed?
Previously, usage guidance could be interpreted ambiguously for reasoning model workflows. This update reduces confusion and helps developers choose the correct client/endpoint path.

Validation

• Documentation-only change.
• Build passes locally.
• Focused compatibility tests pass for legacy chat behavior:
  • pnpm vitest run client.test.ts main.test.ts -t "chat|v1 back compat"

Checklist

• Documentation updated
• No runtime code behavior changed in this PR branch
• Backward compatibility guidance is explicitly documented

---

Note

Low Risk
Documentation-only updates that clarify which client/endpoint to use; no runtime behavior changes.

Overview
Updates the README to explicitly recommend CohereClientV2 / v2/chat for reasoning-capable chat, while clarifying that CohereClient remains backward compatible with the legacy v1/chat endpoint.

Also refreshes wording and examples for consistency (install command, code style, streaming and error-handling snippets) without changing SDK behavior.

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

[Copilot]

Pull request overview

This PR refines the README to reduce ambiguity around “reasoning model” usage by steering developers toward the v2 chat flow (CohereClientV2 / v2/chat) while clarifying that CohereClient remains compatible with the legacy v1/chat endpoint.

Changes:

• Reworded introductory and streaming documentation for clarity and consistency.
• Added explicit guidance recommending v2 usage for reasoning models and describing v1 backward compatibility.
• Updated code examples to use consistent TypeScript formatting and a v2-oriented Errors example.

Comments suppressed due to low confidence (2)

README.md:28

• The v2 usage example initializes CohereClientV2 with {} but the client requires auth via token or the CO_API_KEY env var; without either, requests will throw an auth configuration error. Consider adding token: "YOUR_API_KEY" here or explicitly noting that CO_API_KEY must be set for this snippet to work as-written.

```typescript
import { CohereClientV2 } from "cohere-ai";

const cohere = new CohereClientV2({});

README.md:52

• Same as the main usage snippet: new CohereClientV2({}) will fail unless token is provided or CO_API_KEY is set in the environment. Updating the streaming example to include auth (or a note about CO_API_KEY) would prevent copy/paste failures.

```typescript
import { CohereClientV2 } from "cohere-ai";

const cohere = new CohereClientV2({});

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The Errors section text says "When the API returns a non-success status code ... a subclass of CohereError is thrown", but timeouts and some non-HTTP failures throw CohereTimeoutError (not a CohereError) and the example explicitly handles it. Please update this wording to reflect both HTTP status-code errors (CohereError subclasses) and non-status failures like timeouts (CohereTimeoutError).

[RitikWeb22]

When the API returns a non-success status code, a subclass of CohereError is thrown. For non-HTTP failures, such as request timeouts, the SDK throws a CohereTimeoutError