Valistry

OpenTelemetry

Token counts and the attributes around them: the model, the provider, your service and environment, the agent, the conversation and the trace. Never a prompt, never a completion, never a tool argument — those attributes are not on the list this source will read, so they cannot reach a record even when you send them.

Access

Kind
A key we issue; your side sends
What to give
An endpoint and a key we issue
Why that one
Your instrumentation sends to us. There is no key of yours to hand over and nothing for Valistry to call.

What it attributes on its own

From the source
request · model · provider · input and output tokens · service · environment · agent · conversation · prompt name and version · trace · latency · errors
Needs a rule or a trace
the bill — OpenTelemetry carries tokens, not money, so these rows are priced from the rate card and say so · a model the rate card has no rate for, which lands at zero and is marked · anything your instrumentation does not emit

Connecting it

  1. Create the endpoint. Valistry issues a key for this organization and shows it once. Nothing of yours is stored: the key is ours, and you can replace it at any time.
  2. Point your collector or SDK at it. Set two environment variables on anything that already emits GenAI telemetry. JSON is the encoding we accept; protobuf is refused with a message saying so.
  3. Send. Records appear as they arrive. Re-sending the same span never double counts: a span is stored under its own trace and span id.

Instrumenting is the deepest of the three routes and the only one that reaches a provider with no usage API at all — but it needs a change in your applications. A gateway needs only a base URL, and a provider's own source needs nothing changed. Where you send both, connect one: the same call would otherwise be counted twice.