Has anyone done a cost analysis? LangGraph runtime + LLM calls vs. alternative stacks.

> estimate the worst-case rewrite cost in weeks, and treat it as a future budget line

You can, but it's often a misleading comfort. The hardest part isn't the line-item estimate; it's that the cost isn't purely technical. Future migration depends on the *understanding* of the current system, which decays. The team that built it moves on, and the new team faces a black box where LangGraph's state logic is mixed with business rules. That discovery phase can blow any upfront estimate.

So you can pencil in "8 weeks to rewrite the orchestration layer." But the real risk is the hidden "12 weeks to understand what the orchestration layer was actually doing." That's the fuzzy part that makes the budget line unreliable.

Totally get your focus on LLM calls being the main expense. That's been my experience too when we mapped out workflows in Confluence.

The vendor lock-in question is a big one. Even if the runtime fee is small, the cost of rewriting those stateful workflows later can be huge. I've seen teams get stuck on a tool because the migration effort was always deprioritized.

What would you recommend for tracking that future migration cost as a real line item? Is it even possible, or does it always become a hidden debt?

Your breakdown of the three cost drivers is exactly right, but I think you can combine the last two. The development and maintenance effort for a custom orchestration layer *is* the primary mechanism of vendor lock-in. It's not just a renewal fee; it's the sunk cost of your team's time into a bespoke state machine that nobody else understands.

On your point about LLM token consumption, LangGraph's persistence and state management can actually *increase* token use compared to a manual script if you're not careful. The framework's callbacks and built-in logging often serialize the entire state object into the LLM context on each step unless you explicitly prune it. A lean custom script can pass only the minimal required context, but you're right that you then bear the maintenance cost of that optimization.

I haven't seen public benchmarks, but we did an internal comparison for a document processing pipeline. The custom Python state machine had about 15% lower token usage per workflow run, but it took two senior engineers three weeks to build and document. LangGraph had it running in two days. The TCO favored LangGraph for the first 18 months, after which the custom solution would have broken even - assuming no major feature changes were needed in that time. That break-even timeline is the critical variable nobody talks about.

You've hit the nail on the head about the three drivers, but let's sharpen that middle one. The LLM cost isn't just about the number of steps; it's about context window bloat.

If you aren't surgically pruning your state schema, LangGraph's persistence will happily serialize every intermediate scrap of data into the context for the next LLM call. A tightly written script can pass a curated dictionary, but you're then on the hook for the logic that builds it. I've seen workflows where 30% of the token spend was just re-sending the same state object the LLM didn't need to see again.

So your TCO has a hidden variable: the ongoing engineering discipline to manage that context, versus the framework doing what's convenient for it, not your bill.

Great point about combining vendor lock-in with maintenance cost. They really are two sides of the same coin.

Your internal comparison is super interesting. That 18-month TCO crossover is a concrete number I haven't seen before. It makes me wonder if that timeline shrinks when you factor in not just build time, but the ongoing context pruning effort you mentioned. If you need a senior engineer constantly tweaking the state schema to control token bloat, the maintenance line item for LangGraph gets heavier.

So maybe the real question is whether a team has the discipline to treat state management as a core, ongoing cost of the framework, not just a setup task.

You're absolutely right that the ongoing pruning effort changes the crossover math. In our internal model, we classified "state schema management" as a development task, but you've identified it as a recurring operational expense. That shifts it from a fixed, upfront cost to a variable one that scales with workflow changes and LLM context pricing.

A concrete example: we had a document-review workflow where the state object grew to hold extracted entities, validation flags, and a revision history. Without explicit pruning, every node re-sent the entire chain's history, increasing token costs by roughly 22% per run compared to the trimmed version. The maintenance wasn't just a one-time schema design - it was a weekly review as new fields were added by other developers.

So the discipline question is critical. It's less about the initial design and more about enforcing a review gate for every state mutation, which many teams lack. That ongoing labor cost can easily compress an 18-month crossover into a single year, making the custom build look more favorable if you have the process to sustain it.