What does LangSmith's wrap_openai add that a plain @traceable does not?

## The problem the wrapper solves `@traceable` is generic. It knows a function was called, with what arguments, and what it returned. It has no idea whether that function talked to a language model, and it certainly does not know how many tokens the provider billed you for. Cost and token analytics in LangSmith are computed from the run's usage numbers plus the model name, and those only exist if something captured the provider's response envelope. That is the job of a provider wrapper. ## What wrap_openai does ``` from langsmith.wrappers import wrap_openai from openai import OpenAI client = wrap_openai(OpenAI()) ``` The call returns the same client object with its completion methods patched. From then on, every request through that client produces an `llm`-typed run containing: - the full **message list** sent, in role/content form, which the UI renders as a conversation rather than a JSON blob; - the **invocation parameters** — `model`, `temperature`, `max_tokens`, tool/function definitions, and so on; - the **response**, including tool calls and finish reason; - the **token usage** from the provider's response (prompt/input and completion/output counts), which is what drives the cost column and the token charts. It also handles **streaming**. A streamed response arrives as many chunks; the wrapper aggregates them into one logical output so the run shows a single completed message instead of hundreds of fragments, and still ends the run with correct timing. It applies to both sync and async clients, and it accepts a `tracing_extra` argument if you want fixed metadata, tags or a project override on every model call made through that client. ## How it composes with @traceable The two are complementary, not alternatives. In a typical application you wrap the provider client once at startup and decorate your own orchestration code: - `@traceable` on `answer_question(...)` gives you the business-level run: the user's question in, the final answer out. - The wrapped client gives you a child `llm` run per model call underneath it, with the prompt actually sent after templating and the tokens actually spent. Because nesting is implicit through the active-run context, you get one tree: business call at the root, retrieval and tool runs beside it, model calls as leaves. That tree is what makes debugging tractable — you can see the exact prompt that produced a bad answer, not the arguments to the function that built it. ## What you lose without it If you call the raw OpenAI client from inside a `@traceable` function, you still get a trace, but: - the run is typed `chain`, so no cost and no token attribution; - the prompt appears only if you happened to return or log it, and the actual rendered prompt is often assembled deep inside your function where the decorator cannot see it; - streaming responses show up as whatever your function chose to return; - you cannot open the call in the playground to iterate on the prompt, because the platform does not have a structured model call to reconstruct. The fallback if you cannot patch the client — say a provider with no wrapper — is to put `@traceable(run_type="llm")` on a thin function that performs the call and to shape its inputs and outputs to look like a model call, including a usage field. That is more work and easier to get subtly wrong, which is precisely why the wrapper exists. ## Practical notes Wrap once, at client construction, and inject the wrapped client everywhere; wrapping repeatedly in a hot path is wasteful and confusing. If tracing is disabled by environment, the wrapped client behaves exactly like the unwrapped one, so it is safe to leave in place across environments. Note also that the wrapper puts prompt and completion **content** into the trace store by default — that is the point of it, and it is also the thing a regulated team has to think about before switching it on, since redaction then has to be configured explicitly rather than inherited from your own logging discipline. Finally, do not confuse the wrapper with a proxy. It is an in-process patch on the SDK object; requests still go directly from your process to the provider, and LangSmith receives an asynchronous copy of the metadata. Nothing sits in the request path, so a LangSmith outage cannot fail your model call.