LangSmith Pricing vs LangGraph Runtime Cost: What You Actually Pay
Compare current LangSmith pricing with the model, tool, retry, deployment, and infrastructure costs created by production LangGraph agents.
LangGraph is an MIT-licensed open-source framework, while LangSmith charges separately for observability, traces, managed deployment, and other enabled services. Your complete production budget must also include model tokens, paid tools, vector operations, retries, storage, and cloud infrastructure. Those runtime costs remain separate from LangSmith plan pricing.
- - How much does LangSmith cost?
- - Is LangGraph free for production use?
- - What is the difference between LangSmith pricing and LangGraph runtime cost?
- - How do I estimate the monthly cost of a LangGraph agent?
- - How do I track LangGraph cost by customer and graph node?
LangSmith Pricing and LangGraph Runtime Cost: Quick Answer
LangGraph is an open-source, MIT-licensed framework. The library has no license fee, but running it still creates model, tool, database, and infrastructure costs. The official LangGraph repository publishes the source code and license.
LangChain's current LangSmith pricing lists Developer at $0 for one seat with 5,000 base traces per month, Plus at $39 per seat per month with 10,000 base traces and unlimited additional seats, and Enterprise with custom pricing. Managed LangGraph deployment is sold as LangSmith Deployment: Plus includes one free development-sized deployment, while additional deployments are usage-priced. Runtime costs from LLM calls, tools, vector queries, retries, and infrastructure are separate; neither LangGraph pricing nor LangSmith pricing absorbs those provider bills.
The free Developer plan is a free tier for one user and is suitable for personal projects; it does not include LangSmith Deployment. The Plus plan adds team collaboration, managed deployment, and usage-based billing. Model-provider, tool, vector database, and cloud costs remain separate. Pylva tracks that LLM usage and tool execution by customer, run, and graph node, complementing LangSmith as an LLM observability platform without duplicating it.
LangGraph, LangSmith Deployment, and Runtime Cost: What's the Difference?
Four cost layers can appear when you run agents in production: the open-source LangGraph library, managed LangSmith Deployment, LangSmith observability and evaluation, and the underlying model, tool, storage, and cloud usage. Each is controlled and billed differently.
LangGraph Open Source
LangGraph is an open-source framework and low-level LLM framework for stateful agents, complex workflows, and fine-grained control over agent actions and state management. The open-source library can run on your own servers or in a local development environment without a license fee. LangGraph offers orchestration primitives; you still pay providers for compute, models, databases, and tools.
LangSmith Deployment
The LangChain team now presents the managed LangGraph runtime as LangSmith Deployment. Older sources may call it LangGraph Platform or the agent engineering platform. It runs a managed LangGraph server with persistence, APIs, streaming, scheduling, and production features. The Plus plan includes one free deployment sized for development. The Enterprise plan adds custom deployment options, including cloud, hybrid, and self-hosted deployments; teams that need to self-host LangSmith should contact sales.
LangSmith Observability and Evaluation
LangSmith is an LLM observability and evaluation platform for tracing, experiment tracking, monitoring, datasets, and team collaboration. Its pricing tiers combine developer seats with trace volume. Those charges are independent from model-provider usage, and LangSmith is not a customer billing engine or per-customer margin ledger.
Model, Tool, and Infrastructure Runtime Cost
Runtime cost comes from what agent workflows execute: LLM input and output tokens, paid tools and APIs, vector database operations, storage, retries, branching paths, and cloud infrastructure. Workflow complexity, multi-agent systems, and repeated agent actions change the true cost. LangSmith plan or deployment charges do not absorb those provider invoices.
Platform Pricing vs Runtime Cost: What You're Actually Paying For
The table below separates each cost layer, the unit being paid for, and the decisions your team controls. Published service rates can change, so verify them on the official pricing page before approving a budget.
| Cost Area | What It Pays For | Who Controls It | Why It Matters |
|---|---|---|---|
| LangSmith Deployment (Plus / Enterprise) | Managed agent runtime, persistence, APIs, scaling, deployment runs, and uptime. Plus includes one free development-sized deployment; additional deployment runs are $0.005 each, with production uptime at $0.0036 per minute. | LangChain sets service rates; you control deployment count, development versus production sizing, run volume, and seats. | Affects managed hosting cost, operational workload, and deployment choices. |
| LangSmith (Tracing / Observability) | Trace ingestion, retention, dashboards, evaluation datasets, and collaboration. Base traces cost $2.50 per 1,000 with 14-day retention; extended traces cost $5.00 per 1,000 with 400-day retention. | You choose plan, trace volume, retention period, and number of seats. | Required for debugging, monitoring, and improving agent quality. Trace-overage decisions directly affect monthly spend. |
| LLM / Model Usage | Token cost per call, including input tokens, output tokens, and provider fees. | You choose models, prompt length, and call count. Graph design determines retries and branching. | A variable cost driver tied directly to graph behavior, margin, latency, and quality. |
| Tool / API Calls | External services such as search, enrichment, retrieval, and CRM lookups. | You decide which tools run, how many run per request, and their concurrency and fallback behavior. | Parallel, fallback, and retry paths can repeat paid work across tool nodes. |
| Storage / Vector DB / Persistence | Vector stores, embedding generation, memory history, and checkpoint databases. | You determine retrieval patterns, caching strategy, and embedding model. | Impacts response latency and recurring cost for RAG and memory-based agent workflows. |
| Infrastructure / Hosting | Cloud compute, containers, networking, and managed services, whether self-hosted or cloud-managed. | Cloud-provider rates and your architecture choices. | Architecture and scaling choices change hosting cost even at the same traffic level. |
| Pylva Cost Telemetry | Cost-shaped usage telemetry, server-side pricing, and attribution by customer, run, and graph node. | You attach safe identifiers, enable the supported callback path, and configure pricing. | Supports margin and workflow analysis without sending prompts, completions, or tool arguments. |
Is LangGraph Free?
Yes and no. The LangGraph framework is an MIT-licensed open-source library, so you can build and run LangGraph agents on your own servers without a license fee. Production AI applications still generate model, tool, database, and hosting costs. The free plan covers Developer observability for one user, not managed deployment. Plus and Enterprise add LangSmith Deployment and broader hosting or support options, with separate run and uptime charges for additional or production deployments.
A human-in-the-loop interrupt or human review step does not itself create model spend. Under LangChain's published deployment billing definition, resuming an interrupted graph creates a separate deployment run; any model or tool work executed after resume adds normal runtime usage. The clean answer is that the framework is free, while production usage is not.
Where LangSmith Pricing Fits into the Picture
LangSmith is a tracing, evaluation, and agent observability platform. It is not a runtime billing engine, a revenue-attribution layer, or a replacement for per-customer cost infrastructure. Its job is to help you debug, monitor, and improve your LangGraph and LangChain agents.
LangSmith pricing has three tiers. Developer includes one free seat and 5,000 base traces per month with 14-day retention. Plus costs $39 per seat per month, includes 10,000 base traces, unlimited additional seats, and one free development-sized deployment. Enterprise uses custom pricing for teams that need advanced hosting, security, administration, or support; the official page lists cloud, hybrid, and self-hosted options, custom single sign-on and role-based access control, support commitments, annual invoicing, and custom terms. LangSmith also offers a startup program for eligible early-stage companies, while the LangSmith SDK provides programmatic access to traces and evaluations.
Usage-based pricing applies after included trace volume. Base traces cost $2.50 per 1,000 with 14-day retention; extended traces cost $5.00 per 1,000 with 400-day retention. A single trace represents one application execution and can contain many child runs, including LLM and tool steps. LangSmith surfaces token counts, latency, and trace-level paths, but it is not a full per-customer billing, margin, or revenue-attribution layer. Deployment, trace, model, tool, and infrastructure charges remain separate.
For a detailed breakdown of how LangSmith and Pylva serve complementary roles—LangSmith for observability and evaluation, Pylva for cost-shaped telemetry and pricing logic—see Pylva vs LangSmith.
Other LangSmith Usage Charges to Include
Seats and traces are not the only LangSmith charges. A detailed breakdown of key features also includes Deployment, Fleet, Engine, and Sandboxes.
LangSmith Deployment: the Plus plan includes one free development deployment with unlimited runs. For additional deployments, runs are $0.005 each; published uptime is $0.0007 per minute for development and $0.0036 per minute for production deployments. For high-volume deployments, forecast each meter separately from model and tool usage.
LangSmith Fleet: Developer includes 50 Fleet runs per month and Plus includes 500; additional Plus runs are $0.05 each. Every Fleet run is traced, while its model is billed by the provider. LangSmith Engine: Engine is metered in LangChain Compute Units at $1.50 per LCU, including the compute, infrastructure, and underlying model usage needed for Engine analysis. That inclusion does not cover model calls executed by your own LangGraph application.
LangSmith Sandboxes: the Plus plan lists CPU at $0.0576 per vCPU-hour, memory at $0.0185 per GiB-hour, and storage at $0.000123 per GiB-hour, billed per second. These are isolated code-execution resources, not application hosting. Treat all rates as current public pricing context, not a Pylva performance claim, and recheck the official page before publishing a forecast.
What Production LangGraph Agents Actually Cost
Published seat, trace, deployment-run, and uptime rates are usually easier to forecast than runtime usage. Model choice, context size, graph paths, retries, tools, and traffic make execution cost the more variable layer.
The main runtime cost drivers for agent-based systems include:
- Model calls: Provider and model selection changes the rate paid for each input and output token. Every node that invokes a model adds usage.
- Input and output tokens: Retrieval context, conversation history, and verbose outputs increase tokens per run.
- Branches and loops: Conditional edges, parallel work, and fallback paths add cost only when they execute model or paid tool work.
- Retries: Each additional attempt adds another model or tool execution. Track retry count and status instead of estimating from successful runs alone.
- Tools and APIs: Search, enrichment, code execution, speech, and proprietary APIs may charge per call, unit, or duration.
- Memory and retrieval: Vector queries, embeddings, checkpoint databases, and storage can create separate provider charges.
- Multi-agent orchestration: A supervisor and several specialist agents can create multiple model and tool calls from one user request. Measure the calls that actually ran.
Human-in-the-loop resumes and multi-agent routing should be measured at the deployment-run, graph-node, and actual model or tool-call levels. A per-request average can hide which path created the cost.
Customer request
Start with a stable customer or workspace identifier so downstream usage remains attributable.
LangGraph path
Preserve the run, graph node, branch, and retry context that explains what executed.
Models and tools
Record supported token usage and opt-in billable tool units instead of estimating from the final response.
Cost record
Resolve pricing server-side, then group cost by customer, workflow, model, and tool.
How to Estimate LangGraph Runtime Cost Beyond LangGraph Pricing
This is a practical estimation guide for engineers, product managers, and finance teams trying to budget AI applications built on LangGraph.
Model Usage
Estimate monthly requests, average model calls per graph run, average input and output tokens per call, and the current provider rate for each model. Keep input and output rates separate. A smaller model may be cost-effective when it still meets the workflow's quality and latency requirements.
Tool and API Usage
Estimate outbound API calls, database operations, vector reads and writes, and other priced tools. Record the billable unit for each source, such as calls, rows, characters, seconds, or executions.
Retries and Workflow Paths
Measure which branches executed, how many retries occurred, and whether a fallback repeated model or tool work. Use production retry and path frequency instead of a fixed multiplier.
Deployment and Hosting
Include LangSmith Deployment runs and uptime, trace overages, Fleet or other LangSmith service usage when enabled, and cloud infrastructure. Self-hosted and managed deployments have different cost owners, but both recur.
The dedicated LangGraph implementation guides are collected below so this page can stay focused on pricing and budgeting.
Build a Monthly LangGraph Budget from Fixed and Variable Layers
A practical forecast separates the service layer from execution. Start with seats, included traces, overages, deployment runs, uptime, and enabled LangSmith services; then add model tokens, paid tools, vector operations, storage, retries, and cloud compute. Do not multiply one average run by traffic and stop there. Split complex workflows by graph path because a short support flow, retrieval-heavy research flow, and supervisor with specialist agents can have different call counts and token profiles.
For each workflow, measure successful and failed runs, retries, input and output tokens, paid tool units, and path frequency. Review median and high-percentile cost, then group records by customer or plan. Keep the estimate auditable with current provider rates and a preserved pricing version; flag missing model, token, customer, or tool data instead of treating an incomplete event as billing-quality evidence.
Why LangGraph Builders Need Customer-Level Cost Tracking
If you are building AI applications as a product, whether self-serve SaaS or a managed service, you need cost by customer, workflow, and feature. Without that attribution, pricing plans rely on blended estimates and margin analysis loses the context needed for action.
The kinds of attribution teams typically need include:
- By LangGraph run or graph ID: which workflow was executed.
- By node or
langgraph_node: which step consumed resources. - By model call or tool call: which specific task within a step created usage.
- By workflow type: for example, a research agent versus a support agent.
- By customer or tenant ID.
Without cost-shaped telemetry, you cannot reliably identify which customers, workflows, or graph paths created spend. LangGraph's conditional edges, parallel branches, and dynamic routing make a blended average cost per user incomplete. Customer, run, node, and path attribution gives the team an actionable view.
For architectural patterns, see LLM cost tracking for AI agents. For connecting LangGraph runs to billing entities, see per-customer AI cost attribution.
Where Pylva Fits for LangGraph Runtime Cost Tracking
Pylva is SDK-first cost infrastructure that works through supported LangChain and LangGraph callback paths. The Pylva LangGraph SDK callback records supported model usage, provider, input and output tokens, latency, status, run IDs, and safe customer or step identifiers. When langgraph_node is present, Pylva uses it as step_name; a stable customer_id or workspace identifier connects that node to the account that created the usage. Pylva does not need prompts, completions, raw messages, tool arguments, or tool outputs. That boundary gives engineering, product, and finance the same customer-level record without turning cost telemetry into a second tracing system.
Application code should report raw usage facts such as tokens, calls, latency, and run IDs, then let Pylva price that usage server-side using configured model and tool price catalogs. This follows the report usage, not cost principle—your agent code never hardcodes dollar amounts.
Tool-call usage is opt-in because not every tool is billable. Enabling track_tool_calls in Python or trackToolCalls in TypeScript records selected callback tool executions with metric="calls" and metric_value=1. Configure pricing for that metric before using it in cost or billing views.
For the bottom-of-funnel implementation and buyer decision, see LangGraph cost tracking for AI agent workflows.
Use the Existing LangGraph Guides for Implementation
This pricing guide stays at the budgeting layer. Use the dedicated pages below for implementation details instead of repeating their code and event schemas here.
Token usage: How to Track Token Usage in LangGraph covers callback setup, run context, streaming, retries, and missing usage metadata.
Tool calls: LangGraph Tool Calling Cost Tracking covers billable tool events, retry handling, opt-in callback settings, and privacy boundaries.
Multi-agent workflows: LangGraph Multi Agent Example shows supervisor routing, specialist nodes, shared state, and customer attribution.
Pylva remains complementary to LangSmith observability, LangSmith Deployment, and LangGraph Studio. Its job is to preserve customer and graph context around supported model usage and opt-in tool events, apply pricing server-side, and route readers to the deeper implementation guides when they need code.
Engineering
Inspect run, node, model, status, retry, and latency context.
Product
Compare cost by workflow, feature, customer segment, and execution path.
Finance
Review customer-level cost and margin without reconstructing provider invoices.
Billing
Use validated raw usage and governed server-side pricing before invoicing.
Frequently Asked Questions
Is LangGraph free?
The LangGraph library is free and MIT-licensed. LangSmith Developer includes one free observability seat and 5,000 base traces per month; managed deployment begins on Plus. Model, tool, database, and cloud costs are separate.
What is LangSmith pricing?
Developer is $0 for one seat with 5,000 base traces per month. Plus is $39 per seat per month with 10,000 base traces and unlimited additional seats. Enterprise uses custom pricing. Trace and deployment usage can add pay-as-you-go charges.
Is LangSmith Deployment pricing the same as runtime cost?
No. Managed deployment pricing covers deployment runs, uptime, and platform services. Runtime cost covers model tokens, paid tools, storage, databases, and cloud infrastructure. They are separate line items.
What costs should I track in a LangGraph agent?
Track tokens, model calls, tool and API calls, retries, branching paths, deployment usage, and customer-level usage. Preserve the graph node and run context so the team can explain which workflow path created each cost.
How do I track LangGraph cost by customer?
Tag each run with a stable customer_id or workspace identifier, then attribute supported model and billable tool usage to graph nodes and tenants. Avoid placing direct personal data in cost metadata.
Can LangSmith show runtime cost?
LangSmith surfaces token usage, latency, traces, and evaluation data. It is not a complete customer billing or revenue-attribution system, so teams still need a separate cost and pricing layer when they must explain margin by customer or workflow.
How is Pylva different from LangSmith for cost tracking?
LangSmith focuses on observability and evaluation. Pylva focuses on cost-shaped telemetry, server-side pricing rules, and customer-level attribution. They are complementary rather than interchangeable.
Should my LangGraph code calculate dollars directly?
No. Pricing logic should live server-side. Application code should report raw usage metrics such as tokens, calls, and safe identifiers, then let a governed pricing system resolve the corresponding cost.
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.
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.
LangGraph Tool Calling Cost Tracking
How to track LangGraph tool calling cost by customer, graph node, run, tool name, metric, status, retries, and billable usage without sending tool inputs or outputs.