Logging LLM provider request ids as gen_ai attributes

[dinmukhamedm]

It would be very useful for debugging purposes (e.g. with OpenAI support) to have a unique identifier to an LLM call span. Has OpenLLMetry considered adding something like gen_ai.request.id attribute?

The biggest challenge I see with this is that they are not unified, and formatted differently across providers and even across endpoints of a single provider (e.g. completions vs assistant). Generally, there is a request-wide unique ID though, and if there is none, the attribute can obviously remain optional.

[dinmukhamedm]

Also, saw this comment in the code of semantic conventions from 6 months ago. Looks like this was planned but never executed?

[nirga]

Do you mean to log an ID returned by the provider? Or our own random ID?

[nirga]

Yes definitely something we need to add!

[codefromthecrypt]

ok, so this is gen_ai.response.id.. or something different?

[dinmukhamedm]

Yes, that. I've not seen it implemented in OpenLLMetry libraries though

[nirga]

@dinmukhamedm we need to add it! I'm converting this to an issue

[dinmukhamedm]

@nirga thanks! Closing this discussion, and I will respond on the issue if I find time to contribute at least partially

[dinmukhamedm]

Closing in favor of #2236

[kinthaiofficial]

Request IDs as gen_ai attributes is useful, but in multi-agent systems the provider request ID is actually the leaf node of what you really need — the full delegation trace from root task down to the individual LLM call.

A pattern we found valuable: propagate a delegation_chain_id alongside the provider request ID. The delegation chain is a stable identifier that survives retries (if the LLM call is retried, you get a new request_id but the same chain_id) and lets you correlate costs across an entire agent execution tree.

The gen_ai semantic conventions don't have attributes for:

• Which agent made the call (vs which application)
• What budget was allocated to this call vs what was available
• Whether this call was on behalf of a parent agent's delegation

We ended up adding custom attributes: agent.id, agent.delegation_depth, agent.budget_allocated_millicents, agent.budget_used_millicents. The last two are the most operationally useful — they let you spot runaway agents before they exhaust a user's quota.

Related: we wrote up how cost attribution flows through a delegation chain here — https://blog.kinthai.ai/agent-wallet-economic-models-autonomous-agents — the economic model informs what you need to log at the OTEL layer.

Are you trying to solve cross-agent attribution or mostly just provider-level deduplication with the request IDs?