dspy vs langchain: optimizer versus integration layer
DSPy compiles a pipeline against your metric and dataset; LangChain wires models, tools and retrievers behind one interface. They are complementary, and many teams end up running DSPy modules inside a LangChain or LangGraph application.
At a glance
| Project | stanfordnlp/dspy | langchain-ai/langchain |
|---|---|---|
| Licence | MITPermissive: commercial use allowed | MITPermissive: commercial use allowed |
| Maintenance | Commits in the last six monthsLast push September 28, 2026 | Commits in the last six monthsLast push September 25, 2026 |
| Language | Python | Python |
| GitHub stars | 38,419 | 147,049 |
| Read more | Our analysisGitHub | Our analysisGitHub |
Which one to choose
Choose dspy if you already have a labelled dataset and a scoring function, your pipeline has several LM stages whose prompts you would otherwise hand-tune, and you can absorb the token cost of repeated compile runs.
Choose langchain if you need one interface across several model providers, a large catalogue of tool and retriever integrations, or an agent loop with state and checkpointing, and you are willing to carry a heavier dependency tree.
Two different layers, not two versions of the same thing
DSPy is a compiler for LM programs. The README calls it the framework for programming rather than prompting language models, and describes writing compositional Python code and using DSPy to teach the LM to deliver high-quality outputs. The unit of work is a module with typed inputs and outputs, and the artifact you care about is the compiled program: instructions and demonstrations (and, per the README, weights) that the optimizer has selected. The papers listed in the README, from Demonstrate-Search-Predict through the October 2023 DSPy paper to the July 2025 GEPA work, are all about how to search that space rather than about how to connect to a provider.
LangChain sits one level down. Its README describes a standard interface for models, embeddings, vector stores and more, with model interoperability as an explicit goal, and the quickstart is a single call: init_chat_model with a provider string such as openai:gpt-5.5, then model.invoke. The value is breadth: one shape for many providers, plus integrations for tools, retrievers and vector stores, and an ecosystem the README lists as Deep Agents, LangGraph, Integrations, LangSmith and LangSmith Deployment.
That difference decides most of the rest. LangChain answers who talks to the model and through which abstraction. DSPy answers what the prompt should be, given examples and a way to score them. Neither replaces the other. A DSPy program still needs model access and, if it retrieves, a retriever; LangChain is one source of both. A LangChain agent still has prompts that someone has to write, and DSPy can take over that job for the stages that have a measurable objective.
Getting each one running, and what blocks the install
DSPy installs with pip install dspy, or pip install git+https://github.com/stanfordnlp/dspy.git for the latest from main, per the README. The earlier analysis records a Python constraint of >=3.10, <3.15 declared in pyproject.toml, and notes that a mismatch stops the install before anything else matters. There is no server, no config file and no project scaffold: you import the package, define modules, and run an optimizer. The real setup cost is not installation but data. The optimization loop needs a dataset and a scoring function, and the earlier analysis is blunt that DSPy is useless without both. Budgeting also matters, because every compile step spends tokens against whatever model you point it at.
LangChain installs with uv add langchain in the README quickstart. Provider credentials are handled per integration, and init_chat_model takes a provider string, so the first working call is short. The friction is elsewhere: choosing among providers and integration packages, and pinning a release. The repository's recent releases include langchain==1.4.0a1 and 1.4.0a2 alongside langchain==1.3.18, and the earlier analysis advises against pinning an alpha build. If you need an agent that plans, uses subagents or touches a file system, the README points to Deep Agents as a higher-level package built on LangChain, and to LangGraph for low-level orchestration. That is a second decision before you write application code.
In short, DSPy front-loads cost into data and evaluation. LangChain front-loads it into dependency and provider choices.
What each one costs you at runtime and in operations
DSPy moves spend from development into compile time. The README states that the framework offers algorithms for optimizing prompts and weights, and the earlier analysis warns that repeated evaluation runs against a paid API are the main budget risk. Once compiled, a DSPy program is ordinary Python: you can save the compiled artifact and serve it, and the per-request path is a normal model call. The operational question is how often you recompile. Any change to the metric, the training set or the model invalidates the artifact, and each recompile is another round of evaluation. The README does not document a rollback procedure for compiled programs, so versioning the artifact is something you design yourself.
LangChain's runtime cost is indirection plus, for stateful agents, orchestration. The README frames LangGraph as the framework for controllable agent workflows and LangSmith Deployment as the platform for long-running, stateful workflows. Those are the pieces you reach for when an agent must survive a process restart or pause for a human. The trade is a larger dependency surface: the earlier analysis names a small dependency tree as the thing LangChain is a poor fit for, and notes that every package in the request path becomes yours to track. Provider swaps are the payoff, and the README states model interoperability as a goal, but swaps are cheap only when the integration you need exists. The earlier analysis lists checking that init_chat_model accepts your provider string and that your integration appears in the Integrations documentation as pre-commit checks.
Neither project's README documents autoscaling, rate-limit handling or cost controls in detail. For both, treat those as application concerns.
Where dspy is the weaker choice
If you have one prompt against one model, DSPy is overhead. There is nothing to optimize without a metric, and a single call has no pipeline to compile. The earlier analysis says to skip DSPy when you only need a thin wrapper around one chat call, and that is the common case for prototypes and small internal tools.
The second weakness is evaluation cost. Optimization is a search, and search costs calls. Teams without a cheap scoring function, or without a cached or local model to evaluate against, can spend more on a compile than the prompt was ever worth. That is a budget constraint, not a bug, but it rules DSPy out for some projects.
Third, the payoff is indirect. DSPy does not give you a nicer API for calling models, a tool registry or a retriever catalogue. It gives you a better prompt and a reproducible way to have found it. If what you actually need is provider coverage, DSPy does not provide it. The README directs readers to dspy.ai for documentation and lists research papers, which is the right shape for a framework whose behaviour is defined by its optimizers, but it means you will read papers or docs rather than copy integration snippets.
Where langchain is the weaker choice
LangChain is the wrong tool when the abstraction earns nothing. A single provider, a single prompt and no retrieval do not benefit from a common interface; they just inherit the dependency tree. The earlier analysis states this directly: do not adopt LangChain if your application is a single prompt against a single provider, or if every dependency in the request path must be yours.
The integration catalogue cuts both ways. The README presents a vast library of integrations as a strength, and for provider swapping it is. But integrations are code you did not write and must track, and the earlier analysis makes verifying that your specific integration is listed a pre-commit step rather than an assumption. The README's own framing, that components are interoperable and that decisions are future-proofed as the technology evolves, describes a bet on the abstraction layer holding. That bet is reasonable for multi-provider applications and unnecessary for single-provider ones.
There is also a release-management tax. Recent releases include two 1.4.0 alpha builds, and the earlier analysis advises pinning a non-alpha release. Alpha builds in the release feed mean the version you pick deserves a look before it goes into production. Finally, the README's ecosystem section mixes the open-source framework with commercial products such as LangSmith and LangSmith Deployment. The framework is MIT licensed and usable standalone, per the README, but the fullest described workflow assumes those products.
Licence and maintenance: what the repository facts support
Both projects are MIT licensed. That permits commercial use, modification and redistribution under the usual MIT terms, and for most teams it removes licence review from the decision. Neither repository is archived.
On maintenance, the last push for both is 2026-09-20, which is one day before today's date, so both are being pushed to now. DSPy's recent releases are 3.3.1 on 2026-08-21, 3.3.0 on 2026-08-03 and 3.3.0b1 on 2026-05-28. LangChain's recent releases are langchain==1.4.0a2 on 2026-08-28, langchain==1.4.0a1 on 2026-08-27 and langchain==1.3.18 on 2026-08-27. Both release feeds are current, and the practical difference is release discipline: DSPy's most recent listed release is a stable 3.3.1, while LangChain's two most recent listed releases are alpha builds with a stable 1.3.18 just behind them.
Neither README documents a support window, a deprecation policy or a long-term support branch. For a dependency that sits in the request path, that is a gap worth noting: pin versions and read release notes before upgrading. The star counts in the table above differ by a wide margin, which reflects adoption of an integration layer versus an optimization framework, but neither count tells you whether the maintainers will answer your issue.
Choosing for a concrete project
For a RAG pipeline with a fixed model and a labelled question set, DSPy is the better starting point. You have the two things it needs, a dataset and a scoring function, and the compile step replaces weeks of manual prompt iteration. If the same pipeline must run against several providers, put the retrieval and model access behind LangChain and keep the DSPy modules on top; the earlier analysis of DSPy treats the optimizer as the point and the rest as plumbing, which is exactly the part LangChain standardizes.
For a customer-facing agent that calls tools, keeps state across turns and may pause for approval, start with LangChain and LangGraph. The README points to LangGraph for controllable agent workflows and Deep Agents for planning, subagents and file system use. DSPy can optimize individual stages inside that agent later, once you have logs and a metric, but it will not give you the loop, the checkpointing or the tool registry.
For a single prompt against a single provider, use neither. Write the call directly. For a prototype that may become multi-provider, LangChain's init_chat_model is a low-cost hedge, but only if you actually intend to swap.
A reasonable combined pattern: LangChain for the edges (provider clients, retrievers, tools), DSPy for the middle (the stages with measurable outputs). That split keeps the optimization where it pays and the integration where it is needed.
Bottom line
Pick DSPy when a dataset and a metric exist and prompt quality is the bottleneck; pick LangChain when provider coverage, tools and agent state are the bottleneck; for a single prompt on a single provider, write the call yourself. Before committing, verify three things: that your Python version falls inside DSPy's declared >=3.10, <3.15 range, that init_chat_model accepts the provider string you intend to use and that your integration is listed in the Integrations documentation, and that the release you pin is not one of the 1.4.0 alpha builds. Both projects are MIT licensed and both were pushed to on 2026-09-20, so the decision rests on architecture and operating cost, not on maintenance risk.