langsmith-sdk: the two client libraries behind LangSmith tracing and evaluation

One repository, two client libraries

The GitHub description for this repository is four words: LangSmith Client SDK Implementations. That is accurate and it undersells the split. The README says this repository contains the Python and Javascript SDKs for interacting with the LangSmith platform, and the repository language field on GitHub reads Python. Those two facts sit oddly together, since a reader browsing by language filter will see a Python project and will find a `js/` directory that is not a minor port but a maintained SDK with its own release numbering.

The split is more than a packaging detail. Releases in this repo are tagged once at the repository level, and the tag body then contains separate `release(js)` and `release(py)` entries with different version numbers. The v0.12.6 tag, published 2026-09-16, contains a JavaScript release at 0.10.4 and a Python release at 0.12.6 in the same changelog. That means the git tag and the version on PyPI or npm are separate axes, and pinning has to happen in your language's package manager rather than against the repo tag.

The platform itself is what the clients talk to. The README frames the product in one sentence: LangSmith helps your team debug, evaluate, and monitor your language models and intelligent agents. Two qualifiers in that sentence matter. It works with any LLM application, not only LangChain ones, and there is a native integration with LangChain Python and LangChain JS. The company behind it is LangChain, the same company as the framework, which is the usual source of confusion between the two names.

At roughly 1,060 stars, 298 forks and 220 open issues, with the last push on 2026-09-19, this is a project in active high-output maintenance rather than a stable and quiet one.

The quick start is three environment variables and one wrapped client

The Python quick start is four lines of installation and configuration, and then a short snippet. The install step is `pip install -U langsmith`, followed by three environment variables: tracing turned on, an API key, and a workspace id that the comment marks as required for org-scoped keys.

That last comment is the part worth reading twice. If your key is scoped to an organization rather than to your personal account, the workspace id is not optional, and the failure mode if you omit it is a confusing scope error rather than a clear configuration message. Setting it is cheap.

The code that follows does one interesting thing, which is wrapping the model client rather than instrumenting the call site. `wrap_openai` returns something that behaves like the OpenAI client you already have, and the trace appears as a side effect of calls you did not modify:

import openai
from langsmith import traceable
from langsmith.wrappers import wrap_openai

client = wrap_openai(openai.Client())

client.chat.completions.create(
    messages=[{"role": "user", "content": "Hello, world"}],
    model="gpt-5.4"
)

Notice that `traceable` is imported in the snippet and never used. That is a small honesty about how the README is written: it shows you the two entry points a working application needs, the wrapper for provider clients and the decorator for your own functions, and leaves it to you to apply the decorator to the code that actually orchestrates your agent.

The JavaScript path is the same shape, with the two import paths spelled out for you, which is the more useful part of that snippet:

import { OpenAI } from "openai";
import { traceable } from "langsmith/traceable";
import { wrapOpenAI } from "langsmith/wrappers";

const client = wrapOpenAI(new OpenAI());

The subpath imports mean the package supports tree shaking, so a JavaScript application that only wants tracing does not have to pull the wrapper surface in with it. The README then prints a sample completion response object so you can see what an unwrapped return value looks like, which is a useful check that the wrapper is meant to be transparent.

What the directory tree says about where the work actually is

The root tree is short and telling: `.github/`, `_scripts/`, `examples/`, `js/`, `openapi/`, `openwiki/`, `python/`, plus `Makefile`, `README.md`, `LICENSE`, `CONTRIBUTING.md` and three dotfiles that most readers will never open.

Three entries earn attention. `openapi/` suggests the platform surface is specified as an API contract and that the clients are generated or checked against it, which is the reason the SDKs can stay in step with a hosted service. `openwiki/` is new enough that it tells a story on its own, and the v0.12.6 changelog says what it is: a docs addition, OpenWiki, with a weekly refresh workflow. So the repository now contains reference documentation of its own, kept current on a schedule, rather than only prose written by hand.

`AGENTS.md` and `CLAUDE.md` sit side by side in the root. Two agent instruction files in one repository is a fairly strong signal about how contributors are expected to work on it, and it is also a reasonable thing to read before opening a pull request, because they describe the shape the maintainers want changes to take.

The tooling files fit the same picture. `.pre-commit-config.yaml` is the local gate, `.mlc_config.json` configures markdown link checking, and `.readthedocs.yml` confirms the Python documentation is built on Read the Docs rather than hosted from this repository. `examples/` contains exactly one file, `insights_agent_youtube.ipynb`, which is a notebook rather than a script.

The root `Makefile` is where the dual SDK layout becomes concrete. Both the format and lint targets fan out to the two language directories and then wait for both, so one command at the root is the correct way to keep both SDKs consistent after a change rather than remembering to run each one.

Release notes as a map of the current surface area

Three releases in the recent history, published within four days of each other in September 2026, describe more of the SDK than the README does. Reading them together is the fastest way to understand what the client actually does.

The largest theme is a sandbox subsystem that is growing fast. The v0.13.0 changelog, published 2026-09-18, lists support for AWS IAM roles in both the Python and the JavaScript helpers, a change adding `run_config` plus stdin EOF plus native file search and range operations, and command streaming over an SSE exec API gated behind a feature flag. The v0.12.5 release two days earlier fixed preserving sandbox API error IDs, which is exactly the kind of fix you want to see for a subsystem that runs code: losing the server's error identifier makes an incident untraceable.

The second theme is evaluation observability, and it is more philosophical. v0.13.0 added a `disable_evaluator_tracing` toggle to `evaluate()` and `aevaluate()` in Python, and the matching option in JavaScript landed as its own pull request in the same release. Tracing your evaluators is useful right up until the volume of evaluation traces is the reason your tracing bill is large. Shipping a switch in both SDKs, in the same release, is a sign the team is treating tracing cost as a first-class concern rather than an afterthought.

The third theme is error fidelity. The JavaScript side was fixed to preserve the 403 JSON error body in `raiseForStatus`, which is the case where a plain status code tells you nothing about why a request was refused. v0.12.5 also added reporting of the configured tracing sample rate on runs, so a run record says what fraction of traffic it represents.

One more detail that reads as housekeeping but matters for a client library: a single release patchable vulnerabilities across the JS dependency tree, upgrading `js-yaml` from 3.15.1 to 4.3.1 in a test export path and patching vulnerable Vitest and Hono versions. For an SDK that runs inside other people's applications, that is part of the product rather than internal chores.

Where the README stops

The README is short, and it is honest about being short. After the quick start it points in three directions: the LangSmith documentation for how to use the platform and the client SDK, a separate cookbook repository for tutorials on getting more value out of the product, and the docs site again. There is no API reference in this README, no configuration table, and no list of environment variables beyond the three in the quick start.

So if you arrive with a specific question, the repository is a starting point rather than the place the answer lives. That is a normal arrangement for a hosted platform SDK and it is worth saying plainly, because the repository's own popularity is what tends to make people expect the docs to be here.

There is one gap worth flagging in the other direction as well. Nothing in the README or the release notes says anything about pricing, tiers, or what the free allowance looks like, so any question about whether the platform is free to use cannot be answered from this material. That question matters before you send production traffic, and the answer lives on the platform's own site rather than in this repository. The same goes for data retention, which for a tracing product is the question most teams should ask first and none of which the repository addresses.

What the repository does answer well is the integration question. If you want to know whether LangSmith is a hard dependency on LangChain, the README settles it: it works with any LLM application, and the LangChain integration is described as native rather than required. If you want to know what tracing looks like in code, the two snippets above are the whole story, and they are short enough to read before you install anything.

Editorial conclusion

This repository is deliberately thin at the top and thick underneath. The README you will read is a short on-ramp: install a package, set three environment variables, wrap a model client, and you have a trace. Everything else about LangSmith, including the evaluation model and the tracing configuration surface, is documented elsewhere. What the repository itself reveals is the shape of the surface area, and the recent releases describe that surface better than any prose summary could. Sandbox work is the fastest growing part, with AWS IAM role support, streamed command execution over an SSE API behind a feature flag, run_config plumbing and native file search and range operations landing within a single release. Evaluator tracing gained a toggle in the same release, which is the kind of change that matters when evaluation runs large enough to be noisy. Two things to hold onto before you pin a version. The git tag and the package version are not the same number, because v0.12.6 shipped JavaScript 0.10.4 inside it, so decide whether you track by git tag or by the language specific package you actually install. And 220 open issues on roughly a thousand stars is a high ratio, which usually reflects the rate of feature work rather than neglect, but it does mean the release notes are worth reading rather than skimming. If you are starting from nothing, wrap one model client, send three or four requests, look at the trace, and only then decide whether you need the evaluation and sandbox layers at all.

Frequently asked questions

Official sources

1. langchain-ai/langsmith-sdk on GitHub
2. License: MIT
3. Project website
4. README
5. Releases