Generic OpenTelemetry

If you’re using a framework DecimalAI doesn’t have a first-class integration for — but it emits OpenTelemetry spans following the gen_ai.* semantic conventions — the generic OTel exporter will pick them up. There is no list to be on: the exporter reads span attributes, so any framework, library, or hand-rolled pipeline that puts gen_ai.* spans on the tracer provider is captured, whether or not DecimalAI has ever heard of it. The corollary is worth stating plainly: this page is also where retired integrations land. decimalai.init(autogen=True) (AutoGen / AG2, both lineages) installs exactly this exporter and warns — the flag keeps working so existing code doesn’t break, but the framework is instrumented by you, not by DecimalAI. AG2 emits no spans until you call autogen.opentelemetry.instrument_llm_wrapper(capture_messages=True) once and autogen.opentelemetry.instrument_agent(agent) per agent; do that, and the spans arrive here like any other OTel source.

Install

pip install decimalai

OTel SDK packages are pulled in transitively.

Use

import decimalai
decimalai.init(api_key="dai_sk_...", otel=True)

# `otel=True` puts DecimalAI's exporter on the global TracerProvider, so any span
# carrying `gen_ai.*` attributes reaches it — your framework's own instrumentor,
# or a span you open yourself like this one.
from opentelemetry import trace

tracer = trace.get_tracer(__name__)
with tracer.start_as_current_span("chat gpt-4o") as span:
    span.set_attribute("gen_ai.system", "openai")
    span.set_attribute("gen_ai.request.model", "gpt-4o")
    span.set_attribute("gen_ai.prompt.0.content", "Hello!")
    reply = "Hi! How can I help?"  # <- your model call goes here
    span.set_attribute("gen_ai.completion.0.content", reply)

Run that and one trace appears on the Traces page: a single LLM call on gpt-4o, input Hello!, output Hi! How can I help?. Nothing about it is DecimalAI-specific — swap the four set_attribute lines for a real instrumentor and the same trace arrives. Spans leave on the OTel batch processor’s own schedule — roughly every five seconds, and again when the process exits. To push one out immediately (a long-running server, a notebook cell you want to check), force-flush the provider: trace.get_tracer_provider().force_flush(). Note that decimalai.flush() is not the lever here — it drains the SDK’s own trace buffer and never reaches the OTel batch queue.

What gets captured

DecimalAI maps these OTel attributes onto its trace shape:

OTel attribute	DecimalAI field
`gen_ai.system` / `gen_ai.request.model`	`model`
`gen_ai.prompt.0.content` (and indexed siblings)	`input`
`gen_ai.completion.0.content`	`output`
`gen_ai.usage.input_tokens`	`input_tokens`
`gen_ai.usage.output_tokens`	`output_tokens`
Span duration	`latency_ms`

Tool calls, retriever spans, and embeddings are mapped similarly when they follow the convention.

When to use this vs. a first-class integration

Use the first-class integration if one exists for your framework — it captures more metadata (tool schemas, handoffs, etc.) than OTel conventions can express. Use generic OTel for:

Frameworks DecimalAI doesn’t support (Haystack, Mirascope, AutoGen / AG2, etc.)
Bespoke pipelines you’ve already instrumented with OTel
Multi-framework apps where you want a unified exporter

What’s next

Manifests

register_manifest() is mandatory for OTel-only setups — auto-detection only works for first-class integrations.

Tracing guide

What gets captured at each layer of the stack.

Python SDK

CLI

Generic OpenTelemetry

Install

Use

What gets captured

When to use this vs. a first-class integration

What’s next

Manifests

Tracing guide

​Install

​Use

​What gets captured

​When to use this vs. a first-class integration

​What’s next

Manifests

Tracing guide

Install

Use

What gets captured

When to use this vs. a first-class integration

What’s next