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.

Install

pip install decimalai

OTel SDK packages are pulled in transitively.

Use

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

# Any framework emitting OTEL spans will be captured
# Maps gen_ai.* semantic conventions automatically

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 yet support (Haystack, Mirascope, 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.

​Install

​Use

​What gets captured

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

​What’s next