An idempotency_key argument in a request is not, by itself, a reason to replay a workflow safely. For teams using anthropic-sdk-python v1.5.0, that distinction is explicit in the release notes: the client keeps the request option as a deprecated no-op.
The practical decision is whether your retry path relies on that option to prevent duplicate work. If it does, audit that assumption before permitting automatic retries around side effects.
What the release actually establishes
The v1.5.0 release notes, dated September 10, 2026 in the changelog heading, include two relevant entries under Chores:
- Clean up the unused idempotency request option.
- Keep the
idempotency_keyrequest option as a deprecated no-op, with a link to issue #621.
That is a narrow client-library statement. Keeping the option does not establish duplicate-operation protection. Equally, these notes do not prove that every server endpoint lacks deduplication, specify retry defaults, or establish when the option first became ineffective. Do not turn this into a claim that v1.5.0 newly broke a previously guaranteed safeguard.
Audit the retry boundary, not just the argument
Consider an application that requests model output and then uses it to create a ticket. This is an illustrative workflow, not a reported incident. There are two different questions: whether another model request is acceptable, and whether the ticket-creation step may run again. An SDK request option should not be treated as proof of protection for that downstream action.
A focused integration audit would cover:
- Find the assumption. Search application wrappers, request-option builders, and tests for
idempotency_key. Identify any code or documentation that treats its presence as permission to retry. Removing a deprecated argument is cleanup; it is not the replacement safety mechanism. - Identify the actual effect. Separate model-request attempts from the business operation they serve. Decide which action must not be repeated and where its outcome can be checked.
- Record the logical operation. Use a durable application-owned identity and explicit pending, completed, and uncertain outcomes. Concurrent attempts should not independently claim the same operation. Keep completed results available where appropriate so a repeated caller can receive the existing outcome instead of triggering the effect again.
- Verify the downstream contract. If the side-effecting service offers deduplication, confirm its scope, retention window, and behavior for a repeated key with different input. Do not infer those properties from this SDK release.
- Reconcile before replay. If an acknowledgement is lost, check the destination’s operation state where possible. If the effect cannot be determined, hold that operation for reconciliation rather than automatically treating uncertainty as failure.
A local record alone does not make an external action atomic: the action could complete before the application records success. The retry design still needs a verified destination-side mechanism or a way to resolve that gap. These are application-design recommendations, not guarantees supplied by v1.5.0.
An acceptance check worth adding
In a controlled test environment, exercise both simultaneous attempts for one logical operation and a simulated effect that completes just before its acknowledgement is lost. Check the number of effects, not merely whether both client calls returned successfully.
The intended acceptance condition should be explicit: a repeated operation either returns the recorded result, is prevented from duplicating the effect by a verified mechanism, or remains visibly uncertain with automatic replay blocked. A test that only confirms idempotency_key is accepted does not establish that condition.
No runtime tests are claimed here. The release-note takeaway is enough to justify a targeted audit: base retry permission on verified operation state and an actual duplicate-control mechanism, not on the continued existence of this request option.