LangSmith pricing is easy to misread as a simple per-trace subscription, but the effective cost per trace balloons once you account for nested runs, evaluation workloads, and retention. This analysis breaks down what you actually pay for when you instrument an LLM app with LangSmith, and where the meter quietly runs.
The trace is the unit, but not the cost atom
LangSmith meters on traces. A trace is a root run—typically one user-facing invocation of a chain, agent, or workflow. That sounds clean: if you serve 100,000 chat requests per month, you owe for 100,000 traces. But the moment your agent calls a retriever, three tools, and a summarizer, each of those becomes a child span under that root. LangSmith does not charge per span in the documented consumer tiers, yet spans drive storage volume, affect retention tier limits, and multiply the surface area for evaluation jobs that are priced separately or consume quota.
The trap is treating “trace” as an atomic event. It is a tree. The deeper and wider the tree, the more value you get from observability—and the more you should expect your bill to reflect indirect costs even if the line item says “per trace.”
Public pricing structure without the fantasy numbers
LangSmith publishes a free tier with a cap on traces per month and a paid tier that combines a base subscription (often seat-based) with a trace allowance and overage metering. Exact figures shift; the point is structural. You pay:
- A platform subscription, usually per seat per month.
- A bundle of traces included in that subscription.
- Overage charges per additional trace beyond the bundle.
- Optional add-ons: longer retention, higher rate limits, enterprise SSO.
When you route completions through a gateway such as n4n.ai—which exposes one OpenAI-compatible endpoint across 240+ models and meters per-token usage—you still need trace context to debug multi-step agents. LangSmith fills that gap, but its pricing is orthogonal to token cost. You pay the inference provider (or gateway) for tokens, and LangSmith for the trace metadata around those calls.
What actually counts as a trace
Any root run logged via the LangChain tracer or the raw langsmith SDK counts. If you use the SDK directly:
from langsmith import Client
client = Client()
client.create_run(
name="user_query",
run_type="chain",
inputs={"question": "What is the refund policy?"},
project_name="prod-support"
)That single create_run with is_root=True is one trace. If you never call end_run, it may still count as a partial trace depending on ingestion batching. Background tasks, async evaluations, and scheduled dataset runs can each spawn traces outside your user request path.
A common surprise: evaluation jobs. You might run 1,000 test cases against a dataset nightly. Each test case is a trace. That is 30,000 traces/month just for CI-style eval, on top of production traffic.
Hidden multipliers: nesting, evaluations, and storage
Consider an agent that does:
- 1 retrieval
- 3 tool calls (calculator, search, DB lookup)
- 1 final synthesis LLM call
That is 1 root + 5 child spans. LangSmith stores the full payloads: prompts, tool inputs, outputs, token counts, timings. At scale, storage—not trace count—can push you into a higher retention tier. The pricing page may not show storage as a separate line for small teams, but enterprise contracts absolutely negotiate it.
Evaluations are the second multiplier. If you use langsmith.evaluation to score outputs, each evaluation step can generate auxiliary runs. A typical evaluate() call creates a trace per example, plus inner runs for each metric. The code below estimates your real trace expansion factor:
from langsmith import Client
client = Client()
roots = client.list_runs(run_type="chain", is_root=True, limit=500)
span_counts = []
for r in roots:
children = client.list_runs(parent_run_id=r.id)
span_counts.append(len(children) + 1)
avg_spans = sum(span_counts) / len(span_counts)
print(f"Average spans per trace: {avg_spans}")If avg_spans is 6, your observability data volume is 6x the trace count. That does not directly inflate the per-trace price, but it determines whether you hit retention caps or need to pay for longer storage.
A concrete example: agent with 20 steps
Suppose you ship a customer-support agent. Traffic is 50,000 conversations/month. Each conversation is a trace. Inside, the agent averages:
- 1 planning LLM call
- 2 retrievals
- 4 tool calls
- 2 refinement calls
- 1 answer synthesis
That is ~10 spans/trace. You also run a nightly regression suite of 2,000 examples against the production dataset, each example a trace with 3 spans.
Production traces: 50,000. Eval traces: 60,000/month. Total traces: 110,000.
If your paid plan includes 50,000 traces and charges overage beyond that, you are paying overage for 60,000 traces. Add seats: a team of 5 engineers, each seat bundled with some allowance. The base subscription might dominate the bill, but the overage determines marginal cost.
Now factor storage: 110,000 traces × 10 spans × ~2 KB payload = ~2.2 GB/month of raw trace data. Retention of 30 days is fine; 1 year pushes you to negotiate.
The lesson: your effective cost per production trace is not (subscription + overage)/50,000. It is (subscription + overage + eval share + storage share)/50,000. Eval can double the numerator while only serving QA.
Tradeoffs: LangSmith vs self-hosted or alternative observability
LangSmith is the path of least resistance if you already use LangChain. The tracer integrates in one line:
from langchain.callbacks.tracers import LangChainTracer
tracer = LangChainTracer(project_name="prod-support")
chain.invoke({"input": "Refund status?"}, config={"callbacks": [tracer]})You get a UI, diffing, datasets, and eval harness. For small teams shipping fast, that velocity is worth the premium.
Self-hosting the open-source LangSmith-compatible server (or using an alternative like a custom OpenTelemetry pipeline) removes the per-trace subscription but introduces engineering cost: you run Postgres, a frontend, and build eval tooling. If your trace volume exceeds ~200k/month and your spans are shallow, the build-versus-buy line tilts toward build.
Alternative observability platforms (e.g., Helicone, Langfuse) often meter on requests or tokens, not traces. If your app is a single LLM call per request, those models map cleaner to cost. LangSmith’s trace model shines when you have complex graphs; its pricing is tuned for that value.
When LangSmith pricing makes sense
- You are building agentic workflows with many spans per user action.
- You need hosted eval datasets and regression tracking without maintaining them.
- Your team is <10 engineers and velocity beats infra ownership.
In those cases, the per-trace number is irrelevant; the bundled platform cost is a line item next to salary. You should still monitor eval trace bleed—schedule datasets to run on samples, not full sets, unless you need full coverage.
When it does not
- You serve a high-volume, low-complexity LLM proxy (one call per request).
- You already pipe telemetry to OTel and have Grafana.
- Your eval suite runs 1M examples nightly; the trace multiplier will bankrupt you.
Here, sample your production traces (e.g., 5% capture) and run eval on a fixed subset. LangSmith supports project-level sampling via environment variables, but you must configure it deliberately.
Takeaway
Calculate true cost per trace as (subscription + overage + allocated eval + allocated storage) divided by production traces, not total traces. If that number stays under your debugging-value threshold—roughly the cost of one engineer-hour per thousand traces—keep LangSmith. If nested agents and nightly evals push it past that, sample aggressively or move to a request-metered observability layer. LangSmith pricing is fair for complex LLM apps; it is only a trap if you mistake the trace for the atom.