Audience: Platform engineers choosing observability, tracing, and evaluation tooling for enterprise LLM deployments. Covers architecture, pricing, differentiators, and a decision framework.
- Landscape Overview and Category Map
- Helicone
- Portkey
- Langfuse
- Arize Phoenix
- LangSmith
- Braintrust and Promptfoo
- OpenTelemetry for LLM Observability
- W&B Weave and Fiddler (Brief)
- Decision Framework
- Recommended Stack Combinations
- Verification Ledger
1. Landscape Overview and Category Map
The LLM observability space has fractured into four overlapping categories. The fracture matters because buying in the wrong category means paying twice or missing a capability entirely.
Category A — LLM Gateways with Observability
Tools: Helicone, Portkey, LiteLLM
What the category solves: Unified entry point for multi-provider LLM routing with observability as a side effect of sitting on the request path. The gateway sees every request and response, so it can log tokens, cost, latency, and metadata without any SDK integration in application code.
Core value: Zero-code cost attribution, caching, fallbacks, and basic tracing from a one-line base URL change.
Where it falls short: Tracing is span-level, not application-level. A gateway sees the LLM call but not the surrounding agent logic, retrieval steps, or chain of tool calls. Evaluation pipelines are absent or shallow.
2026 M&A note: Both Helicone (acquired by Mintlify, now in maintenance mode) and Portkey (acquired by Palo Alto Networks in April 2026 after open-sourcing its gateway under Apache 2.0 in March) have changed ownership. LiteLLM remains independent and actively developed.
Category B — Standalone Tracing and Observability
Tools: Langfuse, Arize Phoenix, W&B Weave, Fiddler
What the category solves: Full distributed tracing of LLM application logic — not just LLM calls but retrieval, agent loops, tool calls, and chain steps. Designed for teams that need to understand why an agent behaved a certain way, not just how much it cost.
Core value: Trace trees that span the full application. Session-level context. Human annotation queues. Production debugging.
Where it falls short: These tools add SDK weight. You instrument your code with decorators or context managers. The gateway-free path means they don’t sit on the request path and can’t enforce caching or fallbacks natively.
Category C — Evaluation Platforms
Tools: LangSmith, Braintrust, Promptfoo, Ragas
What the category solves: Systematic measurement of LLM quality — not just “did it respond” but “did it respond correctly.” Dataset management, LLM-as-judge scoring, regression detection between prompt versions, CI/CD gates.
Core value: A scored history of model/prompt changes. The ability to run a new model against a golden dataset before deploying. Human annotation workflows.
Where it falls short: Eval platforms are weak on production routing, cost attribution, and real-time alerting. They operate largely in experiment space, not the hot path.
Category D — OpenTelemetry-Native
Tools: OpenInference (Arize), OpenLLMetry / traceAI (Traceloop), OTel GenAI semantic conventions
What the category solves: Vendor-neutral trace emission using OpenTelemetry primitives. Ship LLM spans to any OTel-compatible backend — Grafana Tempo, Jaeger, Honeycomb, Datadog, New Relic — without vendor lock-in.
Core value: If you already run an OTel stack for non-LLM services, you can extend it to LLM calls without adopting a new vendor.
Where it falls short: No native evaluation layer. The OTel ecosystem does not define how to run LLM-as-judge evals or manage prompt datasets. You build that layer yourself or bolt on a Category C tool.
Category Overlap Map
GATEWAY LAYER
Helicone ── Portkey ── LiteLLM
↓ ↓ ↓
(routing, cache, fallback, virtual keys)
↓ ↓ ↓
TRACE TRANSPORT
OTel OTLP ── OpenInference ── Native SDK
↓ ↓ ↓
OBSERVABILITY BACKEND
Langfuse ── Phoenix ── W&B Weave ── LangSmith
↓ ↓ ↓
EVALUATION LAYER
LangSmith ── Braintrust ── Promptfoo ── Ragas
Key overlap zones:
- Langfuse covers B + partial C (tracing + evals in one tool, open-source)
- LangSmith covers B + C (tracing + evals, managed, LangChain-native)
- Phoenix covers B + C (local, open-source, OTel-emitting)
- Portkey covers A + partial B (gateway + observability, no eval)
- W&B Weave covers B + C (for teams already on W&B for ML training)
2. Helicone
Status (2026)
Helicone was acquired by Mintlify in March 2026 and is now in maintenance mode. No new features are being added. Existing integrations continue to work. Teams choosing Helicone for new projects should treat it as a stable but terminal choice.
Architecture
Helicone operates in two modes:
Proxy mode (default): Change one URL — e.g., https://api.openai.com/v1 → https://oai.helicone.ai/v1 — and every request passes through Helicone’s infrastructure. Helicone adds an Authorization header for its own auth and a Helicone-Auth header for routing. The proxy logs the full request and response, extracts token counts, computes cost, and applies configured behaviors before forwarding to the provider. Latency overhead is ~10–20ms.
Async logging mode: For teams that cannot proxy traffic (compliance, latency budget), Helicone provides a logging endpoint. The application calls the LLM directly and sends a side-channel log to Helicone. This loses some capabilities (no caching enforcement at the proxy layer) but retains full observability.
Features
- Cost tracking: Per-request cost computed from token counts and provider pricing tables. Supports custom cost overrides. Attributable by user ID, session, and custom properties passed as headers.
- Prompt management: Prompt versioning with template variables. Not as full-featured as LangSmith’s Prompt Hub.
- Caching: Semantic and exact-match caching. Configurable TTL. Reduces cost on repeated or near-identical prompts.
- Bedrock support: AWS Bedrock supported at $3/1M tokens gateway fee. Integration path: configure Bedrock endpoint URL as the target, pass AWS credentials as headers or via environment.
- Open-source: Helicone’s core is open-source (MIT). Self-hosting is documented but not heavily supported post-acquisition.
Pricing (as of acquisition)
| Tier | Price | Limits |
|---|---|---|
| Free | $0 | 10,000 requests/month |
| Pro | ~$20/month | 500,000 requests/month |
| Enterprise | Custom | Unlimited, SLA, SAML SSO |
Post-acquisition pricing may not be updated. Verify on helicone.ai before committing.
Differentiators vs LiteLLM
| Dimension | Helicone | LiteLLM |
|---|---|---|
| Primary value | Observability-first proxy | Multi-provider routing |
| Self-hosting | Documented, not priority | First-class supported |
| Observability depth | Strong (built-in dashboard) | Weak out of box (integrates with external tools) |
| Provider coverage | ~15 providers | 100+ providers |
| Caching | Built-in | Add-on (via proxy config) |
| Status (2026) | Maintenance mode | Actively developed |
| Guardrails | Basic | Basic |
| Virtual keys | Yes | Yes |
When to choose Helicone over LiteLLM: You want a managed proxy with a clean observability dashboard and minimal engineering overhead, you’re on a small team, and you’re not betting on it for new feature development.
3. Portkey
Status (2026)
Portkey open-sourced its entire production gateway under Apache 2.0 in March 2026 (processing >1 trillion tokens/day at that point). Acquired by Palo Alto Networks in April 2026. As with Helicone, the acquisition raises long-term roadmap uncertainty, but Portkey is more feature-complete than Helicone was at acquisition.
Architecture
Portkey is a full AI gateway — not just a logging proxy. It acts as a stateful intermediary that routes, transforms, enriches, and enforces policy on every LLM request. The core abstractions are:
- Virtual Keys: Abstract real provider API keys behind workspace-scoped tokens. Engineers never handle raw OpenAI/Anthropic/Bedrock keys. Virtual keys can carry per-key budget limits, rate limits, and provider fallback chains.
- Configs: Declarative routing rules attached to a virtual key. Define fallback order, retry logic, load balancing, and model aliases.
- Guardrails: Request and response filters applied in the gateway layer before and after the LLM call. Includes PII redaction, jailbreak detection, output schema enforcement, and custom regex/LLM-as-judge checks.
- Semantic Cache: Caches responses by semantic similarity of the input prompt. Configurable similarity threshold and TTL. Can reduce cost significantly on RAG pipelines where user questions rephrase the same underlying query.
Features
| Feature | Details |
|---|---|
| Provider coverage | 1,600+ LLMs via unified API |
| Load balancing | Round-robin, weighted, latency-optimized across provider/model combos |
| Fallbacks | Ordered fallback chains with retry budgets |
| Semantic cache | Similarity-threshold configurable, provider-agnostic |
| Guardrails | PII, jailbreak, output schema, custom LLM judge |
| Observability | Per-request logs, cost, latency, error breakdowns. Exportable to external backends. |
| Prompt management | Prompt templates versioned and deployed via gateway config |
| Virtual keys | Workspace-scoped, budget-limited, auditable |
| Bedrock | Full support — Bedrock endpoints treated as first-class providers |
| Compliance | HIPAA, SOC2 on Enterprise; audit trails; VPC hosting |
Pricing
| Tier | Price | Limits |
|---|---|---|
| Developer | Free | 10,000 logs/month, 3-day retention |
| Production | $49/month | 100,000 logs/month, 30-day retention; $9 per additional 100K requests |
| Enterprise | Custom | SSO, VPC, custom retention, HIPAA/SOC2, RBAC |
Portkey vs LiteLLM vs Helicone
| Dimension | Portkey | LiteLLM | Helicone |
|---|---|---|---|
| Primary value | AI gateway + LLMOps | Multi-provider routing | Observability proxy |
| Open-source | Apache 2.0 (March 2026) | MIT | MIT |
| Guardrails | Production-grade | None native | None |
| Semantic cache | Yes | No | Yes (exact + semantic) |
| Observability | Good (not primary) | Basic | Primary feature |
| Virtual keys | Yes | Yes | Yes |
| Bedrock | Yes | Yes | Yes |
| Status (2026) | Palo Alto Networks acquisition | Actively developed | Maintenance mode |
| Best for | Enterprise gateway + compliance | Self-hosted multi-provider | Simple proxy + observability |
Key insight: If your primary requirement is policy enforcement at the gateway layer (PII redaction, guardrails, audit trails), Portkey is meaningfully ahead of LiteLLM and Helicone. If your primary requirement is pure routing flexibility with no vendor, LiteLLM remains the better open-source choice. Portkey’s Apache 2.0 release means you can self-host the full feature set, making the managed vs. self-hosted comparison a DevOps tradeoff rather than a features tradeoff.
4. Langfuse
Overview
Langfuse is the open-source LLM observability platform that has become the default for teams that want self-hosted, framework-agnostic, full tracing + evals in one tool. In January 2026, ClickHouse acquired Langfuse alongside a $400M Series D — the acquisition formalized a technical dependency that already existed in Langfuse v3, which had migrated its core data layer from PostgreSQL to ClickHouse to handle production-scale high-throughput ingestion with fast analytical reads.
License: MIT (including all product features as of June 2025 — tracing, prompts, evals, playground, annotation queues).
Architecture
Langfuse is an SDK + backend model, not a proxy. Your application code calls the Langfuse SDK to emit traces. The SDK is available in Python, TypeScript/JavaScript, and via REST. There is no traffic proxy; Langfuse sits beside the request path rather than on it.
Tracing model:
- A Trace is a full request lifecycle (one user query → final response)
- A Span is a unit of work within a trace (LLM call, retrieval, tool call, custom step)
- Spans have type annotations:
LLM,RETRIEVAL,TOOL,DEFAULT - Nested spans form a tree; the root span is the trace
from langfuse.decorators import observe, langfuse_context
@observe() # creates a span for each call
def retrieve_context(query: str) -> list[str]:
...
@observe() # creates the root trace
def answer(user_query: str) -> str:
context = retrieve_context(user_query)
response = openai_client.chat.completions.create(...)
return response.choices[0].message.content
The @observe() decorator automatically captures inputs, outputs, and nests spans via Python’s contextvars. No manual span management for most cases.
Evaluation Features
Langfuse covers evaluation in three modes:
- Human annotation: Annotation queues surface traces to human reviewers. Configurable scoring rubrics. Results stored as Scores on spans.
- LLM-as-judge: Define a judge prompt template, attach it to a dataset or live trace sample. Langfuse runs the judge and stores the score. Built-in templates for hallucination, faithfulness, relevance, and toxicity.
- Dataset management: Upload or curate datasets from production traces (select traces → add to dataset). Run experiments: pick a dataset, a prompt version, a model, and a scorer — Langfuse runs all combinations and tracks score deltas.
Cost Tracking
Langfuse does not sit on the request path, so cost tracking requires either:
- Passing
usagemetadata when logging (token counts from the LLM response) - Using the OpenAI SDK integration which auto-captures usage
- Custom
costattributes on spans
For Bedrock specifically: Bedrock responses return token counts in the response body; the Langfuse SDK captures these automatically via the Bedrock integration or OpenAI-compatible endpoint mapping.
Bedrock Integration
Two paths:
- OpenAI-compatible endpoint: Route Bedrock calls through LiteLLM’s OpenAI-compatible proxy, then use the standard Langfuse OpenAI SDK integration.
- Direct SDK: Langfuse’s
CallbackHandlerfor LangChain works natively with Bedrock-backed LangChain models. For raw Boto3 calls, manual span creation with usage metadata is required.
Prompt Management
Langfuse’s Prompt Management feature stores prompt templates with version history, variable injection, and deployment labels (production/staging). Prompts are fetched at runtime via the SDK, enabling prompt rollbacks without code deploys:
from langfuse import Langfuse
lf = Langfuse()
prompt = lf.get_prompt("my-rag-prompt", version=None, label="production")
compiled = prompt.compile(question=user_question, context=context_docs)
Pricing
| Tier | Price | What you get |
|---|---|---|
| Free (Cloud) | $0 | 50K events/month |
| Core (Cloud) | $29/month | Higher limits, basic evals |
| Pro (Cloud) | $199/month | Full evals, annotation queues, longer retention |
| Self-hosted (MIT) | $0 license | Full feature set, no seat caps, no retention limits |
| Self-hosted (Enterprise) | Custom | Support SLA, SSO, audit logs |
Self-hosting reality check: MIT self-hosting requires running Langfuse + ClickHouse. ClickHouse at production scale is real ops work — estimated 20–30% of a senior engineer’s time, translating to $3,000–$6,000/month in staffing cost at Series A+ salaries. Factor this into TCO comparisons with the $199/month Pro cloud tier.
Key Differentiators
- Best open-source option that combines full tracing + evals + prompt management + annotation queues in one tool
- Framework-agnostic: integrates with LangChain, LlamaIndex, OpenAI SDK, Anthropic SDK, raw HTTP, or any framework via REST
- MIT license means full product is self-hostable with no feature gating
- ClickHouse acquisition does not change pricing or licensing (confirmed as of June 2026)
5. Arize Phoenix
Overview
Arize Phoenix is an open-source, locally-runnable AI observability and evaluation platform. It is the reference implementation for OpenInference — the OTel-aligned semantic convention for LLM spans. Phoenix is designed to run on a developer’s laptop or a team’s private infrastructure with zero external data transmission.
import phoenix as px
px.launch_app() # starts local UI at http://localhost:6006
No API keys, no cloud account, no vendor lock-in. Data lives in local SQLite (dev) or PostgreSQL (production deployment).
Tracing Architecture
Phoenix uses OpenInference as its trace format — a set of OTel semantic conventions that extends the base OTel GenAI spec with:
openinference.span.kind:LLM,CHAIN,RETRIEVER,RERANKER,EMBEDDING,AGENT,TOOLllm.model_name,llm.input_messages,llm.output_messages,llm.token_count.*retrieval.documents(array of retrieved docs with content and score)embedding.embeddings(input text + vector)
Auto-instrumentation packages exist for: OpenAI, Anthropic, Bedrock, LangChain, LlamaIndex, DSPy, Guardrails AI, and more. One import enables tracing for the entire framework:
from openinference.instrumentation.langchain import LangChainInstrumentor
from opentelemetry import trace as otel_trace
from opentelemetry.sdk.trace import TracerProvider
provider = TracerProvider()
otel_trace.set_tracer_provider(provider)
LangChainInstrumentor().instrument()
# All LangChain calls now emit OpenInference spans to Phoenix
Evaluation Library
Phoenix ships phoenix.evals — a standalone evaluation library that operates on dataframes of spans. This is a genuine differentiator: evals are not a UI workflow but a code-first library.
from phoenix.evals import (
HallucinationEvaluator,
QAEvaluator,
RelevanceEvaluator,
run_evals,
)
import pandas as pd
# Pull traces into a DataFrame
spans_df = px.active_session().get_spans_dataframe()
# Run evaluators in parallel
eval_results = run_evals(
dataframe=spans_df,
evaluators=[HallucinationEvaluator(model), QAEvaluator(model)],
provide_explanation=True,
)
Built-in evaluators: HallucinationEvaluator, QAEvaluator, RelevanceEvaluator, ToxicityEvaluator, SummarizationEvaluator, SQL_EVAL. All use LLM-as-judge internally with configurable judge models.
Embedding Visualization
Phoenix renders embedding spaces via UMAP, enabling visual clustering of:
- Input query embeddings colored by eval result (to find failure clusters)
- Retrieved document embeddings vs. query embeddings (to diagnose retrieval gaps)
- Session-level drift visualization
This is the one feature with no equivalent in Langfuse or LangSmith.
Bedrock Integration
OpenInference ships openinference-instrumentation-bedrock — auto-instruments boto3 Bedrock calls:
from openinference.instrumentation.bedrock import BedrockInstrumentor
BedrockInstrumentor().instrument()
# boto3 bedrock_runtime.invoke_model() calls now emit OpenInference spans
Phoenix vs Langfuse Decision
| Criterion | Use Phoenix | Use Langfuse |
|---|---|---|
| Data residency required | Yes — runs fully local | Cloud or self-hosted ClickHouse |
| Primary concern | Evaluation research + embedding analysis | Production tracing + annotation queues |
| Team size | Solo / small team | Team with annotation workflow |
| OTel backend | Want to emit to Grafana/Honeycomb too | Langfuse-native backend |
| Eval approach | Code-first, dataframe-centric | UI-first, annotation queues |
| Prompt management | Not a Phoenix feature | First-class feature |
Phoenix is the right tool for: RAG debugging, evaluation research, local development, and teams that want code-first evaluation without a managed backend. Langfuse wins for production annotation queues, prompt versioning, and team-scale observability.
6. LangSmith
Overview
LangSmith is LangChain’s managed observability and evaluation platform. It is not open-source. Its strongest advantage is zero-configuration tracing for LangChain and LangGraph applications — set LANGCHAIN_TRACING_V2=true and every LangChain component emits traces automatically.
Architecture
LangSmith is a managed SaaS backend. There is no self-hosted option (an enterprise on-premises version exists but is not publicly documented). The SDK wraps LangChain’s callback system; for non-LangChain code, the @traceable decorator provides similar functionality to Langfuse’s @observe().
import os
os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = "..."
# Zero additional code — all LangChain/LangGraph calls are traced automatically
from langchain_openai import ChatOpenAI
llm = ChatOpenAI()
response = llm.invoke("What is the capital of France?")
# → trace appears in LangSmith UI
For non-LangChain code:
from langsmith import traceable
@traceable
def my_retriever(query: str) -> list[str]:
...
Evaluation Features
LangSmith’s eval story centers on:
- Datasets: Upload gold examples or curate from production traces
- Evaluators: LLM-as-judge, exact match, string contains, custom Python functions
- Experiments: Run a prompt + model combination against a dataset, get per-example scores and aggregate stats
- Prompt Hub: Version prompt templates, compare variants, deploy by label
LangSmith’s evaluate() function:
from langsmith.evaluation import evaluate
results = evaluate(
my_pipeline, # callable that takes example input
data="my-dataset",
evaluators=[correctness_evaluator, groundedness_evaluator],
experiment_prefix="v2-prompt-tuning",
)
LangGraph Integration
LangSmith has deep, automatic tracing for LangGraph agent graphs — every node execution, state transition, and conditional edge is captured as a structured span. This is the most complete automatic tracing of agent graphs available in any platform as of mid-2026.
Pricing
| Tier | Price | Limits |
|---|---|---|
| Developer (Free) | $0 | 5,000 traces/month, 1 seat, 14-day retention |
| Plus | $39/user/month | 100,000 traces/month, 10 users, 400-day retention |
| Enterprise | Custom | Unlimited, SSO, dedicated support |
Overage: $0.50 per 1,000 traces on Plus. A team running 500K traces/month pays $39 + $200 in overage per seat.
LangSmith vs Langfuse Decision
| Criterion | Use LangSmith | Use Langfuse |
|---|---|---|
| Framework | LangChain/LangGraph | Any / multi-framework |
| Self-hosting required | No (no option) | Yes — strong self-hosted option |
| Pricing model | Per-seat + trace overage | Usage-based, free self-hosted |
| Eval UX | Polished, UI-first | Slightly less polished, more flexible |
| Provider agnosticism | LangChain-centric | Fully provider-agnostic |
| Prompt management | Prompt Hub, well integrated | Full prompt management |
| Data ownership | LangChain Cloud | Self-hostable with full data control |
The practical rule: If your stack is LangChain-native, LangSmith is the path of least resistance. If you need self-hosting, multi-framework support, or want to avoid LangChain ecosystem lock-in, Langfuse is the better default.
7. Braintrust and Promptfoo
Braintrust
Category: Evaluation platform (managed, eval-first)
Braintrust is a managed LLM evaluation platform built around the idea that evaluation should be a software engineering workflow, not a data science one-off. Its core primitives are:
- Experiments: Named, versioned eval runs. Compare experiment A vs experiment B on the same dataset. Scores and diffs are first-class.
- Datasets: Versioned collections of (input, expected output) pairs. Non-technical team members can contribute examples via UI.
- Scorers: LLM-as-judge, exact match, regex, embedding similarity, custom Python/JS functions. Braintrust’s “Loop” feature automatically generates better-performing prompt variants by analyzing eval results.
- CI/CD gates: Every PR can trigger an eval run. Results post as PR comments showing which test cases improved, which regressed, and by how much. Quality gates block merges if score drops below threshold.
- Tracing: Braintrust added production tracing, but it’s secondary to the eval story.
Pricing: Not publicly listed; contact-sales model. Free tier available for individuals.
When Braintrust wins over LangSmith:
- You want eval as the primary product, not observability
- You want CI/CD eval gates with automated regression detection
- Your team includes non-engineers who need to contribute test cases via UI
- You want prompt optimization automation (Loop feature)
Promptfoo
Category: Open-source evaluation CLI (developer-driven, CI-native)
2026 status: OpenAI acquired Promptfoo in March 2026. Future of the open-source project under OpenAI ownership is not yet clarified.
Promptfoo is a CLI tool and library for evaluating, comparing, and red-teaming LLM applications. Configuration is YAML-first:
# promptfooconfig.yaml
providers:
- id: openai:gpt-4o
- id: anthropic:claude-opus-4
prompts:
- "Summarize the following text: {{text}}"
- file://prompts/summary_v2.txt
tests:
- vars:
text: "The Fed raised rates by 25bps..."
assert:
- type: contains
value: "Federal Reserve"
- type: llm-rubric
value: "The summary should be factually accurate and under 50 words"
- vars:
text: "file://test_cases/earnings_call.txt"
assert:
- type: not-contains
value: "I don't know"
Run with: promptfoo eval → generates a comparison table with pass/fail rates across providers and prompts.
Red teaming: promptfoo redteam generate creates adversarial inputs targeting 50+ vulnerability types (prompt injection, PII extraction, jailbreaks, hallucination triggers). The red team command reads your prompts and generates stress-test cases automatically.
When Promptfoo wins:
- You want eval integrated into CI without adopting a managed platform
- Your team is developer-driven (comfortable with YAML + CLI)
- You need automated red teaming as part of CI
- You want MIT-licensed, self-contained eval with no backend dependency
- You’re OK with pre-acquisition Promptfoo (post-OpenAI acquisition roadmap TBD)
Braintrust vs Promptfoo vs LangSmith for Evals
| Criterion | Braintrust | Promptfoo | LangSmith |
|---|---|---|---|
| Primary purpose | Eval platform | Eval CLI | Tracing + eval |
| Open-source | No | Yes (MIT, pre-acquisition) | No |
| CI/CD integration | First-class | First-class | Good |
| Red teaming | No | Yes (50+ vuln types) | No |
| Non-engineer UI | Yes | CLI-only | Yes |
| Tracing in production | Secondary | None | Primary |
| Prompt optimization | Automated (Loop) | Manual | Prompt Hub |
| LangChain integration | Provider-agnostic | Provider-agnostic | Tight |
| Self-hosted | No | Yes | No |
8. OpenTelemetry for LLM Observability
The Standards Landscape
As of mid-2026, three overlapping semantic convention standards exist for LLM spans in OTel:
| Standard | Maintainer | Namespace | Status |
|---|---|---|---|
| OTel GenAI Conventions | OpenTelemetry project | gen_ai.* |
Stable in OTel 1.29+ |
| OpenInference | Arize | openinference.*, llm.* |
Widely adopted, OTel-aligned |
| OpenLLMetry / traceAI | Traceloop | gen_ai.* (OTel GenAI aligned) |
Active |
The convergence direction: OTel GenAI is the upstream standard; OpenInference is a superset that adds span kinds and attributes for retrieval, embedding, and agent metadata that OTel GenAI does not cover. The two are not in conflict — OpenInference spans are valid OTel spans; they just carry additional attributes that OTel GenAI doesn’t define. The long-term expectation is that OTel GenAI absorbs retrieval and agent attributes as the spec matures, making OpenInference less necessary.
OTel GenAI Semantic Conventions (1.29+)
Key attributes for LLM spans:
gen_ai.system # "openai" | "anthropic" | "aws.bedrock" | etc.
gen_ai.operation.name # "chat" | "text_completion" | "embeddings"
gen_ai.request.model # "gpt-4o" | "claude-opus-4" | etc.
gen_ai.response.model # model actually used (may differ from request)
gen_ai.usage.input_tokens
gen_ai.usage.output_tokens
gen_ai.usage.total_tokens
gen_ai.request.temperature
gen_ai.request.max_tokens
Message content is captured as span events (not attributes) to avoid attribute size limits:
Event: gen_ai.user.message { content: "..." }
Event: gen_ai.assistant.message { content: "..." }
Emitting LLM Spans to Any Backend
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
# Point to any OTel-compatible backend
exporter = OTLPSpanExporter(endpoint="http://grafana-tempo:4317")
provider = TracerProvider()
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)
# Instrument frameworks
from openinference.instrumentation.openai import OpenAIInstrumentor
OpenAIInstrumentor().instrument()
# All OpenAI calls now emit OTel spans to Grafana Tempo
Compatible backends: Grafana Tempo, Jaeger, Honeycomb, Datadog, New Relic, Dynatrace, OpenObserve, Signoz, Langfuse (OTLP ingestion), Phoenix.
Cost: Full OTel Stack vs Managed Tools
| Approach | Monthly Cost (10M traces) | Engineering Overhead |
|---|---|---|
| Managed tool (LangSmith Plus) | $390+/mo (10 seats) + overages | Low |
| Managed tool (Langfuse Pro) | $199/mo | Low |
| Self-hosted Phoenix + OTel | $0 license, ~$50-200 infra | Medium |
| Self-hosted Grafana + Tempo + OTel | $0 license, ~$100-500 infra | High |
| Full OTel stack (Grafana Cloud) | ~$100-300/mo usage-based | Low-medium |
The case for OTel-native: If you already operate an OTel stack for non-LLM services, extending it to LLM calls via OpenInference auto-instrumentation is the lowest additional cost path. The tradeoff is that you lose purpose-built LLM UX (trace trees with message rendering, cost attribution dashboards, eval integration) and must build or bolt those on.
The case against full OTel-native: LLM-specific UX (rendered message history, cost attribution, human annotation queues, eval runs) is expensive to build on top of a generic trace backend. Unless your team already has OTel expertise and a running backend, the managed tools pay for themselves in engineering time.
9. W&B Weave and Fiddler (Brief)
W&B Weave
Category: B (tracing) + C (evaluation), tightly coupled to Weights & Biases ecosystem
Weave extends W&B — the industry standard for ML experiment tracking — to LLM applications. Teams already using W&B for training run tracking, artifact versioning, and model registry find Weave a natural extension.
Core features:
@weave.op()decorator for automatic trace capture- Cost, latency, and token tracking per call
- Evaluation framework with Weave Scorers (toxicity, PII, hallucination, coherence)
- Integration with W&B artifacts for dataset versioning
- Works alongside W&B training run tracking
When to choose Weave: Your team uses W&B for ML training and you want unified tooling across the train/eval/deploy lifecycle. Not the best standalone LLM observability tool — its strength is integration depth with the W&B platform.
Pricing: Shares W&B pricing. Free tier: 100GB storage. Team tier: $50/seat/month. Enterprise: custom.
Fiddler
Category: B (observability), ML monitoring heritage
Fiddler originated as an ML model monitoring platform for traditional ML (drift detection, bias monitoring, explainability). It has expanded to LLM monitoring — hallucination detection, toxicity scoring, custom metrics — but carries the complexity and pricing of an enterprise ML platform. Best suited for organizations that need unified ML + LLM monitoring and have existing Fiddler contracts. Not a first-choice for greenfield LLM deployments.
10. Decision Framework
Primary Decision Tree
Start: What is your primary need?
├── Gateway / routing / cost control
│ ├── Self-hosted required? → LiteLLM
│ ├── Need guardrails + PII redaction? → Portkey (self-hosted Apache 2.0)
│ └── Managed, simple proxy, small team? → Portkey managed (Helicone in maintenance)
│
├── Tracing / observability
│ ├── LangChain/LangGraph stack? → LangSmith
│ ├── Self-hosted required? → Langfuse
│ ├── Local dev / air-gapped? → Arize Phoenix
│ ├── Already on W&B? → W&B Weave
│ └── Need OTel-native (emit to Grafana/Honeycomb)? → OpenInference + Phoenix or Langfuse OTLP
│
└── Evaluation
├── LangChain stack? → LangSmith
├── CI/CD gates + regression detection, managed? → Braintrust
├── CI/CD gates + open-source + red teaming? → Promptfoo (pre-OpenAI caution)
├── Code-first eval research, local? → Arize Phoenix (phoenix.evals)
└── Full tracing + eval in one open-source tool? → Langfuse
Tool Selection Matrix
| Tool | Self-hosted | Open-source | Gateway | Tracing | Evals | Bedrock | LangChain-native | 2026 status |
|---|---|---|---|---|---|---|---|---|
| LiteLLM | First-class | MIT | Yes | Basic | No | Yes | Good | Active |
| Helicone | Documented | MIT | Yes | Good | No | Yes | Good | Maintenance |
| Portkey | Apache 2.0 | Apache 2.0 | Yes | Good | No | Yes | Good | Palo Alto acq. |
| Langfuse | First-class | MIT | No | Excellent | Good | Via LiteLLM/SDK | Good | ClickHouse acq. |
| Phoenix | First-class | Apache 2.0 | No | Excellent | Excellent | Auto-instrumented | Good | Active (Arize) |
| LangSmith | Enterprise only | No | No | Good | Good | Via LangChain | Best-in-class | Active |
| Braintrust | No | No | No | Secondary | Excellent | Via SDK | Good | Active |
| Promptfoo | Yes | MIT | No | No | Good | Via config | Good | OpenAI acq. |
| W&B Weave | No | No | No | Good | Good | Via SDK | Good | Active |
Cost Comparison at Scale (100K traces/month, 10 engineers)
| Tool | Monthly cost | Notes |
|---|---|---|
| LiteLLM self-hosted | ~$50-200 infra | Engineering overhead to maintain |
| Portkey managed | $49 + overages ≈ $100-150 | 100K logs included |
| Langfuse cloud (Pro) | $199 | All features, no seat cap |
| Langfuse self-hosted | ~$200-500 infra + $500-1000 eng time | ClickHouse ops overhead |
| LangSmith Plus | $390/month (10 seats) + $0 overage at 100K | Overage kicks in above 100K |
| Phoenix self-hosted | ~$50-100 infra | No managed option |
| Braintrust | Contact sales | Likely $500-2000/month at team scale |
11. Recommended Stack Combinations
Stack 1: Open-Source, Self-Hosted, Maximum Control
LiteLLM (gateway + routing)
→ Langfuse (tracing + evals + prompt management)
→ Langfuse ClickHouse backend
Optional: Phoenix for evaluation research + embedding visualization
Best for: Teams with data residency requirements, financial/healthcare, or enterprises that cannot send traces to third parties. Requires ClickHouse + LiteLLM ops capacity.
Stack 2: Managed, LangChain-Native
LangChain / LangGraph (framework)
→ LangSmith (tracing + evals, zero-config)
→ Braintrust (CI/CD eval gates on top)
Best for: LangChain-native teams that want managed infrastructure and are willing to pay per seat. LangSmith handles observability; Braintrust handles eval regression CI gates where LangSmith’s CI integration is weaker.
Stack 3: Enterprise Gateway + Open-Source Observability
Portkey (gateway: guardrails, virtual keys, semantic cache, fallbacks)
→ Langfuse via OTLP (tracing + evals)
Portkey can emit traces to Langfuse via its observability export. This gives you enterprise-grade gateway features with open-source observability backend. Portkey’s Apache 2.0 license means you can self-host both layers.
Best for: Enterprises needing guardrails + PII redaction at the gateway layer AND full tracing with annotation queues.
Stack 4: OTel-Native, Existing Infrastructure
OpenInference auto-instrumentation (openai, anthropic, bedrock, langchain)
→ OTel Collector
→ Grafana Tempo (traces)
→ Grafana + dashboards (metrics)
+ Phoenix (local eval runs, not for production tracing)
+ Promptfoo (CI eval gates)
Best for: Platform teams already running OTel for non-LLM services who want to extend their existing stack rather than adopt a new vendor. Requires investment in LLM-specific dashboards and eval tooling.
Stack 5: Local Dev + Research
Phoenix (local, pip install arize-phoenix)
→ phoenix.evals (hallucination, QA, relevance evaluators)
→ Jupyter notebooks for embedding visualization
Promptfoo (CI eval gates on PRs)
Best for: Individual developers, ML researchers, or teams building RAG pipelines who want zero-cost, zero-vendor-dependency local observability. Graduate to Langfuse or LangSmith when team scale requires annotation workflows.
12. Verification Ledger
| Claim | Source | Confidence |
|---|---|---|
| Helicone acquired by Mintlify, maintenance mode | ChatForest review, helicone.ai changelog | Official docs verified |
| Portkey open-sourced Apache 2.0 March 2026 | PR Newswire via financialcontent.com | Official announcement |
| Portkey acquired by Palo Alto Networks April 2026 | ChatForest review | Official docs verified |
| Langfuse acquired by ClickHouse January 2026 | Multiple pricing teardown sources, consistent | Official docs verified |
| Langfuse MIT license — all features | Langfuse blog (June 2025 announcement) | Official docs verified |
| Langfuse Free: 50K events, Core $29, Pro $199 | CheckThat.ai, CostBench, Coverge | Community pattern (verify on langfuse.com) |
| LangSmith Plus: $39/user/month, 100K traces | Multiple pricing sources, consistent | Official docs verified |
| LangSmith Free: 5,000 traces, 14-day retention | Multiple pricing sources | Official docs verified |
| Portkey Developer: free 10K logs, Production $49/month | TrueFoundry pricing guide, Portkey docs | Official docs verified |
| Promptfoo acquired by OpenAI March 9, 2026 | AppSec Santa review, multiple sources | Official docs verified |
| OTel GenAI stable in OTel 1.29+ | OpenObserve OTel guide, Datadog blog | Official docs verified |
| Phoenix runs local, SQLite/Postgres | Phoenix GitHub repo, Phoenix docs | Source/code verified |
| OpenInference BedrockInstrumentor exists | openinference PyPI, Arize docs | Official docs verified |
| Portkey covers 1,600+ LLMs | Portkey docs, GitHub models repo | Official docs verified |
| LiteLLM covers 100+ providers | LiteLLM docs | Official docs verified |
Known Gaps
- Helicone exact current pricing post-Mintlify acquisition: pricing page may be stale
- Portkey post-Palo Alto acquisition product roadmap: unclear
- Promptfoo post-OpenAI acquisition: open-source future not clarified
- Braintrust pricing: not publicly listed; contact-sales only
- Fiddler LLM-specific pricing: enterprise-only, not public
- W&B Weave exact trace pricing model: complex, shared with W&B platform billing
Next Research Lanes
- Acquisition outcomes (6-month check): How Portkey under Palo Alto Networks, Promptfoo under OpenAI, and Helicone under Mintlify have evolved. Product kills and feature migrations are the most likely outcomes.
- OTel GenAI spec coverage gaps: Whether the OTel 1.30+ spec has absorbed retrieval and agent span kinds from OpenInference, reducing the need for OpenInference-specific auto-instrumentation.
- Ragas deep dive: The open-source RAG evaluation library was not covered in depth here. Ragas provides metric-specific eval (context recall, context precision, faithfulness, answer relevancy) that complements Langfuse/Phoenix eval pipelines rather than replacing them.
- Cost at 1B+ tokens/day: The decision framework above assumes moderate scale. At very high volume, self-hosted LiteLLM + Langfuse self-hosted economics change significantly; the infra cost of ClickHouse becomes negligible relative to the per-event cloud costs.
- MLflow LLM tracing: MLflow 2.12+ added LLM tracing. For teams already using MLflow for model tracking, this is a natural extension. Not covered here because it is not yet competitive with Langfuse or LangSmith on UX.