Which OpenTelemetry GenAI span attributes carry the model name and token counts?

## Why a fixed vocabulary exists Every provider SDK returns its own shape: one calls the field `usage.prompt_tokens`, another `usage.input_tokens`, a third nests it under a different key entirely. If each tracing integration invented its own span attribute names, every dashboard, alert and cost report would have to be rewritten per provider and per library. The OpenTelemetry GenAI semantic conventions solve exactly that: they define a small set of attribute keys that any instrumentation — OpenLLMetry included — writes onto the span that wraps a model call. The payoff is that a backend which has never seen your source code can still answer "how many output tokens did each model burn yesterday". ## The identity attributes - `gen_ai.provider.name` — which provider API was invoked, with values such as `openai`, `anthropic`, `aws.bedrock`. This attribute replaced the older `gen_ai.system`, which is now deprecated. - `gen_ai.operation.name` — the kind of call: chat completion, text completion, embeddings. This is what lets you exclude embedding spans from a chat-latency chart. ## The two model attributes `gen_ai.request.model` is the identifier your code passed in — for example `gpt-4o`. `gen_ai.response.model` is what the provider reports having used, which is frequently a pinned, dated snapshot behind an alias. Recording both is deliberate: an alias silently rolling to a new snapshot is one of the most common explanations for "the prompt started behaving differently and nothing changed on our side". Group your quality metrics by the response model, not the request model, if you want that shift to be visible. ## Request parameters `gen_ai.request.temperature`, `gen_ai.request.max_tokens` and `gen_ai.request.top_p` record the sampling knobs. They are cheap, low-cardinality numbers, and they let you correlate an odd or slow response with the settings that produced it — useful when a config change ships through a feature flag rather than through code. ## Usage: the two attributes everything financial is built on `gen_ai.usage.input_tokens` and `gen_ai.usage.output_tokens` are plain integers. Almost every cost view in every LLM observability product is these two numbers multiplied by a per-model price and grouped by model. Note the naming history: earlier drafts of the convention used `gen_ai.usage.prompt_tokens` and `gen_ai.usage.completion_tokens`, mirroring the OpenAI response shape. The current names are input/output, which generalise across providers that do not use prompt/completion language. Dashboards built against the old spelling silently return nothing rather than erroring, so a chart that suddenly reads zero after a dependency bump is worth checking against the current names. ## What is deliberately absent Three things are not in this core set: 1. **Cost.** No attribute carries dollars. Prices change and vary by contract, so the convention records the physical quantity (tokens) and leaves money to the backend's price table. That also means a stale price table, not a bad span, is a common cause of a wrong cost chart. 2. **Prompt and completion text.** Message content is treated as a separate, sensitive, opt-in concern rather than part of the always-on attribute set — it is the payload, not the metadata. 3. **Provider-specific extras.** Anything one vendor exposes and others do not tends to live outside the standard names, so treat such keys as non-portable. ## Where these come from in practice With OpenLLMetry you rarely write these attributes yourself. Its auto-instrumentation wraps the provider client and sets them on the span it creates around the call, reading the values out of the request arguments and the response object. You read them in queries: sum output tokens by `gen_ai.request.model`, chart p95 duration filtered by `gen_ai.provider.name`, alert when a model's error rate spikes. If you hand-roll a span around a call the instrumentation does not cover, setting the same keys yourself is what makes it show up in the same charts. ## Common trip-ups Confusing request and response model when grouping metrics; assuming token attributes are always present (a streamed response may not carry usage unless the client asked for it, in which case the attribute is simply missing rather than zero); and expecting `gen_ai.usage.input_tokens` to break out cached versus fresh input tokens, which it does not — it is one number, and billing may treat parts of it differently.