---
title: "Caveman vs LangGraph: graph execution and cost evidence"
description: "Use LangGraph when your application needs explicit graph state, durable execution, interrupts, and control over agent orchestration. Caveman's LangGraph.js adapter observes lifecycle and usage inside "
canonical: https://caveman.so/compare/langgraph
last-updated: 2026-09-07
---

# Caveman vs LangGraph: graph execution and cost evidence

Use LangGraph when your application needs explicit graph state, durable execution, interrupts, and control over agent orchestration. Caveman's LangGraph.js adapter observes lifecycle and usage inside that runtime. It does not replace the graph or transform its context.

That makes the first choice straightforward: keep the graph if it already expresses your workflow. Add Caveman when consistent usage evidence is worth testing. Choose a full runtime migration only after mapping the state and execution contracts you depend on.

## What changes with the adapter

| Responsibility | Result |
| --- | --- |
| Nodes, edges, state, and checkpoints | Remain in LangGraph |
| Model calls and retries | Remain with the native stack |
| Lifecycle and usage observations | Added through native callbacks and stream transformers |
| Prompt or context transformation | Unsupported by this adapter |
| Budget enforcement | Not supplied by the adapter |
| Python LangGraph integration | Not covered by the JavaScript adapter |

[LangGraph's overview](https://docs.langchain.com/oss/javascript/langgraph/overview) describes its runtime features. The [Caveman adapter](https://github.com/caveman-ai/agent-sdk/tree/main/packages/adapters/langgraph) is pinned to `@langchain/langgraph@1.4.13` and `@langchain/core@1.2.9`. Its capabilities are experimental, with no certification.

## Why observe a graph that already reports usage?

Usage fields can lose meaning when normalized too early. An absent cache count should not become a measured zero. A graph that calls several models also needs reliable identity before its usage can be attributed or priced.

Caveman's adapter uses native message usage evidence and retains unknown fields. Static identity fits a single-model graph; a multi-model graph needs a correct resolver or usable native metadata. Guessing the provider from a model nickname can create a convincing but wrong cost report.

The adapter does not supply full distributed tracing, durable observation, replay awareness, or compilation. Keep existing operational instrumentation for contracts it does not cover.

## A checkpoint changes the cost boundary

A graph can pause, resume, retry a node, or invoke another graph. Count the work needed to finish the task across those transitions. A per-request average can hide an expensive recovery path or split one task into several apparently cheap runs.

When evaluating context reduction elsewhere in the stack, test resumed execution. The agent may need a detail stored before the pause. Any recovery mechanism has to remain available for that task's lifetime.

Caveman's LangGraph adapter itself will not compress those messages. Use a separately supported integration or an explicit application change, then judge it with [task-level evaluations](/guides/agent-evaluations).

## When to keep LangGraph

Keep it when checkpoints, interrupts, graph structure, and existing tooling are central to the application. An observability addition should not disturb those contracts.

Consider Caveman's own SDK when its agent definition and build workflow fit a new agent or a bounded migration. There is no automatic translator from an arbitrary state graph to an equivalent Caveman agent.

If the immediate problem is an expensive coding-agent session, [local Caveman launchers](/guides/coding-agent-setup) offer a separate route that does not involve moving the application framework.

The [LangGraph switching guide](/switch/langgraph) shows source setup, callback composition, identity checks, and rollback for the native adapter. For the observability product, read [Caveman vs LangSmith](/compare/langsmith).