Skip to main content
Honeycomb enriches spans describing calls to large language models (LLM) with an estimated US dollar cost. LLM costs are calculated at ingest, based on the token counts your instrumentation reports and Pydantic’s pricing catalog. These LLM costs are added to your spans as fields you can query, group, and visualize.
LLM cost is a catalog estimate, not a billed amount. It does not reflect negotiated rates, committed-use discounts, free tiers, or credits. Do not use it to reconcile a provider invoice.

Attributes used to calculate cost

The estimated total cost (io.honeycomb.gen_ai.cost.estimated_total_cost) is calculated from:
  • Input (prompt) and output (completion) tokens
  • Cached token reads and writes (when applicable)
  • AI model and provider
Honeycomb reads standard OpenTelemetry GenAI semantic convention attributes (v1.41.1). If your application uses an OpenTelemetry-based GenAI instrumentation library, these attributes are likely already on your spans. Honeycomb reads a fallback name only when the preferred name is absent or empty. The two cache counts are subsets of gen_ai.usage.input_tokens, not additions to it. Honeycomb prices them out of that same input total at their own rates, so a cache read is never double-counted.

Report Anthropic input and cache token counts correctly

The Anthropic API reports input_tokens, cache_read_input_tokens, and cache_creation_input_tokens as three separate numbers. Anthropic’s input_tokens excludes cached tokens. The OpenTelemetry GenAI semantic conventions define gen_ai.usage.input_tokens differently. It includes the cache read and cache write tokens. To report a call that uses Anthropic models, add the three Anthropic numbers together:
For example, a call where Anthropic reports 10 input tokens, 7,433 cache read tokens, and 71 cache creation tokens must set gen_ai.usage.input_tokens to 7,514. Most GenAI instrumentation libraries add these numbers for you. Hand-written instrumentation and some instrumentation for Claude models on Amazon Bedrock copy Anthropic’s numbers into the attributes unchanged. Older versions of other libraries might do the same.

What happens when input tokens exclude cached tokens

Because Honeycomb assumes gen_ai.usage.input_tokens includes the cached tokens, it subtracts the cache counts from the input count to price the uncached input. When the input count excludes cached tokens, this causes one of two problems:
  • If the cache counts are larger than the input count, the subtraction is negative and Honeycomb cannot price the span. The span has no cost fields.
  • If the cache counts are smaller than the input count, Honeycomb prices the span, but undercounts the input. The estimated cost is lower than the real cost.
If a span reports more cached tokens than input tokens, its instrumentation reports input tokens that exclude cached tokens. To find these spans, create a Calculated Field with the formula GT($gen_ai.usage.cache_read.input_tokens, $gen_ai.usage.input_tokens). Refer to the Calculated Field Expression reference for syntax. Then filter for spans where the field is true.

Correct token counts in the OpenTelemetry Collector

If you cannot change your instrumentation, use the transform processor in the OpenTelemetry Collector to add the cache counts to the input count before the spans reach Honeycomb. The following example assumes that gen_ai.usage.input_tokens, when present, holds Anthropic’s input_tokens value, and that the cache counts are in gen_ai.usage.cache_read.input_tokens and gen_ai.usage.cache_creation.input_tokens. If a span has a cache count but no gen_ai.usage.input_tokens, the processor sets the input count to the sum of the cache counts. Replace these names with the attributes your telemetry uses.
Add the processor to the processors list of your traces pipeline.
Apply this processor only to spans whose input count excludes cached tokens. If a span already reports an inclusive input count, adding the cache counts again overstates the input and the cost.

How LLM span cost is calculated

A span’s cost is calculated only when all of the following are true. The following checks run in order, and the first failure stops the calculation.
1

The span names a model.

gen_ai.response.model, or else gen_ai.request.model.
2

The span does not already carry a cost.

Honeycomb skips spans that already carry a cost, as described in Reporting your own LLM costs.
3

The operation accounts for tokens.

One of chat, text_completion, generate_content, embeddings, or retrieval. Aliases resolve first, so chat_completion counts as chat.Operations such as invoke_agent, create_agent, execute_tool, or invoke_workflow are not priced, because their cost is already captured by the inference spans beneath them.
4

The provider is supported.

openai, anthropic, or aws.bedrock. The comparison is case-insensitive and ignores surrounding whitespace.
5

The span reports token counts.

At least one of gen_ai.usage.input_tokens or gen_ai.usage.output_tokens.
6

The model appears in the pricing catalog.

New model releases can take a short time to appear.
A missing operation name or a missing provider fails its check. When a span fails any check, Honeycomb adds no cost fields to the span and changes nothing your instrumentation sent.
Honeycomb searches the catalog for your reported provider first, then the whole catalog. That second pass prices a Bedrock-hosted Anthropic model, whose rates are published by Anthropic rather than AWS. On those spans, gen_ai.provider.name is aws.bedrock while io.honeycomb.gen_ai.cost.pricing_provider is anthropic. The two fields are expected to be different. This is not a bug.

LLM cost fields Honeycomb adds

Honeycomb writes seven fields in the io.honeycomb.gen_ai.cost namespace.
double
Estimated cost of the input tokens in US dollars.
double
Estimated cost of the output tokens in US dollars.
double
Estimated cost of the whole LLM call in US dollars.
string
The provider whose rates were applied.
string
The pricing library that performed the calculation.
string
The source of the rate data.
string
The version of the price table applied.
The four pricing_* fields record what produced the estimate, so you can trace any cost estimate back to the price table used to calculate it. The pricing_* fields are written as a set of four, or not at all. Honeycomb reports three cost figures only. There is no separate cost field for cache reads, cache writes, or reasoning tokens, even though those counts feed the calculation. To see where a rate difference shows up, group by model and provider.

About the io.honeycomb.* namespace

The io.honeycomb.* namespace is an incubating space for attributes Honeycomb is also pursuing upstream in the OpenTelemetry semantic conventions. Honeycomb defines an allowlist of io.honeycomb.* keys and what each key means. Undeclared io.honeycomb.* keys are dropped at ingest. If you provide your own values, they are never overwritten.

Reporting your own LLM costs

If you’d like to report your own LLM cost estimates, your telemetry should provide values for the estimated cost fields in the io.honeycomb.gen_ai.cost namespace. Honeycomb does not write anything to the io.honeycomb.gen_ai.cost namespace if any one of these cost fields is present on the span with a value:
  • io.honeycomb.gen_ai.cost.estimated_input_cost
  • io.honeycomb.gen_ai.cost.estimated_output_cost
  • io.honeycomb.gen_ai.cost.estimated_total_cost
A cost of 0 counts as a reported cost. This matters when your provider reports an authoritative per-call cost a catalog cannot reproduce. For example, an OpenRouter call may route to a different upstream provider on every request, so only the response knows what it cost. Send that figure and Honeycomb leaves it alone.

Where cost appears in Honeycomb

The seven fields are ordinary public fields on your dataset, and are available regardless of whether any LLM cost-specific UI is enabled for your team. They appear in the field picker, are queryable by name, and work with SUM, AVG, HEATMAP, P95, and any other numeric operator. The cost fields also work in Triggers, SLOs, Boards, and Calculated Fields.

Example cost estimation queries

Cost by model or service

Find the estimated total cost of each LLM model or service.

Cost per user

See the average cost per user or tenant. Here are some useful queries you can run with the cost estimation fields:

Identify GenAI call cost outliers

Find cost outlier GenAI calls, then use BubbleUp to investigate further.

Limitations

  • The cost estimate is a catalog price, not your invoice.
  • A span with no token counts cannot be priced, so a streaming call that never reports usage produces no cost.
  • Agent, tool, and workflow spans are not priced. Cost accrues on the inference spans they contain.
  • If a model is missing from the catalog, no cost estimate is calculated.
  • Cost is estimated per call. You can use queries to aggregate to the trace or session.