Dora NodaLangGraph Platform is now generally available, and LangChain says nearly 400 companies already run agents through it. The pitch is a runtime built for what agents actually are — long-running, stateful, interruptible — instead of a generic container that happens to run Python. The price is usage-metered down to the graph node: $0.001 every time your agent executes a single step.
Here is the headline math, up front, because everything else in this post is commentary on it: a customer-support agent that averages 20 nodes per run, serving 50,000 conversations a month, burns 1,000,000 node executions. That is $1,000 a month in metered charges, plus about $156 for an always-on production deployment, plus $39 per seat for LangSmith Plus — before you pay a cent to your model provider. The same agent as a plain container with a Postgres checkpointer costs on the order of $50 a month, flat, at any volume.
That gap is not a verdict. It is a question with a real answer, and the answer depends on which of the Platform's primitives your agent actually needs. This post works out the cost math across typical volumes, separates which primitives live in the free open-source library from which ones the meter is really charging for, and gives you a decision rule for when the specialized runtime earns its keep — and when your agent is, in the most literal sense, a Python process with a Postgres table that just needs a container and a queue.
The cost math, worked out
LangGraph Platform's Plus-tier pricing has three parts: $0.001 per node executed, standby time for live deployments ($0.0036/minute for production, $0.0007/minute for dev), and a $39/user/month LangSmith Plus subscription underneath it. The Developer tier softens the landing with 100,000 node executions free per month, but production traffic leaves that behind fast.
Standby first, because it is the fixed floor: a production deployment that stays warm around the clock costs $0.0036 × 43,200 minutes, or $155.52 a month, before a single agent runs. A dev deployment idling the same way is $30.24. This is the price of never cold-starting — reasonable for a latency-sensitive agent, but already triple the cost of an entire small container plus Postgres on a mainstream PaaS.
Then the meter. Every node execution — each LLM call, each tool call, each routing step inside the graph — is a tenth of a cent. That sounds negligible until you multiply by graph depth, which is the variable most teams underestimate. A tight ReAct loop might touch 5 nodes per run. A support agent with retrieval, reranking, guardrails, and a draft-and-critique pass easily touches 20. A deep research agent with planning, parallel sub-agents, and reflection can touch 100. The table below shows monthly metered cost (nodes only, before standby and seats) across that range:
| Nodes per run | 10k runs/mo | 50k runs/mo | 500k runs/mo |
|---|---|---|---|
| 5 (tight loop) | $50 | $250 | $2,500 |
| 20 (support agent) | $200 | $1,000 | $10,000 |
| 100 (deep research) | $1,000 | $5,000 | $50,000 |
Add the ~$156 standby floor and seats to each cell. Now compare against the flat line: a small container and a managed Postgres on any mainstream git-push PaaS runs on the order of $50 a month total, whether your agent executes ten thousand nodes or ten million. The crossover is not subtle. At low volume — a prototype doing a few thousand runs of a shallow graph — the Platform's metered bill can be cheaper than running infrastructure, especially inside the free 100k-node tier. But the meter scales with reasoning depth times traffic, which is exactly the curve that grows fastest when your agent succeeds. Cost scales with intelligence, not with machines.
Note what is not in either column: model tokens. Both sides pay the LLM provider identically (bring your own key), so this comparison is purely about the runtime layer. And note the honest caveat on the flat side: the $50 line buys raw compute and a database, not the agent primitives. Replicating those is real work, which is what the next two sections price out.
What the per-node dollar actually buys
The most important fact about LangGraph Platform pricing is a layering fact: the agent primitives are mostly in the MIT-licensed open-source library, which costs $0 with no usage ceiling. The meter charges for the managed running of them. Here is the split:
| Primitive | OSS library (free) | Managed Platform (metered) |
|---|---|---|
| Durable execution via checkpointing | Yes — checkpointers for Postgres, SQLite, Redis | Managed checkpoint store, no ops |
| Thread persistence + short/long-term memory | Yes — same APIs | Managed, scaled, backed up |
| Human-in-the-loop interrupts | Yes — interrupt(), approve/edit/resume | Same, plus Studio review UI |
| Streaming intermediate steps | Yes | Yes, over managed endpoints |
| Cron + webhook-triggered runs | No (you wire a scheduler) | Built-in triggers |
| Studio time-travel debugging | Local Studio against your server | Hosted, against prod threads |
| Double-text / concurrency handling | Patterns you implement | Built into the runtime |
| Scaling, deploys, uptime | Your container platform | One-click deploy, autoscaling |
This table is the whole buy-vs-build debate in one picture. Durable execution — the headline feature, state persisted after every step so a run survives restarts and resumes mid-graph — is a checkpointer, and the Postgres checkpointer ships in the free library. Human-in-the-loop is an interrupt() call in the free library. What the meter genuinely buys is operations: no Postgres to run, no queue to scale, no Studio to host, triggers and double-text handling you do not write yourself, and LangSmith tracing wired in by default.
Whether that operations bundle is worth a bill that scales with reasoning depth is the question Section 5 answers. But first, the honest version of the alternative.
What "just a container" has to replicate
The self-hosted shape of a LangGraph agent is well-trodden at this point, and it is deliberately boring infrastructure:
- The graph server in a container.
langgraph upproduces a production-grade Docker stack — the graph API with Postgres behind it for checkpoints and threads plus a Redis-backed task queue, listening on port 8123. That image runs anywhere containers run: Railway's own docs walk through a LangGraph agent backend with a Postgres checkpointer where every thread survives restarts and redeploys, and community runtimes like skein-js package LangGraph.js graphs for Cloud Run, Render, Railway, Fly.io, or a plain VPS. - Postgres as the durability layer. This is the single most load-bearing piece, and it is one managed database. Checkpoint-after-every-node means a deploy, a crash, or a spot eviction interrupts at most one step; the thread resumes from the last checkpoint on the new container. You do not need the Platform for exactly-once-ish agent state — you need a database you were probably already running.
- A queue and a scheduler. A Redis-backed queue absorbs run spikes; your PaaS's cron or a small scheduler service replaces built-in cron triggers. Neither is agent-specific.
- Tracing via LangSmith or your own logs. The OSS graphs emit LangSmith traces with an API key even when self-hosted, so observability partially carries over for free.
Total marginal infrastructure for a team already on a PaaS: roughly one service and one database. The genuinely harder things to replicate are narrower than the marketing suggests, but they are real: Studio time-travel debugging against production threads (replaying and forking a real failed run step-by-step is the single best agent debugging experience in the ecosystem, and self-hosting it against prod state takes deliberate work), managed scale-to-zero with warm wakeups, and concurrency edge cases like double-texting — two user messages arriving mid-run — which the managed runtime serializes for you and which a DIY deploy must handle with thread locking. If your roadmap is full of long-running, human-supervised, heavily-debugged agents, that list is doing real work. If it is not, you are paying per node for insurance against problems you do not have.
The decision rule
Strip away the branding and the choice reduces to workload shape:
- Pay the meter when the agent is stateful, long-lived, and human-supervised. Multi-day threads, approval gates a compliance team actually clicks through, support copilots whose failures get replayed in Studio every morning, spiky traffic where managed scaling beats capacity planning. Here the Platform's bundle — triggers, Studio-on-prod, serialized concurrency — replaces weeks of platform engineering, and the per-node bill is cheaper than the engineer. Prototype inside the free 100k-node tier, then watch the nodes-per-run distribution, not just the run count: depth is what moves the bill.
- Ship a container when the agent is stateless, short, or checkpoint-simple. A research agent that reads its state from Postgres at start and writes it back at end. A webhook-triggered classifier with a five-node graph. Anything where "durable execution" reduces to "the database write succeeded." Here the OSS library gives you the graph semantics for free and the PaaS gives you the running for flat money — and your cost per run falls as you optimize prompts, instead of rising with every reasoning step you add.
The crossover heuristic that falls out of the table above: if your expected monthly meter (runs × typical nodes × $0.001, plus $156 standby) exceeds roughly 3–4× the flat container cost — call it $200 a month — you should be able to name the specific managed primitive earning the difference. "Studio time-travel on prod threads" is a valid answer. "We might need HITL someday" is not; the free library already has interrupt().
One more consideration for the build column: the meter taxes exactly the behavior you want to encourage. Every extra reflection step, every verification pass, every "let the agent double-check" makes the product better and the bill bigger. Flat compute aligns cost with machines, which get cheaper; per-node billing aligns cost with reasoning, which you want more of. Teams on metered runtimes eventually start budgeting intelligence — capping graph depth, skipping the critic pass — and that is a strange incentive to accept without a fight.
Agents are workloads, and workloads need a PaaS
LangGraph Platform going GA with nearly 400 companies in production is a genuine signal: stateful agent runtimes have crossed from framework curiosity to infrastructure category, and LangChain's bet — that durable execution, memory, and human oversight deserve a purpose-built layer — now has production evidence behind it, from Uber and LinkedIn down to the long tail. But categories mature in two directions at once: the specialized runtime gets better and the generic alternative gets good enough for most workloads. A checkpointed graph on Postgres, in a container, behind a queue, is today what a twelve-factor web app was a decade ago — the boring default that wins on cost and portability for everything except the workloads that can articulate why they are special.
So start from the boring default. Profile your graph depth, multiply by your traffic, and make the Platform argue for its meter line by line. The agents that truly need it — long-lived, supervised, debugged daily — will justify it easily. Everything else just needs a container that stays up, a Postgres that stays backed up, and a deploy story your team already knows.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Your LangGraph agent is a container with a Postgres checkpointer; deploy it someplace the meter doesn't tax its reasoning.
