OpenLLMetry-JS: OpenTelemetry Instrumentation for TypeScript LLM Applications

What OpenLLMetry-JS solves for TypeScript teams

Most application performance tooling has no idea what a chat completion is. A Node service that calls OpenAI, then Pinecone, then Anthropic produces HTTP spans that show latency and status codes but not the model name, the token counts or which prompt template ran. OpenLLMetry-JS exists to close that gap. It is a set of extensions built on top of OpenTelemetry, and the README describes it as giving "complete observability over your LLM application".

The audience is narrow and identifiable: teams running LLM features in Node.js or Next.js who already have an observability stack and do not want a second one. Because the output is standard OpenTelemetry data, the README states it can be connected to Datadog, Honeycomb and others. That is the whole pitch. If you have no collector and no backend, this project gives you instrumented spans and nowhere obvious to put them.

The repository is a monorepo. The root package.json is private and versioned 0.0.1, with a pnpm workspace, Lerna and Nx driving builds across packages/. The published artifact most people will touch is @traceloop/node-server-sdk on npm. The last push to the default branch was on 2026-06-18, and the most recent release listed is 0.27.0 from 2026-05-29.

How the instrumentation hooks into your LLM calls

The mechanism is monkey-patching through OpenTelemetry instrumentation libraries. OpenLLMetry-JS can instrument everything OpenTelemetry already instruments, which the README lists as your database, API calls and more. On top of that layer sit custom instrumentations for LLM providers and vector databases.

The README's supported list is explicit. Providers marked done include OpenAI, Azure OpenAI, Anthropic, Cohere, Vertex AI and Bedrock. Replicate and HuggingFace are marked pending. Vector databases marked done are Pinecone, Chroma and Qdrant, with Weaviate and Milvus pending. Frameworks covered are LangChain and LlamaIndex. Those pending markers matter more than they look: a pending integration is not an integration, and the README does not say when it will land.

Data flow is one-directional. Your code calls the provider SDK, the instrumentation intercepts the call, a span is created with LLM-specific attributes, and the span is exported over OTLP to whatever endpoint you configured. The SDK adds convenience on top of the raw instrumentations, but the README is clear that it still outputs standard OpenTelemetry data. Two consequences follow. First, anything your existing pipeline does to spans (sampling, attribute scrubbing, tail-based routing) applies here too. Second, if you already have OpenTelemetry instrumented, the README says you can add any of the instrumentations directly instead of taking the SDK.

Installing the SDK and getting a first trace out

The README gives a two-step start. Install the package, then call initialize before any LLM module is imported.

npm install --save @traceloop/node-server-sdk

Then in your entry file:

import * as traceloop from "@traceloop/node-server-sdk";

traceloop.initialize();

The README is emphatic about ordering: make sure to import the SDK before importing any LLM module. That is not stylistic advice. Instrumentation works by patching a module as it loads, so a provider SDK imported earlier is already bound to its original implementation and stays invisible. In practice this means the two lines belong at the top of your process entry point, above everything else.

When you run locally, the README suggests disabling batch sending so traces appear immediately:

traceloop.initialize({ disableBatch: true });

With batch sending off, spans are exported as they finish rather than on a timer, which is what you want when you are watching a terminal. Leave it on in production. After that, the remaining decision is the destination. The README points to a separate exporting guide and lists tested destinations including Traceloop, Dynatrace, Datadog, New Relic, Honeycomb, Grafana Tempo, HyperDX, SigNoz, Splunk and the OpenTelemetry Collector.

Where OpenLLMetry-JS stops being the right tool

It is a tracing library, not an LLM platform. The README documents no prompt versioning, no evaluation runs, no dataset management and no annotation queue. If those are what you actually need, you will be building them next to this project, not with it.

The import-order requirement is the sharpest practical edge. A framework that loads provider clients during module initialization, or a Next.js setup where instrumentation has to be registered in a specific file, can silently produce zero LLM spans while ordinary HTTP spans keep flowing. The README does not document a diagnostic for that case, and it does not document rollback either. You find out by noticing that your traces have no model attributes.

Pending integrations are a second boundary. If your stack uses Replicate, HuggingFace, Weaviate or Milvus, the README marks each as pending, so plan on the generic OpenTelemetry instrumentation for those calls and accept that you will not get provider-specific attributes. The README also notes that the SDK and instrumentations no longer log or collect telemetry, and asks users to be on v0.21.1 or above. Older versions are a different privacy story, and the README does not describe what those versions did.

OpenLLMetry-JS versus Langfuse and OpenInference

The comparison people search for is OpenLLMetry versus Langfuse, and the difference is architectural rather than feature-level. OpenLLMetry-JS is an instrumentation layer that emits OpenTelemetry spans and hands them to a backend you choose. Langfuse is a trace store with its own UI, its own data model for prompts and scores, and SDKs that send data to it. Choosing OpenLLMetry-JS means your LLM traces live beside your HTTP and database traces in Datadog, Honeycomb or SigNoz. Choosing a dedicated LLM platform means they live in a purpose-built interface, at the cost of a second place to look.

OpenInference is the closer comparison, because it is also an instrumentation convention rather than a backend. Both projects aim to describe LLM calls as spans. The distinction the README draws is that OpenLLMetry's semantic conventions are now part of OpenTelemetry, with a link to the OpenTelemetry community discussion on LLM semantic conventions. Whether that matters to you depends on how much you care about attribute names being portable across vendors. If you do, the standards path is the argument for this project. If you only care that traces show up somewhere readable, the argument is weaker.

The related searches for OpenLLMetry java and OpenLLMetry golang point at the same design: the sister project covers Python, and this repository is the TypeScript port, so the span shape is intended to be consistent across languages.

Licence, upgrade cost and monorepo maintenance

The repository is Apache-2.0, and the README states it is built and maintained by Traceloop under that licence. Apache-2.0 covers the code in this repository. It does not cover the hosted Traceloop service that appears in the tested destination list, and the README does not describe terms for that service. If your organisation restricts which vendors receive trace data, that distinction is the one to check before wiring the exporter, because spans from LLM calls can carry prompt text.

Upgrade cost is shaped by the release cadence. Three releases are listed between 2026-04-13 and 2026-05-29, which is roughly six weeks for three minor versions. The CHANGELOG.md at the repository root is where breaking changes would be recorded, and the monorepo uses commitlint with conventional commits plus @jscutlery/semver, so version bumps are generated from commit messages rather than hand-written. The root package.json also carries a pnpm overrides block pinning transitive dependencies such as zod, form-data, undici and others, which means a fresh install resolves those versions rather than whatever the instrumented provider SDKs request. That is a maintenance decision made for you, and it is worth knowing about if you also depend on those packages directly.

The last push to the default branch was on 2026-06-18, so the repository is not archived but has not received a push in the three months before this writing.

Editorial conclusion

Adopt OpenLLMetry-JS if you already run an OpenTelemetry backend and want LLM spans in it without a second agent; the SDK is small, the licence is Apache-2.0, and the instrumentations are usable on their own. Do not adopt it if you want prompt management, evaluation scoring or a hosted trace UI out of the box, because the README lists none of those. Before you commit, verify the import ordering in your entry file, confirm whether your provider or vector store is on the supported list rather than the pending one, and check the CHANGELOG for breaking changes between 0.25.0 and 0.27.0.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. traceloop/openllmetry-js on GitHub