Best LangSmith Alternatives 2026: 7 LLM Observability Tools Compared

Verdict

LangSmith is excellent inside its lane: LangChain-native dev workflows. Outside that lane, the alternatives often fit better:

• Production-first, framework-agnostic: ClawPulse.
• OSS + self-host: Langfuse or Phoenix.
• Eval-first: Braintrust.
• Proxy-style cost optimization: Helicone.
• Already on Datadog: Datadog LLM Observability.

Pick by the shape of your problem, not by what's hottest in HN this week. And remember: the right tool for prompt iteration is rarely the right tool for 3am alerts.

> 🇫🇷 Lecteur francophone ? Voir notre version FR : Meilleures alternatives à Langfuse en 2026 : 7 outils de monitoring d'agents IA comparés

---

May 2026 update — five-profile decision matrix: LangSmith vs ClawPulse vs the rest

Most "alternatives" articles dump a feature checklist and call it a day. Here is what we actually see in the field, broken down by team profile. We pulled this from 90+ migration conversations over Q1-Q2 2026 with teams running 1k–250k requests/day.

| Profile | Stack reality | Best fit | Why LangSmith is wrong | Why ClawPulse fits |

| --- | --- | --- | --- | --- |

| A. LangChain-native R&D (eval-heavy, prompt iteration) | Python, LangChain `@traceable`, Jupyter notebooks, 1–5 devs | LangSmith stays | (none — this is its sweet spot) | Not the right tool — keep LangSmith for offline evals |

| B. Production multi-provider agents (OpenAI + Anthropic + Mistral) | Node/Python, mixed SDKs, no framework lock-in | ClawPulse | LangChain-coupling pulls dead weight; OTel path is second-class | Framework-agnostic, agent-side, zero SDK changes |

| C. LangChain in prod at scale (>50k req/day, $5k+/mo LLM bill) | Python, LangChain, AWS/GCP, ops-aware team | ClawPulse + Phoenix for evals | LangSmith Plus tier scales linearly with traces — fast $1k/mo+ | Per-instance pricing, no trace tax, retry-storm detection |

| D. Compliance-first (Quebec/EU) | Any stack, Loi 25 / GDPR audits, SOC 2 in flight | ClawPulse | LangSmith data residency is US-East default; EU plan exists but adds latency and $$ | CA-host (Aiven Toronto), Loi 25 art.17/18/28.1 documented |

| E. Solo founder / weekend hacker | One repo, Vercel, $50–500/mo bill | Helicone free or ClawPulse Starter | LangSmith free tier limits + LangChain coupling = high friction for non-LangChain stacks | $19/mo Starter covers 5 instances, no trace caps |

The single most common migration we see: Profile B teams who adopted LangSmith because "it was the LangChain default" and now run 60% of their traffic via raw OpenAI/Anthropic SDKs — LangSmith captures the LangChain 40% well and the rest as opaque blobs. They migrate to ClawPulse, keep LangSmith for the few LangChain pipelines that still benefit from the tracing tree.

Drop-in instrumentation: replace LangSmith `@traceable` with a framework-agnostic wrapper

If you are migrating off LangSmith and want to keep observability without coupling to any framework, the pattern below is what we recommend. It is a thin observer over your LLM client — no proxy, no SDK fork, no `@traceable` decorator chain. Drop it into a shared `lib/llm-observe.ts` and call it from anywhere.

```typescript

// lib/llm-observe.ts — framework-agnostic LLM observer

// Replaces LangSmith's @traceable / RunTree without LangChain coupling.

import { createHash, randomUUID } from "node:crypto";

type LLMCall = {

provider: "openai" | "anthropic" | "mistral" | "groq" | string;

model: string;

messages: Array<{ role: string; content: string }>;

temperature?: number;

user_id?: string;

tenant_id?: string;

trace_id?: string; // root span id (compat with W3C traceparent)

parent_span_id?: string; // for nested calls (agents, tools)

};

type LLMResult = {

data: T;

usage?: { prompt_tokens?: number; completion_tokens?: number; total_tokens?: number };

cache_read?: boolean; // Anthropic prompt caching, OpenAI cached input

finish_reason?: string;

};

const CLAWPULSE_BEACON =

process.env.CLAWPULSE_INGEST_URL ?? "https://www.clawpulse.org/api/agent/event";

const TOKEN = process.env.CLAWPULSE_TOKEN ?? "";

function hashPrompt(messages: LLMCall["messages"]): string {

// Hash the messages so we can group retry storms by prompt without leaking content.

const normalized = messages.map(m => `${m.role}:${m.content}`).join("\n");

return createHash("sha256").update(normalized).digest("hex").slice(0, 16);

}

export async function instrumentLLMCall(

meta: LLMCall,

fn: () => Promise>

): Promise {

const span_id = randomUUID();

const trace_id = meta.trace_id ?? span_id;

const t0 = performance.now();

let status: "ok" | "error" = "ok";

let error_class: string | undefined;

let result: LLMResult | undefined;

try {

result = await fn();

return result.data;

} catch (err: any) {

status = "error";

error_class = err?.name ?? err?.constructor?.name ?? "Error";

// Don't swallow — observability must be transparent to call sites.

throw err;

} finally {

const latency_ms = Math.round(performance.now() - t0);

const event = {

schema: "llm.call.v1",

span_id,

trace_id,

parent_span_id: meta.parent_span_id,

ts: new Date().toISOString(),

provider: meta.provider,

model: meta.model,

latency_ms,

status,

error_class,

prompt_hash: hashPrompt(meta.messages),

message_count: meta.messages.length,

temperature: meta.temperature,

user_id: meta.user_id,

tenant_id: meta.tenant_id,

prompt_tokens: result?.usage?.prompt_tokens,

completion_tokens: result?.usage?.completion_tokens,

total_tokens: result?.usage?.total_tokens,

cache_read: result?.cache_read ?? false,

finish_reason: result?.finish_reason,

};

// Fire-and-forget — must not block the request hot path.

// 250ms hard timeout, no retry on the call site (the agent retries server-side).

Promise.race([

fetch(CLAWPULSE_BEACON, {

method: "POST",

headers: { "content-type": "application/json", authorization: `Bearer ${TOKEN}` },

body: JSON.stringify(event),

keepalive: true,

}).catch(() => {}),

new Promise(r => setTimeout(r, 250)),

]).catch(() => {});

}

}

// Usage — direct OpenAI SDK, no LangChain required:

//

// import OpenAI from "openai";

// const client = new OpenAI();

//

// const text = await instrumentLLMCall(

// { provider: "openai", model: "gpt-4o-mini", messages, user_id, tenant_id },

// async () => {

// const r = await client.chat.completions.create({ model: "gpt-4o-mini", messages });

// return {

// data: r.choices[0].message.content ?? "",

// usage: r.usage,

// finish_reason: r.choices[0].finish_reason,

// };

// }

// );

```

Three architectural wins versus LangSmith's `@traceable`:

1. No framework coupling. Works with raw OpenAI, Anthropic, Mistral, Groq, Ollama, vLLM. LangChain is not in the dependency graph.

2. Off the request hot path. The 250ms hard timeout + `keepalive: true` means a beacon outage never affects user latency. LangSmith's `@traceable` blocks the run unless you opt into background mode (and even then, the SDK is in your bundle).

3. Cache-aware billing. The `cache_read` flag lets ClawPulse charge cached tokens at the provider's discounted rate (Anthropic 0.1x, OpenAI cached input 0.5x). LangSmith displays raw tokens — your dashboard cost will diverge from your actual provider bill by 20–60% on cache-heavy workloads.

Postmortem: $11.4k Toronto fintech RAG retry storm — caught by ClawPulse in 9 minutes

A Toronto-based fintech (regulated, Loi 25 in scope) was running a customer-support RAG over Anthropic Claude Sonnet 4.5 with LangSmith tracing on the LangChain side and direct Anthropic SDK on a separate path. On April 18, 2026, a frontend `useEffect` regression triggered a 3x retrieval-corpus duplication on every chat turn. Within 4 hours:

• Anthropic prompt-tokens spend went from $1,200/day baseline to $11,400 in 4h (~$68k/day run rate).
• Anthropic dashboards showed nothing actionable — their daily-cost chart aggregates over 24h windows.
• LangSmith captured the LangChain pipeline cleanly, but the duplicated retrieval ran on the direct-SDK path and was invisible to LangSmith.
• ClawPulse's per-route z-score on `prompt_tokens` crossed 4.1 at minute 9, fired a Slack alert, and pinpointed the prompt_hash of the duplicated retrieval.

Time-to-detection: 9 minutes. Time-to-mitigation: 31 minutes. Estimated savings vs. catching at next-day Anthropic invoice: ~$54k, on a $49/mo Growth plan. The team kept LangSmith for offline RAG evaluation (which it does well) and moved production monitoring to ClawPulse.

Two non-obvious lessons:

• Coverage is the single biggest blind spot. LangSmith covered 40% of LLM traffic — the LangChain side. The other 60% (direct SDK calls for embeddings, reranking, classification) had no observability. Framework-coupled monitoring is structurally limited to the framework's call graph.
• Aggregation windows kill anomaly detection. Provider dashboards aggregate at hour/day boundaries. You need per-minute z-scores on prompt_tokens to catch retry storms before the bill arrives.

Four production SQL recipes — adapt to your warehouse

If you self-host or warehouse your LLM events (BigQuery, Snowflake, Postgres, ClickHouse), these are the four queries we run weekly. They are stack-agnostic — the schema below assumes a flat `llm_calls` table with columns matching the `llm.call.v1` event above.

1. Per-route p95 latency + cost outliers (last 24h)

```sql

SELECT

COALESCE(parent_span_id, trace_id) AS route,

COUNT(*) AS n,

APPROX_QUANTILES(latency_ms, 100)[OFFSET(95)] AS p95_ms,

SUM(prompt_tokens) AS in_tok,

SUM(completion_tokens) AS out_tok,

SUM(IF(cache_read, prompt_tokens, 0)) AS cached_in_tok,

SUM(IF(status='error', 1, 0)) AS errors

FROM llm_calls

WHERE ts > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 24 HOUR)

GROUP BY route

HAVING n >= 50

ORDER BY p95_ms DESC

LIMIT 25;

```

2. Retry-storm detection by prompt_hash (rolling z-score)

```sql

WITH per_min AS (

SELECT

TIMESTAMP_TRUNC(ts, MINUTE) AS minute,

prompt_hash,

COUNT(*) AS n

FROM llm_calls

WHERE ts > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)

GROUP BY minute, prompt_hash

),

baseline AS (

SELECT prompt_hash,

AVG(n) AS mu,

STDDEV(n) AS sigma

FROM per_min

WHERE minute < TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 MINUTE)

GROUP BY prompt_hash

HAVING COUNT(*) >= 20

)

SELECT p.minute, p.prompt_hash, p.n, b.mu, b.sigma,

SAFE_DIVIDE(p.n - b.mu, NULLIF(b.sigma, 0)) AS z

FROM per_min p JOIN baseline b USING (prompt_hash)

WHERE p.minute >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 MINUTE)

AND SAFE_DIVIDE(p.n - b.mu, NULLIF(b.sigma, 0)) > 3.0

ORDER BY z DESC;

```

3. Cache-read ratio degradation (Anthropic prompt caching, OpenAI cached input)

```sql

SELECT

DATE(ts) AS day,

provider,

model,

SUM(IF(cache_read, prompt_tokens, 0)) /

NULLIF(SUM(prompt_tokens), 0) AS cache_ratio,

SUM(prompt_tokens) AS total_in

FROM llm_calls

WHERE ts > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)

GROUP BY day, provider, model

ORDER BY day DESC, total_in DESC;

```

A drop from 0.65 to 0.30 cache_ratio overnight typically means a prompt template changed and broke the cache prefix — a $$$ silent regression LangSmith does not surface.

4. Multi-tenant fairness (catch a single tenant burning the budget)

```sql

SELECT

tenant_id,

COUNT(*) AS calls,

SUM(total_tokens) AS tokens,

SUM(total_tokens) * 1.0 / SUM(SUM(total_tokens)) OVER () AS share

FROM llm_calls

WHERE ts > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 24 HOUR)

GROUP BY tenant_id

ORDER BY tokens DESC

LIMIT 20;

```

If one `tenant_id` is consuming >60% of tokens, you have either a runaway customer, a missing rate-limit, or a bug. We have seen all three in the wild.

Seven-tool comparison: where LangSmith genuinely wins, and where it does not

We tested LangSmith, ClawPulse, Helicone, Langfuse (self-hosted), Phoenix (Arize), Braintrust, and Datadog LLM Observability across eight capabilities that matter in production. Scoring is May-2026 current.

| Capability | LangSmith | ClawPulse | Helicone | Langfuse SH | Phoenix | Braintrust | Datadog LLM |

| --- | --- | --- | --- | --- | --- | --- | --- |

| Framework-agnostic | ⚠️ OTel path is 2nd-class | ✅ Bash agent | ✅ Proxy | ✅ SDK | ✅ OTel | ⚠️ Eval-first | ✅ APM |

| Off request hot path | ⚠️ Background mode | ✅ Agent | ❌ Proxy SPOF | ⚠️ SDK | ✅ OTel | ⚠️ SDK | ⚠️ Agent |

| Cache-aware billing | ❌ Raw tokens | ✅ Discounted | ⚠️ Partial | ⚠️ Partial | ❌ | ❌ | ⚠️ |

| Retry-storm z-score | ❌ | ✅ Per-min | ⚠️ Manual | ⚠️ Manual | ❌ | ❌ | ⚠️ |

| Tracing tree depth | ✅ Best-in-class | ⚠️ Span-level | ⚠️ Flat | ✅ | ✅ | ⚠️ | ⚠️ |

| Offline evals + datasets | ✅ Best-in-class | ❌ | ❌ | ✅ | ✅ | ✅ | ❌ |

| Setup time (clean repo) | ~30 min | ~3 min | ~10 min | ~2 hours SH | ~20 min | ~30 min | ~1 hour |

| CA/EU data residency | ⚠️ EU plan +latency | ✅ Aiven Toronto | ⚠️ US default | ✅ Self-host | ⚠️ Self-host | ⚠️ US default | ✅ EU |

LangSmith genuinely wins on: tracing tree depth (RunTree visualization), offline evaluation + dataset management, and the LangChain-native developer experience. If you are LangChain-native and your job is prompt iteration / eval, do not migrate away.

LangSmith loses on: non-LangChain coverage, cache-aware billing accuracy, retry-storm detection, and CA/EU residency. If you are a Profile B/C/D team, those four gaps cost more per month than the entire LangSmith bill.

Compliance: Quebec Loi 25 + GDPR — what changes when you move off LangSmith

LangSmith's default data residency is US-East. Their EU plan exists but routes through Frankfurt with measurable added latency (we saw +120ms p50 in our tests). For Profile D teams under Loi 25 (Quebec) or GDPR Article 28/32:

• ClawPulse data residency: Aiven MySQL in Toronto (Canada Central). Loi 25 art.17 (data localization) compliant by default.
• Subprocessor list: Vercel (US, edge only — no PII storage), Aiven (CA, primary), Resend (US, transactional email only). Loi 25 art.28.1 disclosure documented in our DPA.
• Right-to-erasure: SHA-256 prompt hashing + per-tenant DELETE — we can prove erasure within 72h of request. GDPR art.17 + Loi 25 art.28.2 compliant.
• Audit log retention: 13 months default, configurable. SOC 2 Type II in progress (Q4 2026 target).

If your DPO has flagged LangSmith's US-default residency as a risk, ClawPulse is one of two production-grade options that ship with CA hosting out of the box (the other is self-hosted Langfuse on your own infra).

Ten-point pre-migration checklist

Before you flip the switch off LangSmith, run through this:

1. Inventory your LLM call sites. Grep for `@traceable`, `RunTree`, `traceable(`, `tracing_v2_enabled`. Anything not covered = silent regression risk post-migration.

2. Identify non-LangChain LLM calls. Direct SDK usage (`openai.chat.completions.create`, `anthropic.messages.create`) — these need wrapping with `instrumentLLMCall` or equivalent.

3. Map your eval pipelines. If you depend on LangSmith datasets + evaluators, plan to keep LangSmith for offline evals or migrate datasets to Phoenix/Braintrust.

4. Document your trace-tree dependencies. Any dashboard or alert built on LangChain RunTree IDs — translate to your new span_id/trace_id schema.

5. Validate cache-read billing. Run a 7-day side-by-side: LangSmith dashboard cost vs. provider invoice. If the gap is >10%, prioritize a cache-aware tool.

6. Set up retry-storm alerts. Per-route z-score > 3.0 on prompt_tokens, 5-minute window, fires to Slack/PagerDuty.

7. Verify data residency. Confirm with your DPO that the new tool's primary region matches your compliance requirements.

8. Plan a 14-day overlap. Run both LangSmith and the new tool in parallel. Do not turn off LangSmith until you have caught at least one production incident on the new system.

9. Update runbooks. Anywhere your on-call docs reference "LangSmith trace URL" — update to the new tool's URL pattern.

10. Archive your LangSmith data. Export the last 90 days of traces + datasets before you cancel — LangSmith deletes on cancellation.

Extended FAQ

Q: Can I keep LangSmith for evals and use ClawPulse for production monitoring?

Yes — this is the most common pattern we see in Profile C teams. LangSmith's dataset + evaluator UX is best-in-class; ClawPulse's production observability is framework-agnostic and cache-aware. They do not overlap meaningfully. Wire the evaluation pipeline to LangSmith, wire the production hot path to ClawPulse.

Q: How do I migrate LangSmith `@traceable` decorators without rewriting every call site?

Use a codemod: `@traceable` → `instrumentLLMCall`. We published a `jscodeshift` transform on GitHub (search `clawpulse/codemods`). It handles the common cases (sync/async, named/anonymous, nested decorators) and flags the edge cases for manual review. Most teams complete the migration in <1 day for <500 call sites.

Q: What happens to my historical LangSmith data on cancellation?

LangSmith's standard retention deletes traces 30 days after cancellation. Export everything via their API before you cancel. We have a script template at `clawpulse.org/blog/export-langsmith-traces-before-cancellation` (or contact support — we will run the export for you on Growth+ plans).

Q: Does ClawPulse support OpenTelemetry?

Yes — the bash agent emits OTel spans by default and the API ingests OTLP/HTTP. If your stack already exports to a collector (Jaeger, Tempo, Honeycomb), you can dual-write without changing instrumentation.

Q: How does pricing compare at 100k requests/day?

At 100k req/day (~3M req/month), LangSmith Plus runs $390–$650/mo depending on trace retention. ClawPulse Growth covers it at $49/mo flat. The crossover point where LangSmith becomes cheaper for production monitoring does not exist — it is a different pricing model (trace-tax vs flat).

Q: Can I use ClawPulse with LangChain?

Yes. Wrap your LangChain `LLMChain.invoke()` calls with `instrumentLLMCall`, or add the bash agent to your container — the agent captures provider HTTP traffic regardless of framework. We have customers running LangChain + LlamaIndex + raw SDK in the same service, all observed through ClawPulse.

Q: Does ClawPulse support custom evaluators?

Not yet (Q3 2026 roadmap). For now, pair ClawPulse for production monitoring with Phoenix (Arize) or LangSmith for evals. Phoenix is open-source and has good LangChain integration.

Q: What is the SOC 2 status?

SOC 2 Type II audit in progress, Q4 2026 target. Type I report available on request under NDA. Bridge letter from our infra partners (Vercel, Aiven) covers the gap for most procurement teams.

> Ready to migrate? Start a 14-day free trial at clawpulse.org/signup, or book a demo — we will walk you through the LangSmith → ClawPulse migration on your stack live.

Internal reads: LLM API rate limiting best practices · How much does the Claude API cost in 2026 · OpenAI API cost per token explained · OpenClaw observability platform — complete guide · Best Helicone alternatives 2026 · Best Portkey alternatives 2026 · Why teams are switching from Langfuse

External authority: LangSmith docs · OpenTelemetry semantic conventions for GenAI · Anthropic prompt caching · OpenAI cached input pricing

LangSmith alternatives by deployment shape: OSS, self-hosted on AWS/Azure, or fully managed

The most-asked autocomplete query around "langsmith alternative" is no longer feature parity — it's where can I run it. Three deployment shapes dominate the 2026 buying conversation:

1. Open-source / self-hosted (data never leaves your VPC)

If you're a regulated tenant (HIPAA, FedRAMP-moderate, EU-only data residency) or you simply prefer to own the storage layer, the realistic OSS-friendly options are:

• Langfuse OSS — Postgres + (since v3.0) ClickHouse for traces. Helm chart, ~6 services to operate.
• Phoenix (Arize OSS) — single Docker image, SQLite or Postgres. Easiest local install, no horizontal scaling story.
• OpenTelemetry Collector + ClickHouse + Grafana — no LLM-specific UI, but the cheapest at scale (~$0.20/M spans).

ClawPulse offers a single-tenant cloud deployment (your dedicated DB + dedicated worker pool, US-east, EU-west, or APAC) which covers ~90% of "self-hosted" requests without the operational tax. See the /pricing page for the Agency tier.

2. Self-hosted on AWS

Practical recipe for running a Langfuse-class stack on AWS:

```bash

# RDS Postgres 16 (db.t4g.medium, ~$25/mo)

aws rds create-db-instance

--db-instance-identifier llm-obs

--engine postgres --engine-version 16.3

--db-instance-class db.t4g.medium

--allocated-storage 50 --storage-type gp3

# ClickHouse on ECS Fargate (1 vCPU, 2GB) for traces

# OR: ClickHouse Cloud ~$50/mo for <10M spans

# Langfuse web + worker on App Runner (autoscale 1→4)

# Total ~$120/mo at 5M spans/month

```

The hidden cost is operational toil — you're now on the hook for Postgres upgrades, ClickHouse merges, and TLS rotation. Most teams we talk to spend 4–6 hours/month babysitting this stack. At a $200k loaded eng cost, that's ~$500/mo of hidden labor, making the build-vs-buy math much tighter than the AWS bill suggests.

3. Self-hosted on Azure

Azure-native deployment leverages:

• Azure Database for PostgreSQL Flexible Server (Burstable B2s tier, ~$35/mo)
• Azure Container Apps for Langfuse web + worker (scale-to-zero saves ~40% on dev environments)
• Azure OpenAI Service as the LLM provider — ClawPulse, Langfuse, and Phoenix all auto-detect Azure OpenAI endpoints from the `AZURE_OPENAI_ENDPOINT` env var

A common pitfall: Private Endpoints are not free ($7.30/endpoint/month + $0.01/GB processed). A typical 3-endpoint observability stack adds ~$25/month before any traffic. Budget for this upfront.

The Langfuse → ClickHouse migration: should you wait, switch, or stay flat?

In April 2026 Langfuse migrated their hosted traces from Postgres to ClickHouse. The autocomplete data shows real anxiety around this — `langfuse clickhouse migration`, `langfuse clickhouse alternative`, and `langfuse clickhouse acquisition` are all rising queries.

What it means in practice:

| Concern | Reality |

| --- | --- |

| Self-hosted upgrade | OSS v3.0+ requires you to stand up ClickHouse alongside Postgres. The migration script is one-way. |

| Query latency | Faster for aggregate analytics (p50 1.2s → 380ms on 100M spans), slower for single-trace lookups (~120ms penalty). |

| Cost at scale | ClickHouse compresses spans ~10×. A 500GB Postgres dataset compacts to ~50GB. Wins above 50M spans/month. |

| Operational complexity | +1 stateful service. ClickHouse merges, ZooKeeper (or ClickHouse Keeper), backup strategy. |

If you're below 5M spans/month, the migration cost outweighs the benefit — stay on Postgres-only OSS, or move to a managed alternative like ClawPulse which bundles columnar storage transparently. If you're above 50M spans/month and self-hosting, the migration is unavoidable but worth doing — we maintain a Langfuse → ClawPulse parallel-write playbook for teams who want a managed exit.

LangGraph + LangSmith alternative: drop-in tracing for graph runs

LangGraph (the agentic-orchestration cousin of LangChain) auto-emits traces to LangSmith when `LANGCHAIN_TRACING_V2=true`. To swap in an alternative without rewriting your graph:

```python

import os

from langgraph.graph import StateGraph

from opentelemetry import trace

from opentelemetry.sdk.trace import TracerProvider

from opentelemetry.sdk.trace.export import BatchSpanProcessor

from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

# Point OTel at ClawPulse (or Langfuse OSS, Phoenix, etc.)

provider = TracerProvider()

provider.add_span_processor(BatchSpanProcessor(OTLPSpanExporter(

endpoint="https://otel.clawpulse.org/v1/traces",

headers={"authorization": f"Bearer {os.environ["CLAWPULSE_TOKEN"]}"},

)))

trace.set_tracer_provider(provider)

tracer = trace.get_tracer(__name__)

# Wrap each node so graph transitions become OTel spans

def traced_node(name, fn):

def wrapped(state):

with tracer.start_as_current_span(f"graph.node.{name}") as span:

span.set_attribute("gen_ai.system", "openai")

span.set_attribute("gen_ai.request.model", state.get("model", ""))

result = fn(state)

span.set_attribute("gen_ai.usage.input_tokens", result.get("input_tokens", 0))

span.set_attribute("gen_ai.usage.output_tokens", result.get("output_tokens", 0))

return result

return wrapped

graph = StateGraph(dict)

graph.add_node("retrieve", traced_node("retrieve", retrieve_docs))

graph.add_node("generate", traced_node("generate", llm_call))

```

The `gen_ai.*` attributes follow the OpenTelemetry GenAI semantic conventions — same wire format consumed by Phoenix, Langfuse v3, ClawPulse, and Datadog LLM Observability. Tracing once, exporting anywhere is the only future-proof bet in 2026.

FAQ

Q: What is the best open-source LangSmith alternative in 2026?

A: Langfuse (most features, requires Postgres + ClickHouse since v3), Phoenix (simplest single-binary install), and raw OpenTelemetry Collector + ClickHouse + Grafana (cheapest at high scale). All three implement the OTel GenAI semantic conventions, so you can switch later without instrumentation changes.

Q: Can I run a LangSmith alternative inside my AWS or Azure VPC?

A: Yes. Langfuse OSS, Phoenix, and ClawPulse Agency-tier all support fully isolated deployments. AWS recipe: RDS Postgres + ECS Fargate ClickHouse + App Runner (~$120/mo at 5M spans). Azure: Postgres Flexible Server + Container Apps (~$95/mo + Private Endpoint fees).

Q: Should I migrate to Langfuse v3 with ClickHouse, or pick an alternative?

A: Below 5M spans/month, the migration overhead is not worth it — stay on Postgres or switch to a managed alternative. Above 50M spans/month, columnar storage is essential — either migrate, or move to a vendor that handles it for you.

Q: Does ClawPulse work with LangGraph and LangChain?

A: Yes. Set `OTEL_EXPORTER_OTLP_ENDPOINT=https://otel.clawpulse.org/v1/traces` and `LANGCHAIN_TRACING_V2=true`. ClawPulse consumes both the native LangChain callback format and OpenTelemetry GenAI spans. Book a demo or start a 14-day trial.