LangGraph

This is the thing to get straight before anything else, because the vendor page and the pricing page describe two different products.

The library — langgraph on PyPI (1.2.11, 13 Aug 2026) and @langchain/langgraph on npm (1.4.9) — is MIT, as is the GitHub repo and the Postgres checkpointer package langgraph-checkpoint-postgres (3.1.2, MIT). The docs are explicit that "You don't need to use LangChain to use LangGraph." Nothing phones home: tracing to LangSmith is opt-in via environment variable. If you build a graph, back it with your own Postgres, and serve it from your own FastAPI process, you owe LangChain nothing and are not locked to their infrastructure. That is a real and unusually clean position, and it is the version of LangGraph most teams should start from.

The server is a separate object. langgraph-api on PyPI — the package behind langgraph dev, which gives you the assistants/threads/runs HTTP API, Studio integration, cron scheduling and a task queue — is licensed Elastic License 2.0, not MIT, and has no public GitHub repository. (Curiously, the JavaScript equivalent, @langchain/langgraph-api, is MIT with a public repo at langchain-ai/langgraphjs-api — so the licensing asymmetry is language-specific, not a stated policy.)

So: "LangGraph is an MIT-licensed open-source library and is free to use" (vendor's own words) is true and is not the whole picture. The graph engine is free. The server that turns a graph into a deployable, managed, resumable service is not.

Durable execution is the actual product. A checkpointer persists a graph state snapshot at every node boundary, which is what gives you conversation continuity, human-in-the-loop interrupts, time travel (rewind to an earlier checkpoint and re-run a different branch), and crash resumption. If your agent runs for minutes, pauses for a human, and must survive a process restart with its state intact, that is a genuinely hard thing to build and LangGraph gives it to you as library behavior rather than as a hosted service you must buy. The official backends are InMemorySaver, SqliteSaver and PostgresSaver — Postgres being the one that matters in production, and it's MIT.

The execution model is a real design, not a wrapper. LangGraph implements a variant of the Pregel/BSP model to orchestrate graphs with cycles and parallel branches without data races — which is why it handles loops and fan-out that a plain DAG runner can't. This distinction shows up even in the framework-sceptical corners of the internet: in a Hacker News thread otherwise critical of LangChain, a commenter drew the line explicitly — "LangGraph is different. It is a legitimate piece of workflow software and not a wrapper framework." Another: "fully agree that LangChain is a meaningless abstraction but I've found that the graph abstraction that LangGraph uses is a very useful mental model." That is about as good as unsolicited praise gets for a framework in this category.

It is now the default path, not a side path. As of LangChain 1.0 (22 Oct 2025), LangChain agents are built on LangGraph as their runtime — langchain 1.3.15 hard-depends on langgraph>=1.2.11. If you adopt LangChain at all, you are already running LangGraph. That reduces the "will this be abandoned" risk considerably compared with a standalone framework.

Versioning is now a commitment. LangGraph 1.0 shipped 22 Oct 2025 with, per the vendor, no breaking changes to the core graph primitives and a stated commitment of "no breaking changes until 2.0." For a project whose ecosystem's chief historical complaint was API churn, that's the right thing to have done and it is worth crediting.

If you want LangGraph Server (or, in the current naming, an Agent Server) running on your own infrastructure, LangChain's documentation is unambiguous: "Self-hosted deployments require an Enterprise plan and the LangSmith license key delivered with that plan." A LangChain staff member on the official forum put the practical consequence more bluntly: "Langraph OSS itself is free to use, but the associated binaries that run the Langgraph server are an enterprise solution which requires an enterprise key to run in production" — and, for local work, "You can still start a local dev server... but that is not recommended in production."

This matters most for teams whose whole reason for choosing an open-source framework was to avoid a vendor relationship. The escape routes, in rough order of effort:

1. Skip the server entirely. Use the MIT library plus PostgresSaver and write your own HTTP/queue layer. Fully supported, fully free, and how a lot of production LangGraph actually runs — you're giving up Studio, the managed runs API, and the built-in task queue.
2. Use the hosted deployment on Plus or above (see costs below).
3. Use a third-party server. Aegra is an Apache-2.0 drop-in for LangGraph Platform/LangSmith Deployments — same LangGraph SDK and API surface, FastAPI + Postgres, self-hosted. As of 13 Aug 2026 it has 1,130 stars, 226 forks, 87 open issues, and commits from today. That's an active project, not an abandoned one, but it is a young single-purpose community effort re-implementing a commercial API surface, and you should weigh it as such.

None of this makes LangGraph a bait-and-switch — the open-core line is drawn in a defensible place and it's documented. But it is drawn at exactly the point where a hobby project becomes a production system, so it belongs in the procurement conversation and not in the deployment sprint.

LangGraph Platform pricing now redirects into LangSmith pricing; they are one commercial product.

Seats and traces. Developer is $0/seat, capped at 1 seat, with up to 5k base traces/mo then pay-as-you-go, and 5 LCU + 1 LSU of sandbox usage/mo. Plus is $39/seat/mo, unlimited seats, up to 10k base traces/mo, one free Serverless (Small) deployment, and 25 LCU of Fleet usage/mo. Enterprise is custom and is the only tier with self-hosted and hybrid options. A base trace beyond quota is $0.0005 (0.05¢); upgrading a trace to extended retention adds 0.45¢, for 0.50¢ total.

Compute. Deployments meter in two synthetic units: LCU at $1.50 and LSU at $1.00. The published rates are Runtime Compute 0.045 LCU/vCPU-hr, Runtime Memory 0.006 LCU/GiB-hr, Database Compute 0.177 LSU/vCPU-hr, Database Memory 0.025 LSU/GiB-hr.

Convert those to dollars and the non-obvious result falls out: the Postgres behind your checkpoints costs more per vCPU-hour than the agent runtime does. Runtime compute is $0.0675/vCPU-hr; database compute is $0.177/vCPU-hr — roughly 2.6×. Memory shows the same shape ($0.009 vs $0.025 per GiB-hr, ~2.8×). Durable execution is the feature you came for, and durable execution is the line item.

Illustrative arithmetic, not a quote: an always-on deployment sized at 1 vCPU / 2 GiB runtime plus 1 vCPU / 2 GiB database, over a 730-hour month, is about $62 of runtime and about $166 of database — roughly $228/mo for one deployment, before traces and seats. LangChain does not publish the vCPU/GiB sizing of Serverless Small/Medium/Large, so treat that figure as an order-of-magnitude illustration of the rate structure and use the calculator on their pricing page for anything you'd actually commit to. Serverless deployments can scale to zero after inactivity (marked beta), which materially changes the maths for bursty workloads and not at all for a chat product with steady traffic.

The honest summary: cheap to evaluate, cheap for one small always-on service, and the seat charge plus per-deployment database floor is what makes it add up across a team running many agents.

The vendor's site shows 30+ logos including Klarna, Uber, LinkedIn, Rippling, Harvey, Workday, Cisco, Nvidia, LinkedIn, Coinbase and ServiceNow, and the 1.0 announcement names Uber, LinkedIn, Klarna, JP Morgan, Blackrock and Cisco as production users. Take these as vendor claims by default — a logo wall does not distinguish "one team piloted it" from "it's core infrastructure."

One is corroborated first-hand. Uber's own engineering blog states: "For agent development and workflow orchestration, we used LangChain LangGraph™, a scalable yet developer-friendly framework for agentic AI workflows," describing its use in their agentic-RAG system, and a second Uber post describes LangGraph orchestrating their Finch financial-data agents. That is a named large engineering organization writing about it in their own voice, which is worth more than the rest of the wall combined.

The scale claims circulating elsewhere — "around 400 enterprises run LangGraph in production," "12 million downloads a month," Klarna's "80% reduction in resolution time" — all trace back to LangChain's own blog and social posts. Not necessarily wrong; just not independently established, and we shouldn't repeat them as fact.

On download numbers, a caveat we should apply to ourselves too. PyPI shows 72.7M downloads for langgraph in the last 30 days and npm shows 12.6M for @langchain/langgraph. Because langchain 1.3.15 hard-depends on langgraph, every pip install langchain counts. These figures prove the LangChain ecosystem is enormous; they do not measure deliberate LangGraph adoption. The GitHub repo's own stars are a cleaner signal of direct interest.

Single-vendor, and visibly so. The top contributors to langchain-ai/langgraph are LangChain employees: nfcampos (2,262 commits), hinthornw (800), vbarda (783), dqbd (526), eyurtsev (380), sydney-runkle (322), hwchase17 (108). There is no meaningful independent contributor base and no foundation governance. Commit activity over the last eight weeks runs 4–18 commits/week — active, steady, not frantic. Practically: the MIT license means a fork is legally possible, but the expertise to maintain the Pregel-style scheduler sits inside one company. The repo has 685 open issues.

The company is well capitalized. LangChain raised a $125M Series B led by IVP at a $1.25B valuation in October 2025, with Sequoia, Benchmark, CapitalG, ServiceNow Ventures, Workday Ventures, Cisco Investments, Datadog and Databricks participating. TechCrunch reported ARR of $12–16M as of June 2025 — a large gap between valuation and revenue, which is normal for the category and is also the reason to expect continued pressure to monetize the platform layer rather than the library. Nothing here suggests near-term abandonment risk; the risk to watch is the open-core line moving, not the lights going out.

These are trade-offs, not defects — several follow directly from the design decisions that make it good at its actual job.

Your agent is a single tool-calling loop. LangGraph's cost is conceptual overhead: state schemas, reducers, node/edge wiring, checkpointer configuration. If you're calling a model in a while loop with three tools, a provider SDK will be shorter and easier to debug. Start at langchain.agents.create_agent (which is LangGraph underneath) and drop to raw LangGraph when you actually hit branching, loops or interrupts.

You need a self-hosted managed server without an enterprise contract. Covered above. Budget either for the Enterprise plan, for writing your own serving layer, or for evaluating Aegra.

You already run a durable workflow engine. If Temporal, Restate or similar is in your stack, you already have durable execution, retries and resumption — LangGraph's headline feature is a duplicate, and you'd be adopting it for the agent ergonomics alone. Worth being honest with yourself about which one you're buying.

Debugging. The common criticism from practitioners is that stack traces through a graph scheduler are harder to follow than through your own loop, and that the framework hides control flow. LangGraph's answer is the tracing product — which is the thing that costs money, and which is a real answer, just not a free one.

Migration friction that does exist despite the 1.0 promise. langgraph.prebuilt is deprecated and create_react_agent is superseded by create_agent in langchain. Tutorials and Stack Overflow answers written before October 2025 will point at the old surface. The core graph API is stable; the ergonomic layer above it moved.