Claude Agent SDK vs LangGraph: The Real Cost

Claude is your model and nobody is asking you to change that?Agent SDK. You inherit the entire Claude Code harness — tools, subagents, permissions, caching, compaction — instead of writing it. That's weeks of work you skip.

A run takes twenty minutes and a crash at minute eighteen is unacceptable? LangGraph. Checkpointed durable execution is the one thing here you genuinely cannot bolt on afterwards without building half of LangGraph yourself.

You can draw the whole workflow on a whiteboard? LangGraph — or honestly, maybe not an agent at all. A known sequence with three branches is a state machine wearing a costume.

A client contract says “no vendor lock-in”?LangGraph. It's model-agnostic and Claude runs through it fine. You lose conveniences, not capability.

Both, because half the job is deterministic and half is fuzzy?That's the hybrid, and it's where most of the good 2026 systems have landed. More on it below.

Most comparisons treat these as two competing agent frameworks. They aren't. They sit at different altitudes, and once you see that, the choice mostly makes itself.

The Claude Agent SDK is the Claude Code engine handed to you as a library. Anthropic owns the agent loop. You give it tools, subagents, a system prompt and permission rules, and it decides what to call and when. Opinionated, batteries included, Claude-only.

LangGraph is a low-level orchestration runtime. You own the loop. You declare a state schema, write nodes, wire edges — including cycles and conditional branches — and the runtime executes your graph. Unopinionated, model-agnostic, more code.

So the honest framing isn't “which framework is better.” It's how much of the agent do you want to build versus inherit, and is Claude-only acceptable. Answer those two and you're done.

This is the stat driving most of the framework arguments right now, so it's worth pulling apart properly.

Published 2026 benchmarks on an orchestrator-plus-three-workers task put LangGraph around 18,500 tokens, the Agent SDK around 22,000, and CrewAI around 41,000. Reasonable spread. But a separate measurement clocked Agent SDK runs at roughly 35,000 input tokens each — about 25x the field— because the whole Claude Code harness rides along in the context window. That's the number that got screenshotted and passed around.

Here's the part that keeps getting dropped: about 33,000 of those 35,000 tokens were cache reads. Cache reads bill at 10% of the fresh input rate. So the effective cost multiple isn't 25x, it's closer to 4-5x.

Run the arithmetic at Sonnet 4.6 rates of $3 per million input tokens. A cold 35,000-token prefix is about 10.5 cents. Warm, at the 10% cache-read rate, those 33,000 cached tokens cost about 1 cent. The gap between the two frameworks on a single run is somewhere between a rounding error and a nickel. Meanwhile one senior engineer week costs more than a year of that difference at any volume a mid-size team is realistically running.

Two caveats, because I don't want to hand-wave this away entirely. Cold caches are real. If your agent fires a handful of times a day, spread out, you eat the fresh rate every time and the 25x is your actual bill — the caching economics only work when traffic keeps the prefix warm. And cached tokens still occupy context.A 33k-token harness is 33k tokens of window you don't get to use, which pushes you toward compaction sooner. Cheap isn't the same as free.

Either way: measure your own runs. Read usage.cache_read_input_tokens off the API response separately from usage.input_tokens. A benchmark that reports one aggregate token count is telling you almost nothing about your invoice. Same trap I wrote about in the real token cost of subagents, where the scary-looking number turned out to be the cheap one.

If you strip the marketing off both, LangGraph has exactly one feature that's genuinely hard to replicate, and a few that are merely annoying.

The hard one is durable execution. Every node result is checkpointed. Kill the process at step seven of twelve, restart, and it picks up at step seven with the state it had. It doesn't re-run steps one through six, doesn't re-charge you for them, doesn't re-send the emails they sent. If your workflow moves money, touches customer records, or runs long enough that infrastructure will interrupt it, this is the feature you're actually buying.

The merely-annoying ones: explicit cycles and conditional branches you can read in the code, parallel fan-out with a real join, and human-in-the-loop interrupts that pause a run mid-graph waiting on an approval. You can approximate all of it in an agent loop with enough prompting and tooling. It just won't be as testable, and “the model decided not to wait for approval today” is a genuinely bad incident to write up.

This is the same argument I made about human-in-the-loop approvals in n8n: the moment a step needs a guaranteed pause, you want that guarantee in the runtime, not in a system prompt. Prompts are suggestions. Graph edges are not.

The counterweight is volume of code. You write the state schema, the nodes, the edges, the reducers, the retry policy. That's not a criticism — it's the deal. You're trading boilerplate for control, and for some workloads that trade is obviously correct.

The Agent SDK's pitch is that Anthropic already solved the boring, fiddly parts of running an agent in production, and shipped them as defaults. Prompt caching wired correctly. Extended thinking. MCP client support. File and shell tooling. Subagents with their own context windows. A permission system so the thing can't rm -rf its way through your repo.

Here's my honest test for whether you should be using it: if you catch yourself building a tool-call loop, a permission prompt and a compaction strategy inside a graph node, stop.You're re-implementing the SDK by hand, worse, and you'll maintain it forever. I've done exactly this. It took a week and the result was a strictly inferior version of something I could have imported.

The flip side is real and worth saying plainly. Anthropic owns the loop, which means when it does something you didn't expect, your options are narrower — you steer with prompts, tools and permissions rather than editing the control flow. And it's Claude-only. If model portability is a live requirement rather than a hypothetical one, that's disqualifying and no amount of convenience fixes it.

Worth noting that the SDK isn't automatically the right call over just hitting the API directly, either. That's a separate decision with its own tradeoffs, and I broke it down in Claude Agent SDK vs the raw API. Short version: plenty of “agents” are one well-structured API call with a retry, and framework shopping is a way of avoiding that realization.

The framing that finally made this click for me: use a graph where you need determinism, and an agent where you need judgment. Almost every real workflow has both, and forcing one tool to cover both is where systems get ugly.

In practice that looks like LangGraph as the top-level state machine — it owns sequencing, retries, checkpoints, approval gates, and the audit trail your client will eventually ask for. Individual nodes then call Claude Agent SDK subagents for the steps where the work genuinely is open-ended reasoning: read this messy thing and tell me what it means, look at these five sources and reconcile them, write the draft.

You get durable orchestration where a crash would hurt, and a strong agent loop where the model needs room to think. The seam between them is a plain function call, which is about as low-risk as integration seams get.

One warning from experience: put observability on the seam before you need it. Two runtimes means two places a run can stall, and debugging “it's just sitting there” without traces across both is genuinely miserable. Log the node boundary, the subagent's token usage, and its stop reason. Same discipline as instrumenting n8n AI agents — the fix is boring and it takes an afternoon, and skipping it costs you a weekend later.

I build a lot of client automation, and my default order isn't what framework comparisons expect.

First I check whether it needs an agent at all.A surprising share of “agent” briefs are a scheduled job, three API calls and one classification. Those ship in n8n in an afternoon and never page anyone at 2am. Reaching for an agent framework there is how you turn a solved problem into a maintained one.

If it does need judgment and Claude is fine, I start with the Agent SDK.Fastest path to a thing that works, and the token overhead is noise against the engineering time it saves. I've never once had a client care about a nickel per run. They care that it shipped this month.

I move to LangGraph when a specific requirement demands it— a resumability guarantee, a hard approval gate, a contract clause about model portability. Not because it's “more production-grade,” which is a phrase that means nothing. Because something concrete broke, or is going to.

The mistake I see most often is picking the heavier framework first, on the theory that you'll grow into it. You mostly grow into the maintenance. Start at the altitude your problem actually lives at, and move up when something forces you to — that's the same instinct behind how I approach agent cost in general: the cheapest architecture is usually the one doing less.