feat: Introduce new integrations API and convert anthropic by AbhiPrasad · Pull Request #118 · braintrustdata/braintrust-sdk-python

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T21:20:44Z

This PR introduces a new integrations API for provider instrumentation (wrappers) and migrates Anthropic to it as the first implementation. The goal is to separate three concerns that were previously mixed together in individual wrappers:

integration discovery and version compatibility
patch selection and idempotent patch application
provider-specific tracing behavior

This PR is inspired by the current Ruby SDK implementation.

AI Summary

A new base integration layer lives under py/src/braintrust/integrations/. BaseIntegration is the orchestration class. It is responsible for:

probing whether an integration is installed
detecting the installed version
checking compatibility bounds
exposing the patchers available for that integration
resolving enabled_patchers / disabled_patchers
applying patchers in a deterministic, idempotent way

Conceptually, BaseIntegration.setup() is now the standard entry point for “instrument this library in the current process”.

BasePatcher is the unit of patch work. It represents one concrete patch strategy and is responsible for:

identifying itself with a stable patcher id
deciding whether it applies for the current runtime
checking whether its target is already patched
applying its patch once

This PR also adds FunctionWrapperPatcher, a reusable BasePatcher subclass for the common case where instrumentation is done with wrapt.wrap_function_wrapper against a single target path.

Supporting types added with this work:

IntegrationRuntime: normalized runtime facts for one integration (name, module, version)
IntegrationPatchConfig: user-facing config object for selecting patchers
versioning.py: a small stdlib-only helper for version detection and simple spec matching

Anthropic Migration

AnthropicIntegration defines:

name = "anthropic"
import_names = ("anthropic",)
min_version = "0.48.0"
two patchers:
- anthropic.init.sync
- anthropic.init.async

Those patchers wrap:

anthropic.Anthropic.__init__
anthropic.AsyncAnthropic.__init__

The constructor patching model is straightforward: after a client is constructed, Braintrust replaces the instance’s messages and beta.messages surfaces with traced wrappers. Those wrappers preserve Anthropic behavior while adding span creation, metadata capture, token metrics, time-to-first-token, stream aggregation, and error logging for sync, async, and streaming request paths.

This means the old Anthropic tracing logic did not disappear, but it was moved behind a cleaner integration boundary:

orchestration and patch selection now live in the integration layer
Anthropic-specific tracing remains local to the Anthropic implementation

The old braintrust.wrappers.anthropic module is now a compatibility shim that re-exports the new Anthropic wrapper entry points.

User-Facing Changes

The main user-facing change is that Anthropic instrumentation is now configurable instead of being strictly all-or-nothing.

Existing behavior still works:

importbraintrustbraintrust.auto_instrument()

Users can now also choose which Anthropic patchers to apply:

frombraintrustimportauto_instrumentfrombraintrust.integrationsimportIntegrationPatchConfigauto_instrument(
anthropic=IntegrationPatchConfig(
disabled_patchers={"anthropic.init.async"},
)
)

New public surfaces introduced by this PR:

braintrust.integrations.AnthropicIntegration
braintrust.integrations.IntegrationPatchConfig
braintrust.integrations.anthropic.wrap_anthropic

Existing exports:

braintrust.wrappers.anthropic.wrap_anthropic still works for compatibility

In practical terms, this PR is additive for users:

no intended breaking change for existing Anthropic wrapper usage
new ability to selectively instrument Anthropic sync vs async constructor paths
new public integration API that future providers can migrate onto

Cedric / ViaDézo1er (viadezo1er)

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done (unless there's an explicit customer request)?

Cedric / ViaDézo1er (viadezo1er) · 2026-03-23T22:09:49Z

+
+Keep the class focused on orchestration. Provider-specific tracing logic should stay in `tracing.py`.
+
+If the provider already supports direct instance wrapping, expose a `wrap(client)` method on the integration class that returns the traced client wrapper.


Which providers do this?

I needed to update the skill - I deleted this .wrap stuff, will fix!

Cedric / ViaDézo1er (viadezo1er)

(I don't know if this is a plausible situation)

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

Or maybe we don't want to have any code shared between providers?

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:26:08Z

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

We can just add a utility folder, or figure that out at this time.

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:37:45Z

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done

no, we can just do this on a case by case basis. Not that much activity on this repo, so we can get away with less merge conflicts.

Cedric / ViaDézo1er (viadezo1er)

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

Good to merge

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:51:11Z

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

yeah I gotta fix that. Thanks for the review!

Convert the Google ADK (Agent Development Kit) instrumentation from the legacy wrappers pattern to the new integrations API introduced in #118. - Extract tracing helpers into integrations/adk/tracing.py - Create ADK patchers (agent, runner, flow, mcp_tool) in patchers.py - Add AdkIntegration class with proper registration - Move tests and cassettes from wrappers/adk/ to integrations/adk/ - Move auto_instrument test script to integrations/auto_test_scripts/ - Slim down wrappers/adk/__init__.py to delegate to integrations - Update noxfile.py with ADK integration test sessions - Update integrations base and registry for ADK support

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T21:20:44Z

This PR introduces a new integrations API for provider instrumentation (wrappers) and migrates Anthropic to it as the first implementation. The goal is to separate three concerns that were previously mixed together in individual wrappers:

integration discovery and version compatibility
patch selection and idempotent patch application
provider-specific tracing behavior

This PR is inspired by the current Ruby SDK implementation.

AI Summary

A new base integration layer lives under py/src/braintrust/integrations/. BaseIntegration is the orchestration class. It is responsible for:

probing whether an integration is installed
detecting the installed version
checking compatibility bounds
exposing the patchers available for that integration
resolving enabled_patchers / disabled_patchers
applying patchers in a deterministic, idempotent way

Conceptually, BaseIntegration.setup() is now the standard entry point for “instrument this library in the current process”.

BasePatcher is the unit of patch work. It represents one concrete patch strategy and is responsible for:

identifying itself with a stable patcher id
deciding whether it applies for the current runtime
checking whether its target is already patched
applying its patch once

This PR also adds FunctionWrapperPatcher, a reusable BasePatcher subclass for the common case where instrumentation is done with wrapt.wrap_function_wrapper against a single target path.

Supporting types added with this work:

IntegrationRuntime: normalized runtime facts for one integration (name, module, version)
IntegrationPatchConfig: user-facing config object for selecting patchers
versioning.py: a small stdlib-only helper for version detection and simple spec matching

Anthropic Migration

AnthropicIntegration defines:

name = "anthropic"
import_names = ("anthropic",)
min_version = "0.48.0"
two patchers:
- anthropic.init.sync
- anthropic.init.async

Those patchers wrap:

anthropic.Anthropic.__init__
anthropic.AsyncAnthropic.__init__

The constructor patching model is straightforward: after a client is constructed, Braintrust replaces the instance’s messages and beta.messages surfaces with traced wrappers. Those wrappers preserve Anthropic behavior while adding span creation, metadata capture, token metrics, time-to-first-token, stream aggregation, and error logging for sync, async, and streaming request paths.

This means the old Anthropic tracing logic did not disappear, but it was moved behind a cleaner integration boundary:

orchestration and patch selection now live in the integration layer
Anthropic-specific tracing remains local to the Anthropic implementation

The old braintrust.wrappers.anthropic module is now a compatibility shim that re-exports the new Anthropic wrapper entry points.

User-Facing Changes

The main user-facing change is that Anthropic instrumentation is now configurable instead of being strictly all-or-nothing.

Existing behavior still works:

importbraintrustbraintrust.auto_instrument()

Users can now also choose which Anthropic patchers to apply:

frombraintrustimportauto_instrumentfrombraintrust.integrationsimportIntegrationPatchConfigauto_instrument(
anthropic=IntegrationPatchConfig(
disabled_patchers={"anthropic.init.async"},
)
)

New public surfaces introduced by this PR:

braintrust.integrations.AnthropicIntegration
braintrust.integrations.IntegrationPatchConfig
braintrust.integrations.anthropic.wrap_anthropic

Existing exports:

braintrust.wrappers.anthropic.wrap_anthropic still works for compatibility

In practical terms, this PR is additive for users:

no intended breaking change for existing Anthropic wrapper usage
new ability to selectively instrument Anthropic sync vs async constructor paths
new public integration API that future providers can migrate onto

Cedric / ViaDézo1er (viadezo1er)

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done (unless there's an explicit customer request)?

Cedric / ViaDézo1er (viadezo1er) · 2026-03-23T22:09:49Z

+
+Keep the class focused on orchestration. Provider-specific tracing logic should stay in `tracing.py`.
+
+If the provider already supports direct instance wrapping, expose a `wrap(client)` method on the integration class that returns the traced client wrapper.


Which providers do this?

I needed to update the skill - I deleted this .wrap stuff, will fix!

Cedric / ViaDézo1er (viadezo1er)

(I don't know if this is a plausible situation)

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

Or maybe we don't want to have any code shared between providers?

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:26:08Z

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

We can just add a utility folder, or figure that out at this time.

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:37:45Z

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done

no, we can just do this on a case by case basis. Not that much activity on this repo, so we can get away with less merge conflicts.

Cedric / ViaDézo1er (viadezo1er)

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

Good to merge

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:51:11Z

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

yeah I gotta fix that. Thanks for the review!

Convert the Google ADK (Agent Development Kit) instrumentation from the legacy wrappers pattern to the new integrations API introduced in #118. - Extract tracing helpers into integrations/adk/tracing.py - Create ADK patchers (agent, runner, flow, mcp_tool) in patchers.py - Add AdkIntegration class with proper registration - Move tests and cassettes from wrappers/adk/ to integrations/adk/ - Move auto_instrument test script to integrations/auto_test_scripts/ - Slim down wrappers/adk/__init__.py to delegate to integrations - Update noxfile.py with ADK integration test sessions - Update integrations base and registry for ADK support

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T21:20:44Z

This PR introduces a new integrations API for provider instrumentation (wrappers) and migrates Anthropic to it as the first implementation. The goal is to separate three concerns that were previously mixed together in individual wrappers:

integration discovery and version compatibility
patch selection and idempotent patch application
provider-specific tracing behavior

This PR is inspired by the current Ruby SDK implementation.

AI Summary

A new base integration layer lives under py/src/braintrust/integrations/. BaseIntegration is the orchestration class. It is responsible for:

probing whether an integration is installed
detecting the installed version
checking compatibility bounds
exposing the patchers available for that integration
resolving enabled_patchers / disabled_patchers
applying patchers in a deterministic, idempotent way

Conceptually, BaseIntegration.setup() is now the standard entry point for “instrument this library in the current process”.

BasePatcher is the unit of patch work. It represents one concrete patch strategy and is responsible for:

identifying itself with a stable patcher id
deciding whether it applies for the current runtime
checking whether its target is already patched
applying its patch once

This PR also adds FunctionWrapperPatcher, a reusable BasePatcher subclass for the common case where instrumentation is done with wrapt.wrap_function_wrapper against a single target path.

Supporting types added with this work:

IntegrationRuntime: normalized runtime facts for one integration (name, module, version)
IntegrationPatchConfig: user-facing config object for selecting patchers
versioning.py: a small stdlib-only helper for version detection and simple spec matching

Anthropic Migration

AnthropicIntegration defines:

name = "anthropic"
import_names = ("anthropic",)
min_version = "0.48.0"
two patchers:
- anthropic.init.sync
- anthropic.init.async

Those patchers wrap:

anthropic.Anthropic.__init__
anthropic.AsyncAnthropic.__init__

The constructor patching model is straightforward: after a client is constructed, Braintrust replaces the instance’s messages and beta.messages surfaces with traced wrappers. Those wrappers preserve Anthropic behavior while adding span creation, metadata capture, token metrics, time-to-first-token, stream aggregation, and error logging for sync, async, and streaming request paths.

This means the old Anthropic tracing logic did not disappear, but it was moved behind a cleaner integration boundary:

orchestration and patch selection now live in the integration layer
Anthropic-specific tracing remains local to the Anthropic implementation

The old braintrust.wrappers.anthropic module is now a compatibility shim that re-exports the new Anthropic wrapper entry points.

User-Facing Changes

The main user-facing change is that Anthropic instrumentation is now configurable instead of being strictly all-or-nothing.

Existing behavior still works:

importbraintrustbraintrust.auto_instrument()

Users can now also choose which Anthropic patchers to apply:

frombraintrustimportauto_instrumentfrombraintrust.integrationsimportIntegrationPatchConfigauto_instrument(
anthropic=IntegrationPatchConfig(
disabled_patchers={"anthropic.init.async"},
)
)

New public surfaces introduced by this PR:

braintrust.integrations.AnthropicIntegration
braintrust.integrations.IntegrationPatchConfig
braintrust.integrations.anthropic.wrap_anthropic

Existing exports:

braintrust.wrappers.anthropic.wrap_anthropic still works for compatibility

In practical terms, this PR is additive for users:

no intended breaking change for existing Anthropic wrapper usage
new ability to selectively instrument Anthropic sync vs async constructor paths
new public integration API that future providers can migrate onto

Cedric / ViaDézo1er (viadezo1er)

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done (unless there's an explicit customer request)?

Cedric / ViaDézo1er (viadezo1er) · 2026-03-23T22:09:49Z

+
+Keep the class focused on orchestration. Provider-specific tracing logic should stay in `tracing.py`.
+
+If the provider already supports direct instance wrapping, expose a `wrap(client)` method on the integration class that returns the traced client wrapper.


Which providers do this?

I needed to update the skill - I deleted this .wrap stuff, will fix!

Cedric / ViaDézo1er (viadezo1er)

(I don't know if this is a plausible situation)

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

Or maybe we don't want to have any code shared between providers?

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:26:08Z

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

We can just add a utility folder, or figure that out at this time.

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:37:45Z

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done

no, we can just do this on a case by case basis. Not that much activity on this repo, so we can get away with less merge conflicts.

Cedric / ViaDézo1er (viadezo1er)

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

Good to merge

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:51:11Z

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

yeah I gotta fix that. Thanks for the review!

Convert the Google ADK (Agent Development Kit) instrumentation from the legacy wrappers pattern to the new integrations API introduced in #118. - Extract tracing helpers into integrations/adk/tracing.py - Create ADK patchers (agent, runner, flow, mcp_tool) in patchers.py - Add AdkIntegration class with proper registration - Move tests and cassettes from wrappers/adk/ to integrations/adk/ - Move auto_instrument test script to integrations/auto_test_scripts/ - Slim down wrappers/adk/__init__.py to delegate to integrations - Update noxfile.py with ADK integration test sessions - Update integrations base and registry for ADK support

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T21:20:44Z

This PR introduces a new integrations API for provider instrumentation (wrappers) and migrates Anthropic to it as the first implementation. The goal is to separate three concerns that were previously mixed together in individual wrappers:

integration discovery and version compatibility
patch selection and idempotent patch application
provider-specific tracing behavior

This PR is inspired by the current Ruby SDK implementation.

AI Summary

A new base integration layer lives under py/src/braintrust/integrations/. BaseIntegration is the orchestration class. It is responsible for:

probing whether an integration is installed
detecting the installed version
checking compatibility bounds
exposing the patchers available for that integration
resolving enabled_patchers / disabled_patchers
applying patchers in a deterministic, idempotent way

Conceptually, BaseIntegration.setup() is now the standard entry point for “instrument this library in the current process”.

BasePatcher is the unit of patch work. It represents one concrete patch strategy and is responsible for:

identifying itself with a stable patcher id
deciding whether it applies for the current runtime
checking whether its target is already patched
applying its patch once

This PR also adds FunctionWrapperPatcher, a reusable BasePatcher subclass for the common case where instrumentation is done with wrapt.wrap_function_wrapper against a single target path.

Supporting types added with this work:

IntegrationRuntime: normalized runtime facts for one integration (name, module, version)
IntegrationPatchConfig: user-facing config object for selecting patchers
versioning.py: a small stdlib-only helper for version detection and simple spec matching

Anthropic Migration

AnthropicIntegration defines:

name = "anthropic"
import_names = ("anthropic",)
min_version = "0.48.0"
two patchers:
- anthropic.init.sync
- anthropic.init.async

Those patchers wrap:

anthropic.Anthropic.__init__
anthropic.AsyncAnthropic.__init__

The constructor patching model is straightforward: after a client is constructed, Braintrust replaces the instance’s messages and beta.messages surfaces with traced wrappers. Those wrappers preserve Anthropic behavior while adding span creation, metadata capture, token metrics, time-to-first-token, stream aggregation, and error logging for sync, async, and streaming request paths.

This means the old Anthropic tracing logic did not disappear, but it was moved behind a cleaner integration boundary:

orchestration and patch selection now live in the integration layer
Anthropic-specific tracing remains local to the Anthropic implementation

The old braintrust.wrappers.anthropic module is now a compatibility shim that re-exports the new Anthropic wrapper entry points.

User-Facing Changes

The main user-facing change is that Anthropic instrumentation is now configurable instead of being strictly all-or-nothing.

Existing behavior still works:

importbraintrustbraintrust.auto_instrument()

Users can now also choose which Anthropic patchers to apply:

frombraintrustimportauto_instrumentfrombraintrust.integrationsimportIntegrationPatchConfigauto_instrument(
anthropic=IntegrationPatchConfig(
disabled_patchers={"anthropic.init.async"},
)
)

New public surfaces introduced by this PR:

braintrust.integrations.AnthropicIntegration
braintrust.integrations.IntegrationPatchConfig
braintrust.integrations.anthropic.wrap_anthropic

Existing exports:

braintrust.wrappers.anthropic.wrap_anthropic still works for compatibility

In practical terms, this PR is additive for users:

no intended breaking change for existing Anthropic wrapper usage
new ability to selectively instrument Anthropic sync vs async constructor paths
new public integration API that future providers can migrate onto

Cedric / ViaDézo1er (viadezo1er)

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done (unless there's an explicit customer request)?

Cedric / ViaDézo1er (viadezo1er) · 2026-03-23T22:09:49Z

+
+Keep the class focused on orchestration. Provider-specific tracing logic should stay in `tracing.py`.
+
+If the provider already supports direct instance wrapping, expose a `wrap(client)` method on the integration class that returns the traced client wrapper.


Which providers do this?

I needed to update the skill - I deleted this .wrap stuff, will fix!

Cedric / ViaDézo1er (viadezo1er)

(I don't know if this is a plausible situation)

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

Or maybe we don't want to have any code shared between providers?

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:26:08Z

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

We can just add a utility folder, or figure that out at this time.

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:37:45Z

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done

no, we can just do this on a case by case basis. Not that much activity on this repo, so we can get away with less merge conflicts.

Cedric / ViaDézo1er (viadezo1er)

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

Good to merge

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:51:11Z

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

yeah I gotta fix that. Thanks for the review!

Convert the Google ADK (Agent Development Kit) instrumentation from the legacy wrappers pattern to the new integrations API introduced in #118. - Extract tracing helpers into integrations/adk/tracing.py - Create ADK patchers (agent, runner, flow, mcp_tool) in patchers.py - Add AdkIntegration class with proper registration - Move tests and cassettes from wrappers/adk/ to integrations/adk/ - Move auto_instrument test script to integrations/auto_test_scripts/ - Slim down wrappers/adk/__init__.py to delegate to integrations - Update noxfile.py with ADK integration test sessions - Update integrations base and registry for ADK support

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T21:20:44Z

This PR introduces a new integrations API for provider instrumentation (wrappers) and migrates Anthropic to it as the first implementation. The goal is to separate three concerns that were previously mixed together in individual wrappers:

integration discovery and version compatibility
patch selection and idempotent patch application
provider-specific tracing behavior

This PR is inspired by the current Ruby SDK implementation.

AI Summary

A new base integration layer lives under py/src/braintrust/integrations/. BaseIntegration is the orchestration class. It is responsible for:

probing whether an integration is installed
detecting the installed version
checking compatibility bounds
exposing the patchers available for that integration
resolving enabled_patchers / disabled_patchers
applying patchers in a deterministic, idempotent way

Conceptually, BaseIntegration.setup() is now the standard entry point for “instrument this library in the current process”.

BasePatcher is the unit of patch work. It represents one concrete patch strategy and is responsible for:

identifying itself with a stable patcher id
deciding whether it applies for the current runtime
checking whether its target is already patched
applying its patch once

This PR also adds FunctionWrapperPatcher, a reusable BasePatcher subclass for the common case where instrumentation is done with wrapt.wrap_function_wrapper against a single target path.

Supporting types added with this work:

IntegrationRuntime: normalized runtime facts for one integration (name, module, version)
IntegrationPatchConfig: user-facing config object for selecting patchers
versioning.py: a small stdlib-only helper for version detection and simple spec matching

Anthropic Migration

AnthropicIntegration defines:

name = "anthropic"
import_names = ("anthropic",)
min_version = "0.48.0"
two patchers:
- anthropic.init.sync
- anthropic.init.async

Those patchers wrap:

anthropic.Anthropic.__init__
anthropic.AsyncAnthropic.__init__

The constructor patching model is straightforward: after a client is constructed, Braintrust replaces the instance’s messages and beta.messages surfaces with traced wrappers. Those wrappers preserve Anthropic behavior while adding span creation, metadata capture, token metrics, time-to-first-token, stream aggregation, and error logging for sync, async, and streaming request paths.

This means the old Anthropic tracing logic did not disappear, but it was moved behind a cleaner integration boundary:

orchestration and patch selection now live in the integration layer
Anthropic-specific tracing remains local to the Anthropic implementation

The old braintrust.wrappers.anthropic module is now a compatibility shim that re-exports the new Anthropic wrapper entry points.

User-Facing Changes

The main user-facing change is that Anthropic instrumentation is now configurable instead of being strictly all-or-nothing.

Existing behavior still works:

importbraintrustbraintrust.auto_instrument()

Users can now also choose which Anthropic patchers to apply:

frombraintrustimportauto_instrumentfrombraintrust.integrationsimportIntegrationPatchConfigauto_instrument(
anthropic=IntegrationPatchConfig(
disabled_patchers={"anthropic.init.async"},
)
)

New public surfaces introduced by this PR:

braintrust.integrations.AnthropicIntegration
braintrust.integrations.IntegrationPatchConfig
braintrust.integrations.anthropic.wrap_anthropic

Existing exports:

braintrust.wrappers.anthropic.wrap_anthropic still works for compatibility

In practical terms, this PR is additive for users:

no intended breaking change for existing Anthropic wrapper usage
new ability to selectively instrument Anthropic sync vs async constructor paths
new public integration API that future providers can migrate onto

Cedric / ViaDézo1er (viadezo1er)

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done (unless there's an explicit customer request)?

Cedric / ViaDézo1er (viadezo1er) · 2026-03-23T22:09:49Z

+
+Keep the class focused on orchestration. Provider-specific tracing logic should stay in `tracing.py`.
+
+If the provider already supports direct instance wrapping, expose a `wrap(client)` method on the integration class that returns the traced client wrapper.


Which providers do this?

I needed to update the skill - I deleted this .wrap stuff, will fix!

Cedric / ViaDézo1er (viadezo1er)

(I don't know if this is a plausible situation)

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

Or maybe we don't want to have any code shared between providers?

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:26:08Z

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

We can just add a utility folder, or figure that out at this time.

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:37:45Z

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done

no, we can just do this on a case by case basis. Not that much activity on this repo, so we can get away with less merge conflicts.

Cedric / ViaDézo1er (viadezo1er)

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

Good to merge

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:51:11Z

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

yeah I gotta fix that. Thanks for the review!

Convert the Google ADK (Agent Development Kit) instrumentation from the legacy wrappers pattern to the new integrations API introduced in #118. - Extract tracing helpers into integrations/adk/tracing.py - Create ADK patchers (agent, runner, flow, mcp_tool) in patchers.py - Add AdkIntegration class with proper registration - Move tests and cassettes from wrappers/adk/ to integrations/adk/ - Move auto_instrument test script to integrations/auto_test_scripts/ - Slim down wrappers/adk/__init__.py to delegate to integrations - Update noxfile.py with ADK integration test sessions - Update integrations base and registry for ADK support

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T21:20:44Z

This PR introduces a new integrations API for provider instrumentation (wrappers) and migrates Anthropic to it as the first implementation. The goal is to separate three concerns that were previously mixed together in individual wrappers:

integration discovery and version compatibility
patch selection and idempotent patch application
provider-specific tracing behavior

This PR is inspired by the current Ruby SDK implementation.

AI Summary

A new base integration layer lives under py/src/braintrust/integrations/. BaseIntegration is the orchestration class. It is responsible for:

probing whether an integration is installed
detecting the installed version
checking compatibility bounds
exposing the patchers available for that integration
resolving enabled_patchers / disabled_patchers
applying patchers in a deterministic, idempotent way

Conceptually, BaseIntegration.setup() is now the standard entry point for “instrument this library in the current process”.

BasePatcher is the unit of patch work. It represents one concrete patch strategy and is responsible for:

identifying itself with a stable patcher id
deciding whether it applies for the current runtime
checking whether its target is already patched
applying its patch once

This PR also adds FunctionWrapperPatcher, a reusable BasePatcher subclass for the common case where instrumentation is done with wrapt.wrap_function_wrapper against a single target path.

Supporting types added with this work:

IntegrationRuntime: normalized runtime facts for one integration (name, module, version)
IntegrationPatchConfig: user-facing config object for selecting patchers
versioning.py: a small stdlib-only helper for version detection and simple spec matching

Anthropic Migration

AnthropicIntegration defines:

name = "anthropic"
import_names = ("anthropic",)
min_version = "0.48.0"
two patchers:
- anthropic.init.sync
- anthropic.init.async

Those patchers wrap:

anthropic.Anthropic.__init__
anthropic.AsyncAnthropic.__init__

The constructor patching model is straightforward: after a client is constructed, Braintrust replaces the instance’s messages and beta.messages surfaces with traced wrappers. Those wrappers preserve Anthropic behavior while adding span creation, metadata capture, token metrics, time-to-first-token, stream aggregation, and error logging for sync, async, and streaming request paths.

This means the old Anthropic tracing logic did not disappear, but it was moved behind a cleaner integration boundary:

orchestration and patch selection now live in the integration layer
Anthropic-specific tracing remains local to the Anthropic implementation

The old braintrust.wrappers.anthropic module is now a compatibility shim that re-exports the new Anthropic wrapper entry points.

User-Facing Changes

The main user-facing change is that Anthropic instrumentation is now configurable instead of being strictly all-or-nothing.

Existing behavior still works:

importbraintrustbraintrust.auto_instrument()

Users can now also choose which Anthropic patchers to apply:

frombraintrustimportauto_instrumentfrombraintrust.integrationsimportIntegrationPatchConfigauto_instrument(
anthropic=IntegrationPatchConfig(
disabled_patchers={"anthropic.init.async"},
)
)

New public surfaces introduced by this PR:

braintrust.integrations.AnthropicIntegration
braintrust.integrations.IntegrationPatchConfig
braintrust.integrations.anthropic.wrap_anthropic

Existing exports:

braintrust.wrappers.anthropic.wrap_anthropic still works for compatibility

In practical terms, this PR is additive for users:

no intended breaking change for existing Anthropic wrapper usage
new ability to selectively instrument Anthropic sync vs async constructor paths
new public integration API that future providers can migrate onto

Cedric / ViaDézo1er (viadezo1er)

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done (unless there's an explicit customer request)?

Cedric / ViaDézo1er (viadezo1er) · 2026-03-23T22:09:49Z

+
+Keep the class focused on orchestration. Provider-specific tracing logic should stay in `tracing.py`.
+
+If the provider already supports direct instance wrapping, expose a `wrap(client)` method on the integration class that returns the traced client wrapper.


Which providers do this?

I needed to update the skill - I deleted this .wrap stuff, will fix!

Cedric / ViaDézo1er (viadezo1er)

(I don't know if this is a plausible situation)

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

Or maybe we don't want to have any code shared between providers?

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:26:08Z

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

We can just add a utility folder, or figure that out at this time.

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:37:45Z

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done

no, we can just do this on a case by case basis. Not that much activity on this repo, so we can get away with less merge conflicts.

Cedric / ViaDézo1er (viadezo1er)

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

Good to merge

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:51:11Z

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

yeah I gotta fix that. Thanks for the review!

Convert the Google ADK (Agent Development Kit) instrumentation from the legacy wrappers pattern to the new integrations API introduced in #118. - Extract tracing helpers into integrations/adk/tracing.py - Create ADK patchers (agent, runner, flow, mcp_tool) in patchers.py - Add AdkIntegration class with proper registration - Move tests and cassettes from wrappers/adk/ to integrations/adk/ - Move auto_instrument test script to integrations/auto_test_scripts/ - Slim down wrappers/adk/__init__.py to delegate to integrations - Update noxfile.py with ADK integration test sessions - Update integrations base and registry for ADK support

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T21:20:44Z

This PR introduces a new integrations API for provider instrumentation (wrappers) and migrates Anthropic to it as the first implementation. The goal is to separate three concerns that were previously mixed together in individual wrappers:

integration discovery and version compatibility
patch selection and idempotent patch application
provider-specific tracing behavior

This PR is inspired by the current Ruby SDK implementation.

AI Summary

A new base integration layer lives under py/src/braintrust/integrations/. BaseIntegration is the orchestration class. It is responsible for:

probing whether an integration is installed
detecting the installed version
checking compatibility bounds
exposing the patchers available for that integration
resolving enabled_patchers / disabled_patchers
applying patchers in a deterministic, idempotent way

Conceptually, BaseIntegration.setup() is now the standard entry point for “instrument this library in the current process”.

BasePatcher is the unit of patch work. It represents one concrete patch strategy and is responsible for:

identifying itself with a stable patcher id
deciding whether it applies for the current runtime
checking whether its target is already patched
applying its patch once

This PR also adds FunctionWrapperPatcher, a reusable BasePatcher subclass for the common case where instrumentation is done with wrapt.wrap_function_wrapper against a single target path.

Supporting types added with this work:

IntegrationRuntime: normalized runtime facts for one integration (name, module, version)
IntegrationPatchConfig: user-facing config object for selecting patchers
versioning.py: a small stdlib-only helper for version detection and simple spec matching

Anthropic Migration

AnthropicIntegration defines:

name = "anthropic"
import_names = ("anthropic",)
min_version = "0.48.0"
two patchers:
- anthropic.init.sync
- anthropic.init.async

Those patchers wrap:

anthropic.Anthropic.__init__
anthropic.AsyncAnthropic.__init__

The constructor patching model is straightforward: after a client is constructed, Braintrust replaces the instance’s messages and beta.messages surfaces with traced wrappers. Those wrappers preserve Anthropic behavior while adding span creation, metadata capture, token metrics, time-to-first-token, stream aggregation, and error logging for sync, async, and streaming request paths.

This means the old Anthropic tracing logic did not disappear, but it was moved behind a cleaner integration boundary:

orchestration and patch selection now live in the integration layer
Anthropic-specific tracing remains local to the Anthropic implementation

The old braintrust.wrappers.anthropic module is now a compatibility shim that re-exports the new Anthropic wrapper entry points.

User-Facing Changes

The main user-facing change is that Anthropic instrumentation is now configurable instead of being strictly all-or-nothing.

Existing behavior still works:

importbraintrustbraintrust.auto_instrument()

Users can now also choose which Anthropic patchers to apply:

frombraintrustimportauto_instrumentfrombraintrust.integrationsimportIntegrationPatchConfigauto_instrument(
anthropic=IntegrationPatchConfig(
disabled_patchers={"anthropic.init.async"},
)
)

New public surfaces introduced by this PR:

braintrust.integrations.AnthropicIntegration
braintrust.integrations.IntegrationPatchConfig
braintrust.integrations.anthropic.wrap_anthropic

Existing exports:

braintrust.wrappers.anthropic.wrap_anthropic still works for compatibility

In practical terms, this PR is additive for users:

no intended breaking change for existing Anthropic wrapper usage
new ability to selectively instrument Anthropic sync vs async constructor paths
new public integration API that future providers can migrate onto

Cedric / ViaDézo1er (viadezo1er)

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done (unless there's an explicit customer request)?

Cedric / ViaDézo1er (viadezo1er) · 2026-03-23T22:09:49Z

+
+Keep the class focused on orchestration. Provider-specific tracing logic should stay in `tracing.py`.
+
+If the provider already supports direct instance wrapping, expose a `wrap(client)` method on the integration class that returns the traced client wrapper.


Which providers do this?

I needed to update the skill - I deleted this .wrap stuff, will fix!

Cedric / ViaDézo1er (viadezo1er)

(I don't know if this is a plausible situation)

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

Or maybe we don't want to have any code shared between providers?

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:26:08Z

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

We can just add a utility folder, or figure that out at this time.

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:37:45Z

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done

no, we can just do this on a case by case basis. Not that much activity on this repo, so we can get away with less merge conflicts.

Cedric / ViaDézo1er (viadezo1er)

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

Good to merge

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:51:11Z

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

yeah I gotta fix that. Thanks for the review!

Convert the Google ADK (Agent Development Kit) instrumentation from the legacy wrappers pattern to the new integrations API introduced in #118. - Extract tracing helpers into integrations/adk/tracing.py - Create ADK patchers (agent, runner, flow, mcp_tool) in patchers.py - Add AdkIntegration class with proper registration - Move tests and cassettes from wrappers/adk/ to integrations/adk/ - Move auto_instrument test script to integrations/auto_test_scripts/ - Slim down wrappers/adk/__init__.py to delegate to integrations - Update noxfile.py with ADK integration test sessions - Update integrations base and registry for ADK support

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T21:20:44Z

This PR introduces a new integrations API for provider instrumentation (wrappers) and migrates Anthropic to it as the first implementation. The goal is to separate three concerns that were previously mixed together in individual wrappers:

integration discovery and version compatibility
patch selection and idempotent patch application
provider-specific tracing behavior

This PR is inspired by the current Ruby SDK implementation.

AI Summary

A new base integration layer lives under py/src/braintrust/integrations/. BaseIntegration is the orchestration class. It is responsible for:

probing whether an integration is installed
detecting the installed version
checking compatibility bounds
exposing the patchers available for that integration
resolving enabled_patchers / disabled_patchers
applying patchers in a deterministic, idempotent way

Conceptually, BaseIntegration.setup() is now the standard entry point for “instrument this library in the current process”.

BasePatcher is the unit of patch work. It represents one concrete patch strategy and is responsible for:

identifying itself with a stable patcher id
deciding whether it applies for the current runtime
checking whether its target is already patched
applying its patch once

This PR also adds FunctionWrapperPatcher, a reusable BasePatcher subclass for the common case where instrumentation is done with wrapt.wrap_function_wrapper against a single target path.

Supporting types added with this work:

IntegrationRuntime: normalized runtime facts for one integration (name, module, version)
IntegrationPatchConfig: user-facing config object for selecting patchers
versioning.py: a small stdlib-only helper for version detection and simple spec matching

Anthropic Migration

AnthropicIntegration defines:

name = "anthropic"
import_names = ("anthropic",)
min_version = "0.48.0"
two patchers:
- anthropic.init.sync
- anthropic.init.async

Those patchers wrap:

anthropic.Anthropic.__init__
anthropic.AsyncAnthropic.__init__

The constructor patching model is straightforward: after a client is constructed, Braintrust replaces the instance’s messages and beta.messages surfaces with traced wrappers. Those wrappers preserve Anthropic behavior while adding span creation, metadata capture, token metrics, time-to-first-token, stream aggregation, and error logging for sync, async, and streaming request paths.

This means the old Anthropic tracing logic did not disappear, but it was moved behind a cleaner integration boundary:

orchestration and patch selection now live in the integration layer
Anthropic-specific tracing remains local to the Anthropic implementation

The old braintrust.wrappers.anthropic module is now a compatibility shim that re-exports the new Anthropic wrapper entry points.

User-Facing Changes

The main user-facing change is that Anthropic instrumentation is now configurable instead of being strictly all-or-nothing.

Existing behavior still works:

importbraintrustbraintrust.auto_instrument()

Users can now also choose which Anthropic patchers to apply:

frombraintrustimportauto_instrumentfrombraintrust.integrationsimportIntegrationPatchConfigauto_instrument(
anthropic=IntegrationPatchConfig(
disabled_patchers={"anthropic.init.async"},
)
)

New public surfaces introduced by this PR:

braintrust.integrations.AnthropicIntegration
braintrust.integrations.IntegrationPatchConfig
braintrust.integrations.anthropic.wrap_anthropic

Existing exports:

braintrust.wrappers.anthropic.wrap_anthropic still works for compatibility

In practical terms, this PR is additive for users:

no intended breaking change for existing Anthropic wrapper usage
new ability to selectively instrument Anthropic sync vs async constructor paths
new public integration API that future providers can migrate onto

Cedric / ViaDézo1er (viadezo1er)

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done (unless there's an explicit customer request)?

Cedric / ViaDézo1er (viadezo1er) · 2026-03-23T22:09:49Z

+
+Keep the class focused on orchestration. Provider-specific tracing logic should stay in `tracing.py`.
+
+If the provider already supports direct instance wrapping, expose a `wrap(client)` method on the integration class that returns the traced client wrapper.


Which providers do this?

I needed to update the skill - I deleted this .wrap stuff, will fix!

Cedric / ViaDézo1er (viadezo1er)

(I don't know if this is a plausible situation)

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

Or maybe we don't want to have any code shared between providers?

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:26:08Z

If some providers share a similar API and we could create some shared functions/classes to reduce LoC and improve code reuse, where should this shared code live?

We can just add a utility folder, or figure that out at this time.

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:37:45Z

Since we need to migrate all providers, should additional features for providers that haven't been migrated yet be postponed until their migration is done

no, we can just do this on a case by case basis. Not that much activity on this repo, so we can get away with less merge conflicts.

Cedric / ViaDézo1er (viadezo1er)

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

Good to merge

Abhijeet Prasad (AbhiPrasad) · 2026-03-23T22:51:11Z

I assume the CI is failing because the old tests are running against the new codebase and it has to be merged for the tests to be updated?

yeah I gotta fix that. Thanks for the review!

Convert the Google ADK (Agent Development Kit) instrumentation from the legacy wrappers pattern to the new integrations API introduced in #118. - Extract tracing helpers into integrations/adk/tracing.py - Create ADK patchers (agent, runner, flow, mcp_tool) in patchers.py - Add AdkIntegration class with proper registration - Move tests and cassettes from wrappers/adk/ to integrations/adk/ - Move auto_instrument test script to integrations/auto_test_scripts/ - Slim down wrappers/adk/__init__.py to delegate to integrations - Update noxfile.py with ADK integration test sessions - Update integrations base and registry for ADK support

Abhijeet Prasad (AbhiPrasad) requested review from Stephen Belanger (Qard) and Cedric / ViaDézo1er (viadezo1er)March 23, 2026 21:20

Abhijeet Prasad (AbhiPrasad) self-assigned this Mar 23, 2026

Abhijeet Prasad (AbhiPrasad)force-pushed the abhi-new-integrations-api branch 3 times, most recently from aab6190 to a837b93Compare March 23, 2026 21:54

Cedric / ViaDézo1er (viadezo1er) reviewed Mar 23, 2026
View reviewed changes

Abhijeet Prasad (AbhiPrasad)force-pushed the abhi-new-integrations-api branch from a837b93 to 90e9cceCompare March 23, 2026 22:33

Cedric / ViaDézo1er (viadezo1er) reviewed Mar 23, 2026
View reviewed changes

Comment threadpy/src/braintrust/integrations/anthropic/__init__.py Outdated
Comment threadpy/src/braintrust/integrations/anthropic/patchers.py Outdated

Cedric / ViaDézo1er (viadezo1er) approved these changes Mar 23, 2026
View reviewed changes

Abhijeet Prasad (AbhiPrasad)force-pushed the abhi-new-integrations-api branch from 90e9cce to d179fbdCompare March 23, 2026 22:49

Abhijeet Prasad (AbhiPrasad)force-pushed the abhi-new-integrations-api branch from d179fbd to 218ce96Compare March 23, 2026 22:51

feat: Introduce new integrations API and convert anthropic
11d3bd7

Abhijeet Prasad (AbhiPrasad)force-pushed the abhi-new-integrations-api branch from 218ce96 to 11d3bd7Compare March 23, 2026 22:57

Abhijeet Prasad (AbhiPrasad) merged commit 363baa0 into mainMar 23, 2026
33 checks passed

Abhijeet Prasad (AbhiPrasad) deleted the abhi-new-integrations-api branch March 23, 2026 23:12

Abhijeet Prasad (AbhiPrasad) mentioned this pull request Mar 24, 2026
ref(adk): migrate ADK wrapper to integrations API #122
Merged

Abhijeet Prasad (AbhiPrasad) mentioned this pull request Mar 31, 2026
ref(pydantic_ai): migrate wrapper to integration patchers #182
Merged