What does the service.version attribute mean in Rius?

In Rius, service.version is a resource attribute that holds the build or release your process runs, for example a release number or a build tag. You set it once for the process, not on each span. The Rius SDKs read it from the RIUS_SERVICE_VERSION environment variable, and any other OpenTelemetry sender can set it as a resource attribute. The Agents page compares versions by it: Compare shows it as Build, next to Agent version (rius.main_agent.version, the agent definition), and you switch between the two when traces carry both.

How it works

• What the key holds. The value is a string that names the build or release of the process. Rius lists it with the other resource attributes in the span attribute reference, next to service.name and service.instance.id.
• Resource, not span. A resource attribute describes the process that produces telemetry, not a single LLM call or tool call. You do not set it inside a trace, on a model call or in a tool wrapper.
• Where the SDKs read it. Both the Python and TypeScript SDKs read RIUS_SERVICE_VERSION. Unset, the SDKs use a service.version from OTEL_RESOURCE_ATTRIBUTES, and otherwise send no service.version.
• Senders without the SDK. A vanilla OpenTelemetry SDK or a collector pipeline sets service.version in its resource configuration. The key name is the standard OpenTelemetry one, so you need no Rius-specific spelling. The OpenTelemetry guide covers sending traces from these senders.
• Older names. None are documented for this key. Use service.version as written.
• Build, not agent definition. service.version describes the build the process runs. rius.main_agent.version describes the agent’s definition: its prompt, tools and policy. The SDKs read it from RIUS_MAIN_AGENT_VERSION. The Agents page compares either one: Build for service.version, Agent version for rius.main_agent.version.
• Nothing to send for cost. Rius computes cost and time to first token from the spans. You never send a cost or latency value, and service.version plays no part in either.

Set it up

1. Pick a value that identifies the release, such as a semantic version, a build number or a short commit hash. Use the same value for every process that runs that build.
2. With the Rius SDKs, export the variable before the process starts, next to your service name and API key:

export RIUS_API_KEY=ri_...
export RIUS_SERVICE_NAME=my-agent
export RIUS_SERVICE_VERSION=2026.10.1

The value 2026.10.1 is only an example. Use your own release identifier. The SDK installation page covers install and init in full. 3. With a vanilla OpenTelemetry SDK or a collector, set service.version in the resource configuration of the same process that sets service.name. Set service.name always, because every trace view and filter groups by it. 4. Change the value on each deploy. A process that keeps an old value keeps reporting the old release. 5. To compare builds, service.version is enough. To compare agent definitions (prompt, tools, policy) independently of the build, also set rius.main_agent.version, or RIUS_MAIN_AGENT_VERSION in the SDKs.

What you get

• A resource attribute named service.version that carries the build or release your process runs, sent with your telemetry in the standard OpenTelemetry form.
• One consistent key across the SDKs and any OpenTelemetry sender, so mixed fleets label their releases the same way.
• Build comparisons on the Agents page: Compare sets two builds side by side, and when traces also carry rius.main_agent.version you switch between Build and Agent version.
• No effect on cost, which Rius computes from the model and token counts.

When something else fits

• If you want to compare versions of the agent definition, such as a prompt change, independently of the build, set rius.main_agent.version as well.
• If you want to group traces by the agent or service that produced them, service.name is the key every trace view and filter groups by, so set that first.

Related