LCEL (LangChain Expression Language) is LangChain's declarative composition syntax. It overloads the | (pipe) operator on Runnables so chain = prompt | model | parser composes them into a new Runnable. The composed Runnable inherits invoke (single input), batch (parallel over a list, preserves input order), stream (token-chunk iterator), astream (async generator), batch_as_completed, and automatic tracing through the callback system. LCEL replaced the older Chain class hierarchy (LLMChain, SimpleSequentialChain) in modern LangChain. Those are now legacy and discouraged.
LangChain in 2022 had a problem. Every common pattern, prompt to LLM, prompt to LLM to parser, retrieval to prompt to LLM, was a different class. `LLMChain`, `SimpleSequentialChain`, `SequentialChain`, `RetrievalQA`, and so on. Each class had its own constructor signature, its own way to add streaming, its own way to handle async, and behavior drift between them was frequent.
LCEL, LangChain Expression Language, is the rewrite that fixes this. Every piece (a prompt template, a chat model, an output parser, a retriever, a tool) implements the same `Runnable` interface. The interface includes `invoke` for single inputs, `batch` for parallel input lists, `stream` for token by token output, and `astream` for the async version. The composition operator is `|` (the pipe), borrowed from shell pipelines. Compose with `chain = prompt | model | parser` and you get a new Runnable that supports all the same operations.
The practical impact: one mental model instead of thirty. The same code reads naturally, switches between sync and async without restructuring, and traces through LangSmith uniformly.
The old Chain classes are now legacy. New code should use LCEL exclusively.
LCEL is LangChain's declarative composition layer. The concrete syntax is the overloaded `|` operator on the `Runnable` base class: `chain = prompt | model | parser` builds a composed Runnable that pipes the output of each component into the next.
The substance, though, is the unified interface. Every Runnable supports invoke, batch, stream, astream, batch_as_completed, and the callback system that drives LangSmith tracing. Composition preserves all of these. The composed chain you got from `|` supports `.batch([...])` and `.stream({...})` automatically, no wrapping required. This means a single piece of code can serve a single-request API, a batch worker, and a streaming chat endpoint without restructuring.
LCEL replaced the older Chain class hierarchy (LLMChain, SimpleSequentialChain, SequentialChain, RetrievalQA, and dozens more), which suffered from inconsistent constructors, ad-hoc streaming support, and behavior drift between subclasses. Those classes still exist but are marked legacy; the migration story is to express them as Runnable compositions.
The lesson is composition over inheritance. A single small interface implemented by everything beats a deep class hierarchy where each combination needs its own type.
Quick reference
TL;DR
LCEL replaced LangChain's old Chain class tree with a single pipe-composable Runnable interface that hands you batch, stream, and async for free.
Picture a kitchen where every appliance used to need its own kind of plug, toaster plug, blender plug, kettle plug, and you needed an adapter to chain any two. LCEL is the move to one universal socket. Plug a prompt into a model into a parser with the same connector. Now whatever you build can be turned on one at a time, in a big batch, streaming, or asynchronously, without you wiring anything extra. Before LCEL, each combination needed its own special chain class. After LCEL, it is one line and the runtime features come along for the ride.
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.
Single chat completion call where you do not need any composition LCEL adds a Runnable wrapper around what could be a direct model SDK call; for a single one-shot, the SDK is shorter and has lower import weight
Workloads with complex branching control flow and durable state LCEL composes pipes well but does not model loops or persistent state. That is LangGraph's job; trying to express a stateful agent in pure LCEL gets ugly
TypeScript projects that need first-class streaming UI primitives Vercel AI SDK ships TS-first streaming helpers and React hooks; LangChain.js Runnables work but are heavier than the typical TS app needs
Quick scan · 2–4 min
Everything important, quickly.
3 minutes: define LCEL and the pipe operator, name the five Runnable methods that come free with composition, identify the legacy Chain classes it replaced, and frame the architectural move as composition over inheritance.
Code example
python
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_openai import ChatOpenAI
prompt = ChatPromptTemplate.from_template('Summarise in one paragraph: {text}')
model = ChatOpenAI(model='gpt-4o-mini')
chain = prompt | model | StrOutputParser()
# Same chain, four call patterns, all free from composition
out_single = chain.invoke({'text': 'A long article...'})
out_batch = chain.batch([{'text': a}, {'text': b}, {'text': c}])
for token in chain.stream({'text': 'A long article...'}):
print(token, end='', flush=True)
# async usage
# async for token in chain.astream({'text': '...'}): ...
# Stacking: fallbacks, retries, structured output all return Runnables
robust = chain.with_fallbacks([prompt | ChatOpenAI(model='gpt-4o') | StrOutputParser()])
Real-world examples
Real products, models, and research that use this idea.
1LangChain's official quickstart for chat apps is now pure LCEL, no Chain subclasses
2LangSmith traces visualize LCEL chains as a graph because the Runnable interface exposes the necessary metadata
3Production teams running Claude Opus 4.7 and GPT-5.5 use LCEL's with_fallbacks to fail over between providers
4Migration guides from LangChain 0.0.x to 0.1+ are largely 'rewrite your Chains as Runnables'
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy is composition over inheritance the right call for a framework like LangChain?
Sign in or go Pro to see the approach for this follow-up.
QHow does LCEL relate to LangGraph?
Sign in or go Pro to see the approach for this follow-up.
QWhen does a long LCEL chain become a readability liability?
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
Treating LCEL as 'just nicer syntax'. The real payload is the unified Runnable interface that makes batch, stream, and async work uniformly across every composition.