LangChain Alternatives in 2026 (Open Source)

Most guides to LangChain alternatives rank the options. That is the wrong shape: if you are looking to leave, you have a specific complaint, and which one you have decides where you should go. A ranking sends everyone to the same place regardless.

Every row has a section below. If none of them is your complaint, the honest answer is that you may not have a framework problem.

Most of what follows is Python-only. LlamaIndex.TS was archived on 30 April 2026 and its README states "This project is deprecated and no longer maintained", pointing readers at the Python docs rather than a TypeScript successor. Haystack, DSPy and Pydantic AI have no TypeScript port. If you are on LangChain.js, that leaves LangGraph, whose JS package was last published 14 August 2026, or the provider SDK. TypeScript-first frameworks exist and are outside this page's scope.

How big these projects are

Star counts read 8 August 2026:

What this cannot tell you, despite being the obvious thing to ask it: whether anyone is migrating. A star records a moment of discovery, and nobody un-stars a framework when they stop using it. A team that moved off LangChain last quarter still shows in its star count and produces no signal here at all. Any comparison article inferring migration from star charts is over-reading the instrument.

It tells you nothing about fit either. LangChain leads this table by nearly three times and is the thing this page is about leaving. Haystack sits second from last and is the strongest answer on this page for one specific problem. Popularity and suitability are different questions, and on this page they mostly disagree.

First, check you are leaving for the right reason

Two reasons to leave are worth examining before you migrate anything.

"It's too abstracted." Fair historically, but the architecture changed. LangChain's own documentation now states plainly that "LangChain's agents are built on top of LangGraph," inheriting durable execution, human-in-the-loop support and persistence from it. If your objection came from a write-up rather than from your own codebase, check the date on it before paying migration costs.

"It broke on upgrade." This one is real. The 1.0 migration relocated core APIs into a separate langchain-classic package, which now carries "legacy chains, langchain-community re-exports, indexing API, deprecated functionality, and more."

pip install langchain-classic

Be clear about what that does and does not buy you. It restores the code without restoring your imports: the paths moved, so you still edit every call site that touched a legacy chain. It buys time to migrate deliberately rather than under pressure. It is not a way to skip the migration.

And every framework in this category has shipped breaking changes. Switching to escape churn can mean paying migration cost twice.

The reason that genuinely justifies leaving is shape mismatch: you are using a small fraction of a large framework, and its abstractions describe a problem you do not have.

Start here: LangGraph

LangGraph is barely a move at all, which is exactly why it belongs first. Same company, and as LangChain's own docs confirm above, the agent layer already sits on top of it. Its README bills it as a "low-level orchestration framework for building stateful agents," and says it "can be used without LangChain."

If your complaint is specifically about the high-level abstractions, dropping to LangGraph gives you explicit state and control without changing ecosystems. It is not free: chain topology and any callback or tracing wiring still have to be rewritten, and if you drop LangChain entirely you give up its integration catalogue along with it. But you keep your tooling, your team's operational knowledge, and your provider setup.

This is the answer to one complaint, not to all of them. If layers are what is bothering you, try it before anything else on this page. If your complaint is one of the other five, LangGraph does not address it — and for "breaking changes keep costing me time" it is actively the wrong direction, because it is one more framework dependency rather than one fewer.

The alternatives

Pydantic AI: typed all the way down

Pydantic AI's README calls it a "GenAI Agent Framework, the Pydantic way." Take the first half literally. This is a full agent framework with tools, dependency injection and MCP support, well beyond a thin validation wrapper. What differs from LangChain is the house style rather than the scope: typed and validated throughout, so whole classes of error move from runtime to write-time by checking model output against Pydantic models you already know how to write.

It is the smallest project in the table above, which raises the obvious worry about provider support. That is not where the trade-off sits. The README says it supports "virtually every model and provider" and named 28 of them when we counted on 8 August 2026, plus a documented path for implementing your own.

The real trade-off is ecosystem surface. You get fewer off-the-shelf document loaders, retrievers and vector-store integrations than LangChain offers, so more of the retrieval layer is yours to assemble. If your application is mostly structured model calls with tools, that is a good deal. If you were relying on LangChain's integration catalogue to avoid writing connectors, you will feel the difference immediately, and you should count that work before committing.

LlamaIndex: built for document-heavy work

Best when the hard part is getting heterogeneous documents in and indexed well, and where multi-step reasoning is a secondary concern. Its connector and indexing surface is its strength.

Worth knowing that the project is currently describing itself two different ways. The repository's GitHub description reads "LlamaIndex is the leading document agent and OCR platform," while the first line of its README calls it "an open-source framework to build agentic applications." The README then separates the two, naming Parse as the enterprise platform for agentic OCR and extraction.

Do not read that as a gotcha, but do read it as a signal about where attention is going. If you are adopting LlamaIndex for parsing and extraction, you are moving with the project. If you want it purely as an orchestration layer, check that the parts you depend on are getting the same attention as the document stack.

Haystack: when you cannot tell whether your changes help

Haystack comes from deepset, and its distinguishing feature is that evaluation ships in the box.

Haystack's evaluators split into two families. Statistical evaluators (exact match, document recall, MRR, MAP, NDCG) generally require ground-truth labels. Model-based evaluators (faithfulness, context relevance, and a general LLM evaluator) generally do not. The exception worth knowing before you plan an evaluation set is SASEvaluator, which is model-based but still requires labels. Integrations with dedicated evaluation toolkits such as Ragas and DeepEval are available alongside, if you would rather not build the harness yourself.

If your actual problem is at the pipeline level — retrieval quality, end-to-end answers — this is the strongest answer on the list. If the thing you cannot evaluate is the prompt itself, that is DSPy's problem rather than this one.

On stability, Haystack 3.0 shipped on 20 July 2026, with deepset describing "a few small, intentional breaking changes."

The same notes record 30 components moving out of core into separately released integration packages, so how small the upgrade feels depends on what you import. The reassuring part for the use case above: the evaluators did not move. All nine still ship in core on main, SASEvaluator included, and 3.0 improved several of them.

One related trap worth knowing: the Sentence Transformers components (embedders and rankers) did move to a separate package. SASEvaluator is unaffected by that, because it imports the upstream sentence-transformers library directly and that was never part of core. If it fails after an upgrade, the fix is an extras install rather than an import change.

Worth knowing that 3.0 is also a substantial agent release (hooks on Agent, runtime tool selection, a unified sync/async pipeline), which puts Haystack in more direct competition with LangGraph than its reputation as a retrieval framework suggests. We have not evaluated that surface.

DSPy: a different premise entirely

DSPy comes from Stanford NLP and starts from a genuinely different premise. Its README bills it as "the framework for programming—rather than prompting—language models": instead of writing prompts, you declare what you want and let DSPy's optimizers tune prompts and weights against a metric.

It is worth evaluating if you are hand-tuning prompts and cannot tell whether a prompt change is an improvement. If what you cannot evaluate is the pipeline rather than the prompt, that is Haystack's problem rather than this one. It is not a drop-in LangChain replacement either: it solves a different problem, and adopting it means restructuring how you think about the pipeline.

The provider SDK, plus your own code

Worth ruling out before you reach for any framework here. If you make a handful of model calls, do some retrieval, and stop, the Anthropic or OpenAI SDK plus a vector store will be smaller and clearer than any framework here. This is also the honest destination if your complaint is breaking changes: fewer dependencies is the only change that actually reduces how much can break underneath you.

The trade is that you own retries, streaming edge cases, tool-call plumbing and observability. That works at small scale and gets expensive as scope grows.

What this list leaves out

This page is scoped to the frameworks people leave LangChain for when the complaint is about abstraction, retrieval or prompting. It is not a survey of every agent framework.

If your reason for looking is multi-agent orchestration specifically, the comparison set is different: CrewAI, AutoGen, the OpenAI Agents SDK, Google's ADK and Mastra for TypeScript teams are the names you will hit, and none of them are covered here. We have not evaluated them against this list, and saying so is more useful than padding the page with entries we cannot rank honestly.

What a migration involves

What ports cleanly: prompts, tool definitions, your vector store, your documents. What does not: chain and graph topology, memory and checkpoint state, callback and tracing integration, and every piece of operational knowledge your team built.

Budget for a possible retrieval quality regression too. Frameworks default to different chunking and retrieval strategies, so a like-for-like port can behave differently on day one. Have an evaluation set before you start, or you will not know whether the migration helped.

What we have not done, and what would refute this

We have not ported a real pipeline to any of these, and we have not benchmarked them on retrieval quality or latency. Everything above about fit comes from documentation and source rather than from production experience.

The claim this page rests on is that your destination follows from your complaint. If a survey of teams who left LangChain found they converged on one destination regardless of why they left, the table at the top is the wrong shape and a single recommendation would serve readers better. We know of no such survey.

Every star count on this page was read on 8 August 2026; the retrieval and agents category pages carry current figures.

Our first-party contribution here (gate 1b): the Haystack 3.0 finding. That 30 components moved out of core is in the release notes; that the nine evaluators were not among them we established by reading haystack/components/evaluators on main and checking each name against the moved list. On 14 August 2026 the three highest-ranking pages for this query (vellum.ai, zapier.com and orq.ai) carried none of it. Sourcing and corrections: editorial standards.