LangChain vs LlamaIndex vs Writing It Yourself: What Abstraction Costs

The langchain package recorded 254.5 million downloads in the month to 27 August 2026. In the same window OpenAI's own agents SDK recorded 39.7 million and llama-index-core recorded 14.6 million. LangChain vs LlamaIndex is now the wrong question to open with. The real decision is how much abstraction between your code and the model you are willing to own for the next two years.

What the three options actually are

Most comparisons treat this as a three-way pick between two libraries and a blank file. That framing is out of date, because all three options have moved since 2024 and two of them have moved toward each other.

LangChain is two products, and the distinction matters

LangChain today ships a high-level agent constructor and a lower-level orchestration runtime called LangGraph. Harrison Chase, the company's co-founder, drew that line himself in April 2025. He described LangGraph as an orchestration framework with a series of agent abstractions built on top, and argued that the hard part of reliability is controlling what reaches the model at each step.

That is a more careful position than the marketing suggests. It also concedes the central point of the critics, which is that agent abstractions are the risky layer and orchestration is the useful one.

LlamaIndex is a retrieval framework with an agent layer added later

LlamaIndex started as an indexing and retrieval library and still leads with document work. Its own agent story arrived as Workflows, released as version 1.0 on 30 June 2025 by Massimiliano Pippi and Logan Markewich. They shipped it as a separate package with a limited set of dependencies, usable outside the LlamaIndex ecosystem entirely.

Read that decision carefully. The company that owns the framework chose to unbundle its orchestration layer from its retrieval layer, because developers wanted the flow control without the rest.

The third option is not zero abstraction

Nobody serious writes raw HTTP calls to a model endpoint. Writing it yourself means importing the provider SDK, a validation library and a queue, then owning the loop that sits between them. Anthropic put this plainly in December 2024, saying developers should start by using LLM APIs directly because many patterns take only a few lines of code.

The download numbers say the default has already moved

Package downloads are the only continuously published adoption signal in this market, so they are worth reading even with their flaws. Here is what they said on the morning this was written.

Three readings hold up. LangChain remains the distribution leader by a wide margin and nothing in this post disputes that. LangGraph at 70.3 million is closing on a third of the main package, which is consistent with teams importing the runtime and skipping the agent wrapper. And openai-agents, from a repository created on 11 March 2025 and now carrying 28,985 stars, has passed both LlamaIndex packages combined.

Downloads are not users, and the gap is large. Every figure above counts machines, not people. A single continuous integration pipeline can install a package hundreds of times a week, and container image builds inflate popular packages more than niche ones. Absolute values are therefore close to meaningless.

Ratios between packages of similar popularity are more defensible, because the CI distortion applies to both sides. That is why the comparison to watch here is openai-agents against llama-index-core, and not any single number on its own.

Downloads from pypistats.org, stars and issue counts from the GitHub API, both retrieved 27 August 2026. Star counts are cumulative since repository creation and reward age, so LlamaIndex leading OpenAI on stars while trailing on downloads is expected rather than contradictory.

Where a framework genuinely earns its place

The strongest case for importing a framework has nothing to do with saving keystrokes on a prompt. It is about the machinery that surrounds a long-running process.

Durable execution is the honest one. If an agent runs for 40 minutes across a dozen tool calls, it will be interrupted by a deploy, a rate limit or a timeout. Recovering from step nine without replaying steps one to eight is real distributed-systems work. Chase makes this argument directly, noting that features like human-on-the-loop review and model-specific observability are awkward to build alone.

I would extend it to two more cases. Teams running many similar agents benefit from one shared runtime rather than five hand-rolled loops that drift apart. And teams with a compliance obligation to replay a decision need checkpointing that someone else maintains and tests.

What none of these cases require is the agent constructor. You can import the runtime and keep your own control flow, which is exactly the split the download figures suggest is happening. If you are choosing between a framework and a hosted product rather than between two libraries, the trade-offs are laid out in the piece on when to build coding agents rather than buy them.

The abstraction cost, itemised

Frameworks are usually evaluated on what they add. The costs are less visible because they arrive later, after the person who chose the framework has moved to another project.

Debugging happens through a wrapper

Anthropic's guidance names this failure precisely. Frameworks often create extra layers of abstraction that can obscure the underlying prompts and responses, making them harder to debug. The same document warns that incorrect assumptions about what sits under the hood are a common source of customer error.

This is the cost that compounds. When output quality drops, the first question is always what text the model actually received. If answering it means reading library source, every quality investigation gets slower, and quality is the blocker 33% of practitioners named.

Version churn is a real maintenance line

LangChain reached 1.0 on 22 October 2025 and the release was not cosmetic. LLMChain, ConversationChain, MultiQueryRetriever, the indexing API, the hub module and the community re-exports all moved into a separate langchain-classic package. Objects already marked deprecated were deleted outright.

That was the right call for the library and it was still a migration someone had to schedule. Any framework you adopt is a bet that its maintainers will keep making decisions you can live with, and you have no vote.

Provider abstraction has a shelf life

The most-cited reason to adopt a framework is portability across model providers. I think this is the weakest argument on the list. Provider APIs have converged on tool calling and structured output, so the switching work has shrunk on its own, and the parts that have not converged are the parts frameworks normalise least well.

Reasoning traces, prompt caching semantics, citation objects and server-side tools still differ in ways that leak. A normalisation layer that covers 90% of a provider's surface leaves you writing provider-specific code anyway, on top of the abstraction rather than instead of it.

The 80% wall is a scheduling problem, not a quality problem

The most useful description of what goes wrong comes from Dex Horthy's 12-factor agents, a document with 25,511 stars on GitHub. His account of the failure is a sequence, not a verdict. A team adopts a framework, moves quickly, reaches roughly 70% to 80% quality, then discovers that the last stretch requires control the framework does not expose.

His second observation matters more for architecture. Most products marketed as agents are, in his words, mostly deterministic code, with LLM steps sprinkled in at just the right points. If that is true, the majority of an agent codebase is ordinary software that a framework was never needed for.

The commercial version of this problem is worse than the technical one. The wall is hit near launch, when the team is least able to spend three weeks on an architectural rewrite. Frameworks do not cause bad agents. They move the cost of the decision to the worst possible week.

The counter-discipline is to find your ceiling before you commit, which is what a real readiness test does. The checks worth running are set out in the piece on the tests a proof of concept has to survive.

What writing it yourself means in 2026

The phrase sounds heroic and describes something fairly boring. A thin custom layer is a few hundred lines that most teams could review in an afternoon.

You keep the imports that do genuinely hard things. The provider SDK, because it handles streaming, retries and transport. A schema library for tool arguments. A retrieval library if you are doing document work, and LlamaIndex is a reasonable answer there. A queue or workflow engine if runs are long. An observability layer, because agents drift in production in ways offline tests never show.

You write the parts that encode your product. The loop that decides when to call a tool. The message list, in a shape you chose. The tool dispatch table. The error compaction that turns a stack trace into something a model can act on. The place where a human approves an action, which is a product decision before it is an engineering one, as the piece on designing the human review step argues.

A test you can run before the architecture is fixed

Arguments about frameworks go in circles because both sides are describing different projects. These four questions separate them. Answer them about your project, not about the category.

My own rule sits in the third row. Below about 500 lines of orchestration, I would not start a new agent on a framework's agent abstraction in 2026. Above it, and with long-running state, I would import the orchestration runtime and still write my own control flow on top. That is not a compromise position, it is the split the two camps already agree on once you separate the layers. Where several agents have to coordinate, the tooling landscape is mapped in the review of agent orchestration and automation tools.

Where this argument is weakest

Every post arguing that frameworks are overrated skips this part, so here it is.

The case for the framework, put fairly

LangChain is not a hobby project losing an argument. It raised $125 million at a $1.25 billion valuation on 20 October 2025, led by IVP, and reported 90 million combined monthly downloads for LangChain and LangGraph alongside use at 35% of the Fortune 500. LangSmith trace volume was reported at 12 times the prior year. Those are the numbers of a tool doing real production work.

There is also a survivorship problem in the critique. The teams who write blog posts about removing a framework are the teams whose requirements outgrew it. The much larger group whose requirements did not outgrow it writes nothing, because a project that shipped on time is not a story.

What the framework sceptics get wrong

The rewrite is not free and it is usually costed at zero. A hand-rolled loop that a senior engineer wrote in a week becomes a load-bearing internal framework within six months, with no documentation, no external maintainers and one person who understands it. That is a real risk transferred, not a risk removed.

Sceptics also overstate how much of a framework you must adopt. Importing LangGraph for durable execution while writing your own prompts is a supported pattern, not a hack, and it collects most of the benefit at a fraction of the abstraction.

The part nobody can settle

There is no public dataset comparing defect rates, delivery time or cost between framework-based and custom agent codebases. The download figures here measure distribution, not outcomes. The 80% wall rests on practitioner accounts rather than measurement, and practitioner accounts are selected for drama.

So treat every claim in this post as a prior to test against your own project rather than a finding. The right response is a measurement, and the way to build one is covered in the piece on standing up an evaluation suite you can trust.

Frequently asked questions

Where to start this week

Two things, both doable before your next planning meeting.

First, add one line of logging to your existing agent that writes the exact payload sent to the model on every call, then read a day of it. If getting that line to work is hard, you have measured your abstraction cost directly and you did not need an opinion to do it.

Second, count the lines in your orchestration path, excluding tools and prompts. If the number is under a few hundred, the framework in your dependency list is carrying less weight than the migration you will owe it. If the number is large and the runs are long, keep the runtime and take back the control flow.

Related reading