Early LangChain shipped as a single package called `langchain` that bundled the abstract primitives (Runnables, prompts, output parsers) together with every provider integration (OpenAI, Anthropic, Cohere, Hugging Face, Pinecone, Weaviate, and dozens more).
That single package had two problems. First, every app that wanted to use even the smallest abstraction had to install dependencies for every vendor SDK in the catalogue. Second, any time one integration's vendor SDK shipped a breaking change, the whole `langchain` package had to release a patch. And integration churn was constant.
The modern split separates concerns. `langchain-core` is the small abstract layer: Runnables, prompts, output parsers, base interfaces. It depends on almost nothing. `langchain-community` houses contributed integrations that have not been promoted to their own packages. Provider packages like `langchain-openai`, `langchain-anthropic`, or `@langchain/openai` for JS ship only the relevant vendor SDK as a dependency and can release independently on the provider's cadence.
The split is a dependency-hygiene win, not a marketing or legal reorganisation.
The packaging split solves two coupled problems with monolithic LangChain: dependency bloat and release-cadence coupling.
**Dependency bloat.** When everything lived in one `langchain` package, importing the smallest abstraction (a `PromptTemplate`, a `Runnable`) implicitly pulled in transitive dependencies for every integration in the catalogue. Every vendor SDK, every vector-store client, every tool wrapper. Production apps that used a single provider were paying full-catalogue install time and image size.
**Release-cadence coupling.** Vendors ship breaking changes on their own schedules. When a single OpenAI SDK bump required a LangChain patch release, every other integration was effectively frozen until that patch shipped. The constraint multiplied with every integration added.
The split solves both. `langchain-core` is the small primitive layer (Runnables, prompts, parsers, base interfaces) with minimal dependencies. `langchain-community` is the contributor-driven shelf for integrations not yet promoted. Per-provider packages. `langchain-openai`, `langchain-anthropic`, ``langchain-google-vertexai``, the JS `@langchain/openai`, etc.. Own a single vendor SDK each and version on the vendor's cadence.
Marketing, foundations, and PyPI size limits are not the reasons. The pattern is the standard 'core + adapters' split that every large integration library converges on.
Quick reference
TL;DR
LangChain split into core + community + per-provider packages so apps only pull the vendor SDKs they actually use and provider integrations can ship on the vendor's release cadence.
Picture a hardware store that used to sell a single mega-toolbox with every tool ever made, even the ones you would never use. Lugging it around was painful and if any one tool was broken, the whole toolbox was held back. The store split the kit: a small core box with the handle and the basics, a community shelf with everyone's contributed gadgets, and separate cases for each brand's specialty tools. Now you grab just the basic kit plus the one brand case you need. When that brand ships a new tool, only their case updates. The rest of your gear stays the same.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
A throwaway script that uses three providers and you do not care about install size The legacy langchain import works; the split's wins are about production hygiene, not script ergonomics
Tutorial code where pinning specific provider packages would confuse readers more than help them Many docs still use the legacy paths because they are shorter; production code should diverge
A monorepo that already controls its dependency tree at the lockfile level The lockfile gives you the same hygiene; the import-path discipline is then a code-style concern, not a dependency concern
A migration in flight where touching every import is a risky big-bang change The legacy meta-package keeps working; migrate file by file as part of normal touches, not as a one-shot refactor
Quick scan · 2–4 min
Everything important, quickly.
5 minutes: what each split package contains, the two production wins, the legacy meta package trap, and the migration path.
Side-by-side
Package
What it contains
Release cadence
langchain-core
Runnables, prompts, parsers, base interfaces
Slow, stable
langchain-community
Contributor-maintained integrations not yet promoted
Medium, contributor-driven
langchain-<provider>
One vendor's chat models, embeddings, tools
Tracks the vendor SDK
langchain (meta)
Re-exports from the above for legacy import paths
Lags the underlying packages
Real-world examples
Real products, models, and research that use this idea.
1LangChain's January 2024 split announcement that explicitly cited dependency hygiene and per-provider release cadence as the motivations.
2`@langchain/openai` in the JS ecosystem ships independently from `@langchain/core`, mirroring the Python pattern with package-scoped namespaces.
3Companies running LangChain on AWS Lambda commonly shave hundreds of MBs off the deployment artifact by switching from `langchain` to `langchain-core` + the one provider package they use.
4LlamaIndex went through a similar reorganisation around the same time, splitting into `llama-index-core` plus per-integration packages. The same architectural pressure produced the same shape twice.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you migrate a large codebase from `from langchain.chat_models import ChatOpenAI` to the split imports?
Sign in or go Pro to see the approach for this follow-up.
QWhat does `langchain-community` actually buy you that the per-provider packages do not?
Sign in or go Pro to see the approach for this follow-up.
QHow does this split compare to LlamaIndex's reorganisation around `llama-index-core`?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Importing from `langchain` (the legacy meta-package) instead of `langchain-core` plus the specific provider packages, then wondering why your dependency tree pulls in vendor SDKs you do not use.