LangChain.dart: an unofficial Dart port of LangChain for Flutter apps
Build LLM-powered Dart/Flutter applications.
At a glance
- What is it?
- LangChain.dart ports the LangChain component model to Dart, splitting core abstractions, high-level chains and provider integrations into separate pub packages. It is the right fit when your LLM logic has to live inside a Dart or Flutter process, and the wrong fit when you need the Python ecosystem's breadth of integrations.
- Who is it for?
- Adopt LangChain.dart if your LLM calls must run inside a Dart or Flutter process and the providers you need already have their own langchain_* package, such as langchain_openai, langchain_google or langchain_ollama.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly Dart, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap LangChain.dart was written to fill
The README states the motivation directly: emerging LLM tooling is predominantly built for Python and JavaScript, and the scarcity of Dart and Flutter libraries that handle the complexity of working with LLMs has kept the Dart ecosystem from growing at the same rate. LangChain.dart is an unofficial Dart port of the Python LangChain framework, and its stated purpose is to abstract the work of talking to language models so that Dart and Flutter developers can build chatbots, RAG question answering, agents, summarization, translation and extraction without hand-rolling provider clients.
The audience is narrow and specific. If you are writing a Flutter app and want the LLM call, the prompt template and the retrieval step to live in the same process as the UI, this project exists for you. If your LLM work already runs in a Python service and Flutter only renders the result, the port buys you very little, because you would be duplicating a component model that already works on the other side of an HTTP boundary.
How the pub packages are split and why it matters
The ecosystem is modular by design, and the README is explicit that you should import only what you need. langchain_core holds the core abstractions plus the LangChain Expression Language, and the README says to depend on it if you are building a framework on top of LangChain.dart or interoperating with it. The langchain package holds higher-level chains, agents and retrieval algorithms, and it re-exports langchain_core so you do not need to declare that dependency yourself. langchain_community holds third-party integrations and community-contributed components that are not part of the core API.
Then there is a fourth tier. Popular integrations such as langchain_openai, langchain_google, langchain_anthropic, langchain_chroma, langchain_firebase and langchain_ollama have been moved into their own packages so they can be imported without pulling in the whole of langchain_community. That decision is the most consequential thing about the project's packaging. It means the dependency graph of a Flutter app stays small, but it also means the set of integrations you can use is exactly the set that has been published as a standalone package. There is no single artifact that gives you everything.
For a Flutter developer this split is mostly good news: the README's guidance is to depend on the integration-specific package when you want that integration, so a simple OpenAI chat screen does not drag in Chroma, Firebase and Anthropic. The cost is that version numbers move independently. The recent releases show langchain at v0.9.0 and googleai_dart at v3.0.0, which are different tracks entirely.
LCEL is the composition mechanism, not the components
The README describes three module groups. Model I/O gives a unified API across providers (OpenAI, Google, Mistral, Ollama and others are named), plus prompt templates, example selectors and output parsers for shaping inputs and interpreting outputs. Retrieval covers document loaders, text splitters, embedding models, vector stores and retrievers, which together ground a model's responses in your own data. Agents are described as bots that use an LLM to decide which available tools, such as web search, a calculator or a database lookup, to invoke for a task.
What ties these together is the LangChain Expression Language, documented at langchaindart.dev under an expression language section. LCEL is the part of the project that is genuinely load-bearing: without it you have a collection of provider clients and data utilities, and with it you have a way to compose them into a pipeline. The README's own framing is that components can be composed using LCEL, so the expression language is the abstraction worth evaluating first. If LCEL's primitives do not map onto the shape of your pipeline, the rest of the framework will not rescue the design.
One thing the README does not do is show a complete LCEL example inline. It links out to the documentation site instead. That is a reasonable choice for a README, but it means you cannot judge the ergonomics of the composition API from the repository front page alone.
Getting it into a Dart project
Installation follows normal pub conventions, and the package you add depends on how much of the framework you want. Adding langchain gives you the higher-level chains, agents and retrieval algorithms and exposes langchain_core transitively, which the README describes as the option for building LLM applications with LangChain.dart. Adding langchain_core alone is for building frameworks on top of LangChain.dart or interoperating with it. Adding a provider package such as langchain_openai, langchain_google, langchain_anthropic or langchain_ollama gives you that specific integration without the community bundle.
The README does not reproduce the exact pubspec dependency lines, so the concrete step is to resolve the package name against pub.dev and add it under dependencies in pubspec.yaml, then run dart pub get or flutter pub get depending on your project type. The documentation site at langchaindart.dev is where the getting-started material lives, including the expression language section the README points to. Because the README is truncated in the material available here, I cannot confirm the exact API surface for initialising a model client or the constructor names for prompt templates. Those details need to come from the docs site, not from this review.
Where the port model breaks down
The honest limitation is the one the README implies rather than states: this is an unofficial port, and a port tracks its source. When the Python LangChain API changes, LangChain.dart either follows or diverges, and the recent release history shows the project is still in the 0.x range for the main package. A pre-1.0 version number is not a defect in itself, but it does mean the maintainers reserve the right to make breaking changes, and the move of integrations out of langchain_community into separate packages is exactly that kind of change. If you pinned langchain_community expecting OpenAI support to live there, you have already had to migrate.
The second limitation is coverage. The README names OpenAI, Google, Mistral and Ollama as providers and lists Anthropic, Chroma and Firebase among the integration packages. That is a real set, but it is a subset of what the Python ecosystem offers, and the README's own description of langchain_community as holding components that are not part of the core API tells you the long tail is thinner here. If your architecture depends on a specific vector store or document loader that only exists upstream, the port is the wrong tool and you should keep that step in a service written in a language that has the integration.
The third is that the material available does not state a support policy, a deprecation window or a compatibility matrix between langchain and the integration packages. For a project where integrations version independently, that is the information a team needs before depending on it, and its absence from the README is a gap worth noting.
What you would use instead, and the actual difference
The most direct alternative is calling each provider's HTTP API from Dart yourself, using something like the official or community Dart SDK for that provider and your own prompt strings. The difference in approach is that you own the abstraction layer. You would write your own template rendering, your own retry and parsing logic, and your own retrieval glue, but you would have no dependency on a pre-1.0 port and no exposure to upstream API churn. For a single-provider app with one prompt and one output format, that is a smaller amount of code than it sounds, and it removes an entire category of upgrade work.
The other alternative is to keep the LLM pipeline in Python or JavaScript behind a service boundary and have Flutter call it over HTTP. That gives you the full upstream ecosystem, including integrations that have not been ported, at the cost of running and securing a second service and paying a network hop per call. The trade-off is clean: LangChain.dart keeps the pipeline in-process but narrows the integrations, while a backend service widens the integrations but moves the logic out of the app. Which one is correct depends on whether your bottleneck is latency and deployment simplicity or integration coverage.
Licence and the cost of tracking upstream
The repository is MIT licensed, which is permissive and imposes no copyleft obligation on your application. That is the same licence the badge in the README points to, and it is the kind of licence that fits commercial Flutter apps without a legal review of derivative-work questions. This is a description of the licence identifier, not legal advice; if your organisation has specific requirements, the LICENSE file in the repository is the authoritative text.
The maintenance cost is the part teams underestimate. Because integrations are separate packages with their own version numbers, an upgrade is not one bump in pubspec.yaml but potentially several, and each one can carry its own breaking changes. The release history shows langchain and googleai_dart moving on separate schedules, which is the pattern to expect. Budget for reading changelogs per package rather than per project, and treat the 0.x status of the main package as a signal that the API is still settling. The project is actively pushed to, with a commit as recent as September 2026 in the material provided, so the churn is the price of an actively developed port rather than a sign of abandonment.
Editorial conclusion
Adopt LangChain.dart if your LLM calls must run inside a Dart or Flutter process and the providers you need already have their own langchain_* package, such as langchain_openai, langchain_google or langchain_ollama. Do not adopt it if your pipeline depends on an integration that only exists in the Python or JavaScript ecosystem, or if you need a stable API surface: the project is at langchain-v0.9.0 and has already restructured its packages once by moving integrations out of langchain_community. Before committing, check pub.dev for the specific integration package you need, confirm it is published under the same versioning scheme, and read the LCEL documentation at langchaindart.dev to verify that the composition primitives match how you intend to chain prompts, models and parsers.
Community notes