Datadog LLM Observability pricing 2026: 6 levers that cap the bill

Summary. Datadog's LLM Observability product, now branded Agent Observability in its own documentation, meters exactly one thing: the count of LLM spans. The Free plan covers up to 40,000 LLM spans a month with 15-day retention and full feature access. Pro starts at $160 a month and includes 100,000 LLM spans, with on-demand usage billed above that line. Tool spans, embedding spans, retrieval spans and agent spans are not billed at all, so an agent that grows from 3 steps to 12 steps costs nothing extra unless the extra steps are model calls. Retention add-ons extend traces and spans to 30, 60 or 90 days and are billed per 10,000 LLM spans; experiment results extend to 6, 9 or 12 months, and datasets carry a separate 3-year retention. Evaluations carry no separate product fee, but any eval that calls a model creates LLM spans that do bill. Datadog computes an estimated dollar cost per request against published provider rates for 800-plus models, reported in nanodollars. The FinOps Foundation's sixth annual survey, published 19 February 2026, found 98% of 1,192 practitioners now manage AI spend, up from 31% two years earlier, across companies representing more than $83 billion in annual cloud spend. That is the context in which an unbudgeted observability line item gets noticed.

The practical problem is not that Agent Observability is expensive. It is that most teams instrument first and read the meter later, and the meter counts something specific enough that a small architecture decision moves the bill by a multiple.

What Datadog actually bills for

Agent Observability categorises every span it receives by span kind, and only one of those kinds is billable. From Datadog's own pricing FAQ: "LLM Observability meters and bills only on the count of LLM spans. Tool spans, embedding and retrieval spans, and agent spans are not billed."

That single sentence is the whole cost model, and it inverts the intuition most platform teams bring from APM. In host-based monitoring, adding steps adds cost. Here, adding steps is free as long as the steps are not model calls.

Span kind	Billed?	What creates it
LLM	Yes	Each call to a model provider such as OpenAI or Anthropic
Agent	No	An autonomous sequence of decisions, usually the root span
Workflow	No	A fixed sequence of operations wrapping model and tool calls
Tool	No	A call to an external program or service with LLM-generated arguments
Task	No	A standalone local step, such as prompt preprocessing
Embedding	No	A call to an embedding model or function
Retrieval	No	A vector search returning ranked documents from a knowledge base

Two consequences follow, and they point in opposite directions.

The good one: retrieval-augmented pipelines are cheap to observe. A RAG request that does one embedding call, one vector search, three tool calls and one completion bills as one LLM span. Datadog's own framing is that pricing "scales better as your context window grows and your agent becomes more complex and autonomous," and on the evidence of its span-kind table, that holds.

The bad one: multi-turn reflection patterns are expensive to observe. A planner-critic loop that calls the model to draft, then to critique, then to revise, bills three LLM spans for one user request before any tool work happens. Nothing about that is hidden, but it is rarely what a team estimates when it budgets from request volume.

The arithmetic is worth doing before you sign anything.

Application shape	Model calls per request	LLM spans at 100,000 requests/month
Single-turn completion (classifier, summariser)	1	100,000
RAG assistant, one completion after retrieval	1	100,000
Two-pass agent (plan, then answer)	2	200,000
Planner-critic-revise loop	3	300,000
Tool-calling agent, average 5 model turns	5	500,000

Those figures are arithmetic on your own traffic, not vendor claims. Run them against your actual per-request model-call count before you pick a plan, because the difference between rows one and five is a factor of five on the only number Datadog charges for.

The published pricing, and where it stops

Datadog's LLM Observability pricing page lists two self-serve plans.

Plan	Price	Included LLM spans	Retention	Notes
Free	$0 per month	Up to 40,000	15 days	Unlimited context and evals, full feature access
Pro	From $160 per month	Starting at 100,000	15 days	On-demand usage billed above 100,000 spans
Retention add-on	Billed per 10,000 LLM spans	n/a	30, 60 or 90 days	Extends experiments to 6, 9 or 12 months
M2M / annual commitment	Discounted, not published	Custom	15 days on traces and spans	Experiments retained 90 days
Datasets	Included	n/a	3 years	Versioned, so experiments rerun against a baseline

The page carries two qualifiers that matter more than they look. The first: "Pricing varies by region. Annual pricing shown. On-demand and M2M options available." The second is what is missing. Datadog publishes the entry price and the included volume, but it does not publish the per-span on-demand rate above 100,000 spans, nor the per-10,000-span price of the retention add-ons. Several third-party blogs quote precise figures for both. None of those figures appear on Datadog's own pricing page or in its documentation, so treat them as unverified and get the rate in writing from your account team before you model anything past the included tier.

This is the single most common way LLM observability budgets go wrong in 2026: a team models the $160 entry price, ships an agent that makes four model calls per request, and discovers the shape of the overage curve only after the first invoice. The rate is knowable. It just is not public.

The estimated-cost feature is not the bill

Agent Observability also computes an estimated dollar cost for every LLM request, which is a different number from what Datadog charges you. It works by taking the token counts annotated on each LLM or embedding span and applying the provider's published pricing rates, covering more than 800 models across OpenAI, Anthropic, Gemini, Hugging Face and models served through OpenRouter. The unit stored is nanodollars.

Three failure modes in that estimate are documented, and each of them quietly understates or breaks your model-spend reporting:

Unsupported model provider. If the model_provider on the span is not in the supported list, Datadog has no rate card to apply and the trace shows COST UNAVAILABLE. The fix is to supply cost values manually through the SDK or API.

Unsupported model name. If the provider is supported but the model_name does not match the pricing catalogue, usually because it is abbreviated or uses an internal alias, the same thing happens. Teams that route through a gateway and rewrite model names hit this constantly.

Prompt-caching blindness. If a span carries only aggregate input_tokens and output_tokens without cache_read_input_tokens, cache_write_input_tokens and non_cached_input_tokens, Datadog applies the standard input rate to every input token. Because cache reads and cache writes bill at different rates from fresh input, the cost figure is wrong, and it is wrong in the direction that makes caching look useless. Datadog's guidance is explicit: provide the full cache token breakdown whenever cache usage information is available.

If your caching work is not showing up as savings in the Cost view, check the token breakdown on the span before you conclude the caching is not working.

Six levers that actually move the number

1. Sample at the SDK, not in the app

Trace sampling is the only control that reduces ingested volume before Datadog counts it. It ships in the Python SDK from ddtrace 4.12.0 and the Node.js SDK from dd-trace 5.110.0. The Java SDK does not support it.

DD_LLMOBS_SAMPLE_RATE=0.5 ddtrace-run <YOUR_APP_STARTUP_COMMAND>

Or in code, where it takes precedence over the environment variable:

from ddtrace.llmobs import LLMObs

LLMObs.enable(
  ml_app="<YOUR_ML_APP_NAME>",
  sample_rate=0.5,
)

The Node.js equivalent passes sampleRate under llmobs to init(). The value is a float between 0.0 and 1.0, defaulting to 1.0, and out-of-range values are ignored.

Two details decide whether this is safe for you. The sampling decision is made on the root span and applied to every child span of that root, including spans created in downstream services through distributed tracing, so you never end up with half a trace. And it happens client-side, independent of in-app automation rules and APM trace sampling, which apply only after Datadog has already ingested the data. Sampling at the SDK is the only one of the three that reduces what you are billed for.

The obvious objection is that you lose traces. Langfuse makes the counter-argument well in its own cost guide: dynamic sampling based on error level is not feasible for LLM applications, "since you only know if a trace is interesting after completion (through user feedback, LLM-as-a-judge evaluation, etc.)," and retaining everything supports later model-distillation work. Both things are true. The resolution most teams land on is a high sample rate on the newest or most business-critical ml_app and an aggressive one on the mature, high-volume, low-surprise paths.

2. Cut model calls, not steps

Because only LLM spans bill, the cheapest optimisation is also the one that improves latency: collapse redundant model calls. A separate model call to classify intent, another to rewrite the query and a third to answer is three billable spans; a single structured-output call that returns intent, rewritten query and answer is one. The tool calls, retrievals and preprocessing you leave in place cost nothing.

The real cost is usually the extra model turn, not the extra tool.

3. Sample your evaluations too

Datadog is unusually clear here: "There is no separate product fee for offline or online evaluations. Every plan includes the full evaluation workflow. If an eval run makes LLM calls, those calls count as LLM spans."

An LLM-as-a-judge evaluator running on 100% of production traffic therefore doubles your billable span count, and a three-criterion judge quadruples it. Judge coverage is a dial, not a switch. Decide the sample rate deliberately, publish it alongside the eval results so nobody reads a 5% sample as a full census, and treat the sampled evaluations as a monitoring signal rather than an audit. Our note on silent failures in agent evals covers how to keep a sampled judge honest.

4. Default to 15 days, extend by exception

Free and Pro on-demand both carry 15-day retention for traces, spans and experiment data. Retention add-ons extend traces and spans to 30, 60 or 90 days, and experiments to 6, 9 or 12 months, and are billed per 10,000 LLM spans, which means the add-on cost scales with the same meter as the base product. On an M2M or annual contract, trace and span data still sits at 15 days while experiment results get 90.

The practical shape is to keep 15 days everywhere, then extend retention only for the one or two ml_app values tied to a regulatory or contractual review cycle. Datasets already hold 3 years and are versioned, so if what you actually need is the ability to rerun an experiment against the same baseline later, promote the traces you care about into a dataset instead of paying to retain everything.

5. Make the spend attributable before it grows

Cost and token metrics ship with model_name, model_provider and ml_app tags. To break spend down by anything else, tag your spans with the attribute and pass those keys to the cost_tags parameter in Python or costTags in Node.js, and they propagate onto the ml_obs.span.* cost and token metrics. From there they work in dashboards, monitors and notebooks like any other tag, so you can put a per-team monitor on ml_obs.span.llm.total.cost grouped by team.

One constraint: only bounded values. Team, customer tier, feature and environment are fine. User IDs and request IDs are not, and Datadog warns that unbounded or high-cardinality values may be truncated or omitted from the resulting metrics.

The same tags give you a cache-effectiveness view. Tagging by prompt_version and comparing ml_obs.span.llm.input.cache_read.tokens against ml_obs.span.llm.input.cache_write.tokens shows which prompts populate the cache but never reuse it, the usual signature of a prefix that changes on every call. That is a model-spend saving, not an observability saving, and it is normally the larger of the two. Our AI cost attribution playbook goes further on getting a name attached to each line.

6. Price the alternatives on your own span shape

Two open alternatives publish enough detail to model against.

Langfuse bills on ingested units, defined as Units = Count of Traces + Count of Observations + Count of Scores. That is a materially different meter: every observation counts, not just model calls, and any trace, observation or score created by Langfuse features such as LLM-as-a-Judge, annotation queues or experiments counts as a billable unit too. Langfuse's own worked example shows 20,070 traces plus 119,500 observations plus 561 scores adding to 140,131 units a month. The Hobby plan is free with 50,000 units a month, 30 days of data access and 2 users. Core is $29 a month with 100,000 units included, unlimited users, 90 days of data access and additional units at $8 per 100,000, falling with volume. Pro is $199 a month and Enterprise $2,499. Self-hosting the MIT-licensed open-source build carries no usage-based billing at all, which is the option that changes the arithmetic most for a high-volume, low-margin product.

LangSmith bills seats plus usage. The Developer plan is $0 per seat with 1 seat and 5,000 base traces a month; Plus is $39 per seat with unlimited seats and 10,000 base traces a month; both then move to pay-as-you-go. Usage is normalised into two units with published rates: 1 LangChain Compute Unit is $1.50 and 1 LangChain Storage Unit is $1.00. Base traces retain for 14 days and extended traces for 400 days, and you can upgrade a base trace to an extended one for an additional fee. Worth noting for anyone comparing full-stack costs: LangSmith Engine runs every 6 hours and consumes roughly 5 to 30 LCUs per run depending on trace volume and application complexity, which at $1.50 per LCU is a line item of its own.

Platform	Billing unit	Entry price	Free allowance	Default retention
Datadog Agent Observability	LLM spans only	$160/month (Pro)	40,000 LLM spans/month	15 days
Langfuse Cloud	Traces + observations + scores	$29/month (Core)	50,000 units/month (Hobby)	30 days (Hobby), 90 days (Core)
Langfuse self-hosted (OSS)	None, MIT licence	Infrastructure only	Unlimited	Your storage
LangSmith Developer	Seats + LCU/LSU	$0/seat, 1 seat	5,000 base traces/month	14 days (base)
LangSmith Plus	Seats + LCU/LSU	$39/seat/month	10,000 base traces/month	14 days (base)

The comparison is not "which is cheaper." It is "which meter matches my shape." A deep agent with 40 observations and 2 model calls per request is cheap on Datadog and expensive on a per-observation meter. A shallow, very high-volume classifier is the reverse. Model both against a week of real traffic, not against a pricing page.

Instrumenting without committing

The Free tier is generous enough to answer the pricing question empirically before you commit to anything. Instrument staging, run a representative week, and read the actual LLM span count off the Cost view.

DD_SITE=<SITE> \
DD_LLMOBS_ENABLED=1 \
DD_LLMOBS_ML_APP=<APPLICATION_NAME> \
DD_API_KEY=<API_KEY> \
ddtrace-run <your application command>

Node.js uses NODE_OPTIONS="--import dd-trace/initialize.mjs" with the same environment variables, and Java attaches dd-java-agent.jar with -Ddd.llmobs.enabled=true. Applications in other languages submit spans through the HTTP API or instrument via OpenTelemetry.

One deployment constraint that catches regulated buyers late: Datadog's documentation states that the product is not supported on the app.ddog-gov.com and us2.ddog-gov.com sites. Check your site before you plan a rollout.

Sensitive Data Scanner is included rather than sold separately, with an allocation of 1 GB of scanning for every 10,000 LLM requests, and it scans, identifies and redacts sensitive information in LLM inputs and outputs. For teams whose blocker is that prompts contain personal data, that is a real part of the value, and it removes a line item that would otherwise be priced on its own.

India-specific considerations

Three points change the calculation for teams building from India.

Datadog's pricing page states plainly that pricing varies by region, so the $160 entry figure is a starting point for a quote rather than a global list price. Get the number for your billing region before you build a business case on it.

Prompts and completions are personal data more often than teams assume, and under the Digital Personal Data Protection Act 2023 an observability platform that stores raw inputs and outputs is processing that data on your behalf. Two controls follow: the included Sensitive Data Scanner redaction, and a deliberate retention setting rather than the longest one available. Extending retention to 90 days because the add-on was cheap is a decision to hold personal data for 90 days.

Rupee-denominated budgets and dollar-denominated observability meters drift against each other, and an agent's model-call count usually grows faster than its request count as teams add reflection and tool use. Forecast on spans, not on requests. Our guide to cutting cloud spend for Indian teams covers the wider budgeting picture this sits inside.

Where this fits in the wider FinOps shift

The pressure to answer this question at all is new. The FinOps Foundation's sixth annual State of FinOps survey, released 19 February 2026 with 1,192 respondents from organisations representing more than $83 billion in annual cloud spend, found 98% of practitioners now manage AI spend, up from 31% two years earlier. Alongside that, 90% are asked to manage SaaS, up from 65% the year before, and 78% of teams now report to the CTO or CIO.

"FinOps has definitively expanded to a broad array of technology value management, and the FinOps Foundation has followed to reflect the full scope of what practitioners are doing in the industry today, what they influence, and how they use FinOps to drive greater value from technology investments," said J.R. Storment, Executive Director of the FinOps Foundation. "As companies pursue transformation via AI, with the resulting increases in AI costs, FinOps practices will be critical to enable c-level decisions about multi-year strategic technology investments across infrastructure types."

The survey also found pre-deployment architecture guidance to be a top desired tooling capability, which is exactly what the span-kind table above is. Knowing that a second model turn doubles your observability bill is an architecture input, not a procurement one, and it is cheapest to act on before the code ships. If you are also metering the AI feature you are selling, our note on usage-based billing and margin covers the other side of the same ledger.

FAQ

What exactly does Datadog charge for in LLM Observability?

Datadog meters and bills only on the count of LLM spans, which are the calls your application makes to a model provider. Tool spans, embedding spans, retrieval spans and agent spans are not billed. That means adding retrieval steps or tool calls to an agent does not increase what Datadog charges you.

How much is the Free plan and what does it include?

The Free plan costs $0 per month and covers up to 40,000 LLM spans, with 15-day retention, unlimited context and evals, and full feature access. It is enough to instrument a staging environment for a representative week and measure your real span count before committing to a paid plan or a contract.

What does Pro cost and what happens above the included volume?

Pro starts at $160 per month and includes 100,000 LLM spans with 15-day retention. Additional on-demand usage is billed after the first 100,000 spans, but Datadog does not publish that per-span rate on its pricing page. Ask your account team for the figure in writing before modelling any overage.

Do evaluations cost extra?

There is no separate product fee for offline or online evaluations, and every plan includes the full evaluation workflow. However, if an eval run makes model calls, those calls count as LLM spans and bill like any other. An LLM-as-a-judge evaluator running on all production traffic therefore roughly doubles your billable span count.

How do I reduce ingested volume before Datadog counts it?

Use SDK trace sampling through DD_LLMOBS_SAMPLE_RATE or the in-code sample_rate parameter, available in Python from ddtrace 4.12.0 and Node.js from dd-trace 5.110.0. The decision is made on the root span and applied to all child spans. In-app automation rules and APM sampling apply only after ingestion.

Why does my trace show COST UNAVAILABLE or PARTIAL COST?

Each LLM span is priced independently, and the warning appears when one or more spans lack a cost estimate. The three documented causes are an unsupported model provider, a model name that does not match the provider's pricing catalogue, and missing token counts on the span. You can supply cost values manually through the SDK or API.

How does Datadog's meter compare with Langfuse and LangSmith?

Langfuse bills ingested units, calculated as traces plus observations plus scores, with 50,000 free per month on Hobby and $8 per additional 100,000 on Core. LangSmith bills seats plus usage, at $0 per seat with 5,000 base traces or $39 per seat with 10,000. Model all three against real traffic.

Is LLM Observability available on every Datadog site?

No. Datadog's documentation states the product is not supported for users on the app.ddog-gov.com and us2.ddog-gov.com sites. If your organisation is on one of those sites, confirm availability before planning a rollout, because the constraint is a deployment blocker rather than a configuration option you can change.

How eCorpIT can help

eCorpIT builds and instruments production LLM applications for teams in India and abroad, and the span-shape work described above is part of how we scope them. Our senior engineering teams model the billable-span curve against your real traffic before you commit to a platform, wire up sampling and cost attribution so a name is attached to every line, and design applications aligned with DPDP requirements around prompt and completion retention. We are CMMI Level 5, MSME Certified and ISO 27001:2022 certified. If your LLM observability bill is growing faster than your traffic, talk to us and we will look at the span shape with you. Our AI evals and observability service and AI gateway and model routing service cover the adjacent work.

References

1. Datadog LLM Observability product and pricing page — plan tiers, included span volumes, retention add-ons and the billing FAQ.
2. Agent Observability: Cost documentation — automatic and manual cost monitoring, cache token breakdown, cost tags, troubleshooting.
3. Agent Observability Terms and Concepts — the span-kind taxonomy and which kinds can be root spans.
4. Agent Observability SDK Reference — trace sampling, SDK version requirements and configuration precedence.
5. Agent Observability documentation index — setup, evaluations and site support notes.
6. Agent Observability Metrics — the ml_obs.span.* cost and token metrics.
7. Datadog APM ingestion controls — post-ingestion sampling, for contrast with client-side sampling.
8. Langfuse pricing — cloud tiers and the pricing calculator.
9. Langfuse billable units — the units formula and a worked monthly example.
10. How do I cut my Langfuse Cloud bill? — reducing observations per trace and sampling trade-offs.
11. LangSmith plans and pricing — seat prices, base trace allowances, LCU and LSU rates, Engine metering.
12. LangSmith cost tracking documentation — how trace costs are surfaced.
13. State of FinOps 2026 survey press release, The Linux Foundation, 19 February 2026 — the 98% AI-spend figure, respondent counts and the Storment quote.

Last updated: 3 August 2026.