builders · review · first seen Oct 24, 01:28 UTC

Anthropic adds message threads to Python SDK

Anthropic shipped message threads and usage and cost reports by dimension in Python SDK v2.2.0, while marking older reports as legacy. Builders who use those reports should review their reporting path before adopting the new one.

L0 · primary1 source1 claims checked4 min read

What shipped

The v2.2.0 release notes list support for message threads. That establishes that the Python SDK shipped the feature, but the supplied excerpt does not show its methods, request fields, or an example. Treat the release note as a reason to inspect the SDK, not as enough information to rewrite a message workflow from this review alone. [1]

The same release lists usage and cost reports by dimension and marks older reports as legacy. Those are two distinct changes: a new reporting capability and a changed status for the older reports. The excerpt does not name the available dimensions or say that legacy reports stopped working. A builder should not infer either a particular breakdown or an immediate removal. [1]

The release also records tool-runner fixes. It says the runner leaves history to the caller after append_messages(), keeps the current reply out of the set_messages_params() callback, and again gives that callback tools as definitions. It also addresses which function tools keep running when the callback changes tool definitions, and retention of betas, user_profile_id, and workspace_id when the callback omits them. These details matter if your code uses that callback; the excerpt does not establish their effect on code that does not. [1]

Why it matters if you build

For a team deciding what to work on today, the reporting change deserves a targeted check. If a Python SDK workflow consumes the older usage or cost reports, identify that dependency before changing it. The legacy label signals a distinction between the old and new reporting paths, but supplies no retirement date or migration instructions. Replacing a working report solely because of the label would assume more than the release note says. [1]

Reports by dimension may be useful when a builder needs a more specific view of usage or cost than an older report provides. The excerpt does not identify the dimensions, their units, or how their values relate to older reports. Test the output against the questions your workflow actually asks. Do not use the release note alone to promise a new cost calculation or a particular accounting breakdown. [1]

Message threads merit a separate evaluation from reporting. A builder with a message workflow can check whether the shipped SDK support fits that workflow, while leaving existing behavior in place until the methods and results are verified. If the workflow also uses a tool runner, the listed callback and history fixes give it specific behavior to retest. The excerpt provides no performance, pricing, or limit claims for either feature. [1]

How to try it today

1. Read the v2.2.0 release notes and locate the message-threads and reporting entries.
2. Find any Python SDK workflow that reads the older usage or cost reports; record where its output is used.
3. Inspect the SDK’s message-thread support before changing an existing message workflow.
4. If you use set_messages_params(), retest tool definitions, omitted betas and IDs, and tool-runner history behavior.
5. Evaluate reports by dimension against the breakdown your workflow needs; do not assume which dimensions exist.

What we checked

Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.

1. shipped L0 · primary

   Anthropic Python SDK v2.2.0 marks older usage and cost reports as legacy.

   per GitHub releases · anthropics/anthropic-sdk-python (L0)

What is not confirmed

The supplied release excerpt does not establish message-thread methods, request examples, supported dimensions, report schemas, or limits. It also does not say whether existing message code needs to change. Those details need confirmation before an implementation decision. [1]

The excerpt gives no removal date for legacy reports and no claim that they have stopped working. It provides no price change, measured cost effect, or performance result for the new features. [1]

Who should act, who should wait

Act now if your Python SDK integration depends on older usage or cost reports, needs a report broken down by dimension, or uses the tool-runner callback behaviors named in the release. Make the first action an inspection or a test, not an assumed migration: v2.2.0 shipped the capabilities, but this excerpt does not specify enough to prescribe replacement code. [1]

Wait on a production change if its case depends on a particular report dimension, thread method, limit, price effect, or legacy-report deadline. None is established here. Waiting for those details is different from ignoring the release: the shipped features are worth evaluating, while the proposed change still needs evidence from the SDK behavior. [1]

Sources

• v2.2.0 — GitHub releases · anthropics/anthropic-sdk-python L0 · primary