wrapAnthropic + LANGSMITH_TRACING_MODE=otel traces don't auto-resolve in Playground

[BasRizk]

Summary

When tracing direct Anthropic SDK calls with wrapAnthropic under LANGSMITH_TRACING_MODE=otel, the resulting ChatAnthropic runs land in LangSmith correctly but the Playground tab cannot auto-resolve the model dropdown — it falls back to the workspace default model. Equivalent runs produced by LangChain Python's ChatAnthropic (also via the OTel ingest path) DO resolve correctly, and wrapOpenAI + OTel under the same setup also resolves correctly. The gap appears to be Anthropic-specific.

For background, see the original (broader) report and bisection at #2923 — that issue covered both OpenAI and Anthropic, and the OpenAI half is healthy at the SDK level.

Environment

• langsmith JS: 0.7.2 (latest at time of report)
• @anthropic-ai/sdk: 0.95.x
• Node 22 / TypeScript
• OTel pipeline initialized via initializeOTEL() from langsmith/experimental/otel/setup
• LANGSMITH_TRACING_MODE=otel, LANGSMITH_TRACING=true

Minimal reproduction

import { initializeOTEL } from "langsmith/experimental/otel/setup"
initializeOTEL()

import Anthropic from "@anthropic-ai/sdk"
import { wrapAnthropic } from "langsmith/wrappers/anthropic"

const anthropic = wrapAnthropic(new Anthropic())
await anthropic.messages.create({
  model: "claude-haiku-4-5",       // also tried "claude-haiku-4-5-20251001"
  max_tokens: 100,
  messages: [{ role: "user", content: "Say hi." }],
})

Open the resulting ChatAnthropic run in LangSmith → Playground tab.

Observed: model dropdown falls back to workspace default.
Expected: dropdown resolves to the Claude variant used.

The same harness with wrapOpenAI(new OpenAI()) + chat.completions.create resolves correctly — so the OTel pipeline, initializeOTEL, and Playground itself are all functional in this workspace. The variable is wrapAnthropic vs. wrapOpenAI.

What the trace contains

Tried two variants, both as root runs (no parent_run_id):

Variant	extra.metadata.ls_model_name	extra.invocation_params.model	Playground
A: requested claude-haiku-4-5 (alias)	claude-haiku-4-5	claude-haiku-4-5-20251001 (dated, from response)	Falls back
B: requested claude-haiku-4-5-20251001 (dated)	claude-haiku-4-5-20251001	claude-haiku-4-5-20251001	Falls back

Both traces have extra.metadata.ls_provider = "anthropic", ls_model_type = "chat", run_type = "llm", name = "ChatAnthropic" — matching the shape wrapOpenAI produces (just with ls_provider = "openai") where Playground auto-resolves. So the surface metadata looks complete from this side.

Contrast with LangChain Python ChatAnthropic under the same workspace and same OTel ingest path — those traces DO auto-resolve. So Playground UI supports Anthropic dropdown resolution, but the wrapAnthropic+OTel emission is missing whatever signal it relies on.

Asks

1. Is wrapAnthropic + OTel + Playground intended to be supported the same way the OpenAI counterpart is? If not, calling that out in the wrapper docs would help.
2. If yes, what attribute / metadata field is the LangChain Python ChatAnthropic path emitting that wrapAnthropic isn't? Once identified, either wrapAnthropic could emit it directly, or a documented metadata key (settable from the call site) would unblock OTel users.

Reproduction harness ready for any candidate fix.

[yumuzi234]

BasRizk, the fix for #2923 is in playground UI side, which is not release to the most recent playground ui yet

[BasRizk]

Same root cause: non-model invocation_params don't propagate either

Worth flagging that the Anthropic dropdown gap appears to be one symptom of a broader pattern. The OpenAI side auto-resolves the dropdown (model gets through gen_ai.request.model), but other Playground config fields (Max Output Tokens, Reasoning Effort dropdown, Service Tier, etc.) stay blank — for the same reason: nothing else gets forwarded to top-level extra.invocation_params.

extra.invocation_params (top-level) — what Playground UI pre-fills FROM

Same workspace, same LANGSMITH_TRACING_MODE=otel, same model. Only difference is the SDK:

LangChain Python ChatOpenAI (Playground pre-fills correctly):

{
  "_type": "openai-chat",
  "max_completion_tokens": 2048,
  "model": "gpt-5-mini",
  "model_name": "gpt-5-mini",
  "prompt_cache_key": "playground_lc_smoke",
  "reasoning_effort": "medium",
  "service_tier": "auto",
  "stop": null,
  "stream": false
}

wrapOpenAI + OTel (Playground stays blank):

{ "model": "gpt-5.4-nano-2026-03-17" }

wrapOpenAI does set langsmith.metadata.ls_invocation_params = {reasoning: {effort, summary}, service_tier, prompt_cache_key, use_responses_api} on the run, but it lands under extra.metadata.ls_invocation_params as a JSON blob — not at top-level extra.invocation_params where Playground's pre-fill code looks. And ls_max_tokens isn't captured at all when the Responses API's max_output_tokens field is used (only max_completion_tokens / max_tokens are checked at wrappers/openai.js:248).

Concrete Playground UI symptoms for the OpenAI side

• Max Output Tokens field → blank
• Reasoning Effort dropdown → shows "Default" even though reasoning.effort: medium is in ls_invocation_params. The value DOES land in the Extra Parameters JSON pane (so Replay actually uses it), but the dedicated dropdown isn't populated.
• Service Tier → not surfaced at all in the UI panel.

Why this is the same gap as the Anthropic dropdown issue above

Whatever propagation/normalization step LangChain Python relies on (writing all ls_* and other params straight into extra.invocation_params) doesn't happen for wrap* + OTel. For OpenAI that just means "config fields blank in Playground." For Anthropic — where Playground apparently uses the same data to also identify the provider/model panel to render — that same gap manifests as the dropdown not resolving at all.

A fix that propagates extra.metadata.ls_invocation_params and extra.metadata.ls_max_tokens into top-level extra.invocation_params would likely close both the OpenAI Playground pre-fill issue AND (assuming Anthropic Playground reads similarly) the Anthropic dropdown auto-resolution.

[BasRizk]

Thanks Zhen (@yumuzi234) !!

I am just sharing other aspect here also regarding the invocation_params, I hope that this is also has been taking care of. Is there an expected timeline to observe the fix you mentioned on my end?