LangGraph Tracing: How to Track Token Usage in LangGraph
How to use LangGraph tracing to track token usage by graph node, run, customer, model, status, retries, and usage metadata before turning traces into cost records.
Track token usage in LangGraph by attaching callback instrumentation to graph runs, preserving provider and model usage metadata, and adding run ID, parent run ID, langgraph_node or step name, customer ID, latency, status, and retry context before the trace is rolled up into cost records.
- - How do I track token usage in LangGraph?
- - What should LangGraph tracing capture for AI agents?
- - How do I attribute LangGraph usage to customers and graph nodes?
- - How do LangGraph traces become cost tracking records?
- - Do I need LangSmith, MLflow, or Pylva for LangGraph tracing?
Direct Answer: How To Track Token Usage In LangGraph
LangGraph tracing starts at the graph run. Attach a callback handler, preserve usage metadata from each supported model call, and pass stable business context such as customer ID, workspace ID, workflow name, and graph node name when the graph is invoked.
The minimum useful record includes provider, model, input tokens when available, output tokens when available, total tokens, latency, status, run ID, parent run ID, retry count, environment, customer ID, and step attribution. For LangGraph, that step attribution is often a graph node label such as langgraph_node.
That trace is the input to LangGraph cost tracking. Tracing explains what happened inside the run. Cost tracking applies pricing, customer attribution, budget state, and billing rules to the usage facts.
- Instrument the LangGraph or LangChain callback path where model calls happen.
- Attach customer and workspace identifiers at graph invocation time, not after the invoice arrives.
- Use graph node labels for step-level attribution so planner, retrieval, tool, evaluator, and response nodes can be compared.
- Treat missing model, token, customer, or status fields as data-quality issues before usage reaches pricing or billing.
What Is LangGraph Tracing?
LangGraph documentation describes LangGraph as infrastructure for long-running, stateful workflows and agents. In practice, a LangGraph app is usually a graph of nodes, edges, state updates, tool calls, model calls, retries, and optional human review paths.
LangGraph tracing is the record of how that workflow actually executed. A good trace preserves the path through the graph, the timing of each step, the status of each operation, and the usage created by each model or tool call.
The LangGraph graph API explains the core building blocks: state, nodes, and edges. Tracing is useful because those building blocks can branch, loop, pause, stream, or resume differently for each customer request.
Trace the graph, not only the provider call
A provider dashboard can show aggregate model usage. It usually cannot show which customer, graph node, workflow version, branch, retry path, or plan tier created that usage.
LangGraph traces should therefore preserve both provider facts and product facts. Provider facts explain the model call. Product facts explain why the call happened and who should own the cost.
Tracing is not the same as billing
Keep application code focused on reporting usage facts. The architecture behind report usage, not cost applies here: pricing tables, credits, plan limits, and billing decisions belong outside the hot path.
What A LangGraph Trace Should Preserve
The schema should be small enough to attach to every graph run and explicit enough to support engineering, product, finance, and customer success questions later. The most useful fields connect a model call to the graph path and the customer that caused it.
| Field group | Examples | Why it matters |
|---|---|---|
| Model usage | Provider, model, input tokens, output tokens, total tokens, cached tokens where available. | Turns raw LangGraph model calls into usage facts that can be priced and optimized. |
| Graph context | Run ID, parent run ID, trace ID, workflow name, workflow version, langgraph_node, step name. | Shows which node, branch, retry, or graph version created the usage. |
| Customer context | Customer ID, workspace ID, account ID, plan tier, environment, feature label. | Connects technical usage to margin, support, budget, and billing workflows. |
| Runtime status | Latency, success, handled error, unhandled error, timeout, retry count, fallback path. | Explains why a run became expensive, slow, incomplete, or duplicated. |
| Tool usage | Search requests, vector lookups, speech seconds, enrichment calls, workflow executions. | Captures non-LLM costs that can be material inside agent workflows. |
Python Callback Pattern For LangGraph Token Usage
For Python LangGraph and LangChain graphs, attach the Pylva callback handler and pass customer metadata when the graph is invoked. The callback observes usage metadata and keeps the graph runtime in control.
Use the Pylva LangGraph SDK documentation for current package installation details and callback options.
import os
from pylva.langchain import PylvaCallbackHandler
handler = PylvaCallbackHandler(api_key=os.environ["PYLVA_API_KEY"])
result = graph.invoke(
{"messages": [("user", "Summarize this account")]},
config={
"callbacks": [handler],
"metadata": {
"pylva_customer_id": "cust_acme",
"langgraph_node": "account_summary",
},
},
)TypeScript Callback Pattern For LangGraph Token Usage
For LangGraph.js, import the LangGraph callback entrypoint rather than wrapping the same model call twice. This keeps callback attribution narrow and reduces the risk of duplicate usage records.
The same metadata pattern applies: pass a stable customer identifier and graph node context when the workflow runs.
import { PylvaCallbackHandler } from "@pylva/sdk/langgraph";
const handler = new PylvaCallbackHandler({
apiKey: process.env.PYLVA_API_KEY!,
});
await graph.invoke(input, {
callbacks: [handler],
metadata: {
pylva_customer_id: "cust_acme",
langgraph_node: "account_summary",
},
});Track Usage By Customer, Graph Node, And Run
The useful LangGraph tracing question is rarely only "how many tokens did we use?" Production teams usually need to know which customer created the usage, which graph node created it, and whether that pattern repeats across accounts.
This is where per-customer AI cost attribution matters. A graph trace without customer context is useful for debugging, but it is weak for margins, usage limits, support escalations, and customer-facing billing.
Customer attribution belongs at invocation time
Set customer or workspace context before the graph starts. Trying to join customer identity after the trace is emitted is fragile, especially for background agents, scheduled workflows, retries, and resumed runs.
Use stable opaque identifiers such as customer ID or workspace ID. Do not send emails, phone numbers, raw names, prompts, completions, tool inputs, or tool outputs into cost telemetry.
Graph node attribution reveals the expensive step
Planner, retrieval, tool, evaluator, and final response nodes can have very different cost profiles. Node attribution lets teams optimize a single expensive path instead of weakening the full agent workflow.
For the broader workflow view, see LLM orchestration monitoring.
Handle Streaming, Retries, And Missing Usage Metadata
The LangGraph streaming docs cover how graph output can be streamed during execution. Streaming is good for product experience, but it makes trace completeness more important because usage metadata can arrive after partial output.
Retries and resumed runs can also create duplicate or partial-looking usage if the trace does not preserve run ID, parent run ID, status, and retry count. Failed calls may still consume tokens, and successful fallback calls may add more cost after the failed attempt.
- Record status for every supported model call, including handled errors and timeouts.
- Preserve retry count or fallback context so cost spikes can be separated from normal traffic growth.
- Treat missing customer ID, missing graph node, missing model, or missing token metadata as a validation issue.
- Keep pricing and budget decisions downstream so incomplete traces can be quarantined before they reach billing.
Where LangSmith, MLflow, And Pylva Fit
LangGraph teams often use more than one tool. That is normal. The right question is which workflow each tool should own.
MLflow LangGraph tracing is a tracing and experiment-tracking path for LangGraph workflows. LangSmith is commonly used by LangChain teams for tracing, debugging, evaluation, and workflow inspection. Pylva is the cost and usage layer for customer attribution, budget decisions, margin review, and billing-ready records.
| Tool category | Best fit | What to hand off to Pylva |
|---|---|---|
| LangGraph runtime | Stateful graph execution, nodes, edges, persistence, streaming, and control flow. | Usage metadata, customer context, graph node labels, status, and run relationships. |
| Tracing and evaluation tools | Trace inspection, debugging, evaluations, experiments, and developer workflows. | Customer-attributed usage records that need pricing, budgets, and billing decisions. |
| Pylva | Cost-shaped telemetry, per-customer attribution, budget workflows, and billing-ready usage records. | Keep prompts, completions, raw messages, tool inputs, and tool outputs in the systems that own them. |
From LangGraph Tracing To LangGraph Cost Tracking
LangGraph tracing becomes LangGraph cost tracking when usage facts are priced, attributed to customers, checked for completeness, and connected to operational workflows.
The bottom-funnel page for that job is LangGraph cost tracking for AI agent workflows. Use it when the question moves from tracing token usage to protecting margin, applying budgets, reviewing customer accounts, or preparing billing records.
Pylva fits beside the broader AI cost observability platform and AI agent cost management workflows. The same records can support dashboards, alerts, budget enforcement, and usage billing.
- Use LLM cost tracking for AI agents to normalize model usage across providers and agent steps.
- Use non-LLM cost tracking for search, vector database, speech, enrichment, and workflow-run costs.
- Use pre-call budget enforcement once the runtime has enough trusted usage data to warn, route, throttle, review, or block safely.
- Use usage-based billing for AI agents when customer-attributed records need to feed pricing and invoice workflows.
Common LangGraph Tracing Mistakes
Most tracing mistakes are not caused by LangGraph itself. They happen when teams lose business context, over-collect sensitive content, or treat trace visibility as if it automatically solved cost control.
- Only tracking total tokens without preserving graph node and customer context.
- Relying on provider dashboards for multi-tenant agent workflows that share one provider account.
- Mixing hard-coded dollar calculations into application code instead of reporting usage facts.
- Ignoring non-LLM tool costs such as search, vector lookups, speech, workflow runners, or enrichment APIs.
- Sending prompts, completions, raw messages, tool inputs, tool outputs, emails, or phone numbers into cost telemetry.
- Assuming tracing and cost infrastructure are interchangeable. For a category comparison, see Pylva vs LangSmith.
Launch Checklist For Production LangGraph Tracing
Use this checklist before relying on LangGraph trace data for customer reports, cost alerts, budgets, or billing handoff.
- Pick one production graph, not the entire application, and define the customer, workflow, run, node, status, and token fields it must emit.
- Attach callback instrumentation and verify that supported model calls produce usage records.
- Pass stable customer or workspace identifiers when invoking the graph.
- Confirm that graph node labels appear for planner, retrieval, tool, evaluator, and response steps where those labels are available.
- Validate streaming and retry paths so partial, failed, retried, and fallback calls have clear status records.
- Add non-LLM cost sources only when the tool has a real billable or margin-relevant unit.
- Review the data with engineering, product, finance, and customer success before connecting it to budgets or billing.
Next Step For Production LangGraph Agents
If you only need developer debugging, start with your LangGraph traces and evaluation tooling. If you need customer-level cost, margin review, budget decisions, or usage billing, move from tracing into LangGraph cost tracking.
The practical first milestone is one LangGraph workflow where every supported model call carries model usage, graph node context, customer context, runtime status, and enough metadata to make cost records trustworthy.
Frequently Asked Questions
How do I get token usage from LangGraph?
Attach a LangGraph or LangChain callback handler, preserve usage metadata from supported model calls, and pass customer plus graph node metadata when the graph is invoked.
Can I track LangGraph token usage by graph node?
Yes. Use graph node labels such as langgraph_node or a stable step name so planner, retrieval, tool, evaluator, and response nodes can be compared across runs.
Can I track LangGraph usage by customer?
Yes. Pass a stable customer ID or workspace ID at graph invocation time. Avoid raw emails, phone numbers, prompts, completions, tool inputs, and tool outputs in cost telemetry.
Is LangGraph tracing enough for billing?
No. Tracing is the execution record. Billing needs validated usage records, server-side pricing, plan context, credits, review workflows, and billing handoff, which are covered in usage-based billing for AI agents.
Do I need LangSmith, MLflow, or Pylva for LangGraph tracing?
Use tracing and evaluation tools for developer inspection and debugging. Use Pylva when the same LangGraph usage needs customer attribution, cost records, budget decisions, and billing-ready outputs.
Does Pylva store LangGraph prompts or completions?
No. Pylva is designed for cost-shaped telemetry such as usage metadata, model, provider, status, latency, customer ID, run context, and step attribution. It should not receive prompts, completions, raw messages, tool inputs, or tool outputs.
What is the difference between LangGraph tracing and LangGraph cost tracking?
LangGraph tracing records the execution path and usage facts. LangGraph cost tracking applies customer attribution, server-side pricing, budgets, margin review, and billing workflows to those facts.
Related reading
LangGraph Cost Tracking for AI Agent Workflows
The buyer page for AI agent builders that need LangGraph usage records tied to customers, graph nodes, cost controls, and billing workflows.
LLM Orchestration Monitoring: Track Agent Workflows, Tool Calls, and Cost Across Steps
Learn how to monitor LLM orchestration across agent runs, workflow steps, model calls, tool calls, retries, fallbacks, latency, token usage, non-LLM costs, and customer-level attribution.
LLM Cost Tracking For AI Agents
How to implement LLM cost tracking for AI agents by customer, workflow, step, model, provider, retry, and request before the provider invoice arrives.
Per-Customer AI Cost Attribution: See AI Cost By Customer, Plan, And Workflow
How to attribute AI agent cost by customer, plan, workflow, model, retry, tool call, and non-LLM usage before margins drift.
Non-LLM Cost Tracking For AI Agents
How to track search, speech, vector database, workflow, and other non-LLM API costs next to model spend.
Pre-Call Budget Enforcement For AI Agents
How AI agent teams check customer and workflow budgets before supported provider calls, then warn, route, or hard-stop spend safely.