feat: Introduce new integrations API and convert anthropic

[Abhijeet Prasad (AbhiPrasad)]

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:

import braintrust
braintrust.auto_instrument()

Users can now also choose which Anthropic patchers to apply:

from braintrust import auto_instrument
from braintrust.integrations import IntegrationPatchConfig

auto_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

[ViaDézo1er / cedric (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)?

[ViaDézo1er / cedric (viadezo1er)]

Which providers do this?

[Abhijeet Prasad (AbhiPrasad)]

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

[ViaDézo1er / cedric (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)]

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)]

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.

[ViaDézo1er / cedric (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)]

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!