How does Rius read OpenLLMetry model name attributes?
Rius reads the model name of an OpenLLMetry span from the standard GenAI keys, gen_ai.request.model for the requested model and gen_ai.response.model for the model the provider reports. Spans from current OpenLLMetry releases already use these keys. Spans from older releases are normalized onto them at ingest, so model analytics work across versions. In the console, the span shows the model name next to its token counts.
How it works
Rius stores the model on two canonical keys:
gen_ai.request.modelis the requested model. It drives model analytics and cost.gen_ai.response.modelis the model the provider reports.
Current OpenLLMetry releases emit OpenTelemetry GenAI attributes (gen_ai.*), so Rius reads them as sent. Older releases use other spellings, for example gen_ai.usage.prompt_tokens and completion_tokens for usage. Rius normalizes all of OpenLLMetry’s attribute spellings at ingest. It moves the values onto the canonical keys before storage and removes the source keys it mapped. Native gen_ai.* keys always win. Normalization fills gaps and never overwrites.
The same normalization sets the span’s kind. The Traceloop decorator kinds (workflow, task, agent, tool) and the provider span’s llm.request.type become the span taxonomy. Rius counts a span as an LLM call when its kind is LLM, or when it has no kind and no operation but carries gen_ai.request.model.
Cost is computed by Rius from gen_ai.request.model and the token counts. A span needs the request model and at least one count. A span with no model, or with a model the price catalog does not know, gets no cost. Never send a cost attribute. Send the model name and tokens.
For the full mapping, see the supported-conventions matrix in the span attribute reference.
Set it up
- Point OpenLLMetry’s exporter at Rius. This is the only setup the model name needs, and the OpenLLMetry guide covers it in full.
from traceloop.sdk import Traceloop
Traceloop.init(
app_name="my-agent",
api_endpoint="https://ingest.eu.console.rius-glassflow.com",
headers={"Authorization": "Bearer <your API key>"},
)- Run one traced LLM call from your application. You do not set the model attribute yourself. OpenLLMetry’s instrumentation records it.
- Open the trace in the console and select the model call. Check that the span shows a model name and token counts.
- When you search or filter in trace inspection, use the canonical key. Use
gen_ai.usage.input_tokens, notgen_ai.usage.prompt_tokens. Searching on the key the source used finds nothing, because Rius removes the keys it mapped. - If you run long agent loops on an older OpenLLMetry release, raise OpenTelemetry’s per-span attribute limit. Those releases write messages one attribute per field, and a span that passes the limit can lose its model, usage or messages. See the attribute count limit section of the reference.
To compare this path with the SDK and other senders, see Trace LLM calls with OpenTelemetry.
What you get
- The span for each model call shows the model name and its token counts, whether the application runs a current or an older OpenLLMetry release.
- Cost per call, a list-price estimate in US dollars, appears when the model is in Rius’s price catalog.
- The model appears in the per-model breakdown and in model filters, because the value sits on
gen_ai.request.model. - Prompt and completion content is visible in trace inspection. Older flattened
gen_ai.prompt.*andgen_ai.completion.*messages are reassembled into the GenAI message shape. - Nothing in your application changes. Normalization happens at ingest, so you keep your existing OpenLLMetry instrumentation.
Two OpenLLMetry details are not mapped yet. The per-completion gen_ai.completion.N.finish_reason of older releases and the flattened tool definitions under llm.request.functions.* are stored under their own names.
When something else fits
- If you control the instrumentation, you can set
gen_ai.request.modelyourself with a vanilla OpenTelemetry SDK. The span attribute reference lists the keys to set. - If you route traces through a pipeline, or want Rius to receive them next to another backend, the interoperability overview lists the collector and the other sender guides.