The | overload composes two Runnables into a new Runnable: prompt | model | parser becomes one object whose .invoke, .batch, .stream, and .astream are derived for free from the underlying steps. It replaced the Chain subclass hierarchy because the old approach required a new class per chain shape; LCEL gets the same composition with one operator and gives you batch/stream/async behavior automatically, a property the old Chain classes had to opt into individually.
**LCEL** stands for LangChain Expression Language. The pipe operator `|` is Python operator overloading on the **Runnable** interface: every step (prompt template, model, output parser, retriever, custom function wrapped as `RunnableLambda`) implements the same Runnable contract.
The contract has four methods: invoke (single call), batch (many inputs in parallel), stream (yield tokens as they arrive), and astream (async streaming). When you write `prompt | model | parser`, the operator builds a new Runnable that delegates each of those methods through the underlying steps. You get batch and streaming behavior for free, you did not write a single line to enable them.
This replaced the old Chain class hierarchy where every chain shape (LLMChain, RetrievalQA, ConversationalRetrievalChain) was its own subclass. Adding a new shape meant subclassing Chain and reimplementing the same boilerplate. LCEL collapsed all of that into one operator and one interface, and gave you batch and streaming as built-in properties of the composite, not as features each subclass had to opt into.
**LCEL's `|` overloads `__or__` on the Runnable interface**, composing two Runnables into a new one. The composite is itself a Runnable, so chains nest, branch (`RunnableParallel`), and conditionally route (`RunnableBranch`) cleanly without new class hierarchies.
The real win is the four-method contract every Runnable exposes: invoke, batch, stream, astream. When you compose `prompt | model | parser`, the composite gains all four for free, derived from the underlying steps. The batch method runs the chain in parallel across many inputs, stream yields tokens as the model produces them, astream does the same in async. Without LCEL, every old Chain subclass had to opt into batch and streaming individually, and most did not, which is why pre-LCEL streaming UX was so painful.
The Chain class hierarchy was the older abstraction: one class per chain shape. That worked for the small set of canonical chains but did not scale to arbitrary composition. LCEL replaced the hierarchy with one operator and one interface, and made batch and streaming first-class properties of every composite. That single change is what made modern LangChain ergonomic enough for production chat UIs and the foundation of the LangGraph stack on top.
Quick reference
TL;DR
The | overload composes Runnables into a new Runnable whose invoke, batch, stream, and async methods are derived for free, replacing per-shape Chain subclasses with one operator.
Picture a kitchen with three appliances: a mixer, an oven, and a slicer. The old way of making a sandwich shop meant building a single combo-appliance for every menu item: a 'meatball-sub maker,' a 'panini maker,' each one a different machine. LCEL is the moment someone realized you could just snap any three appliances together with a standard plug. Snap prompt then model then parser, and the line you assembled works as one machine. Want to do many sandwiches at once or watch them come out one slice at a time? The standard plug already supports that.
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.
Tiny two-step pipeline where a raw provider SDK call is shorter and clearer LCEL adds Runnable wrapping and a layer of abstraction that buys nothing when there is no batch, stream, or fallback need.
A pipeline with non-trivial control flow (branches, loops, human approval) LCEL is composition for linear and parallel shapes, LangGraph StateGraph is the right tool when you need conditional edges, checkpoints, or interrupts.
A step that fundamentally cannot stream (whole-output JSON validator, large file processor) The composite chain becomes effectively invoke-only at that boundary, the streaming win disappears and a simpler structure may be clearer.
Quick scan · 2–4 min
Everything important, quickly.
5 to 7 min: Runnable interface + the four-method contract + how | composes + what Chain hierarchy it replaced + relationship to LangGraph and LangSmith.
Real-world examples
Real products, models, and research that use this idea.
1LangChain core ships RunnableSequence, RunnableParallel, RunnableBranch, and RunnableLambda as the canonical LCEL primitives.
2LangServe wraps any Runnable into a FastAPI endpoint, the four-method contract maps onto invoke, batch, stream, and astream HTTP routes directly.
3LangSmith trace UIs visualize LCEL chains as nested Runnables, with per-step spans for every link in the pipe expression.
4LangGraph StateGraph nodes are Runnables under the hood, so an LCEL chain is a legal node and the pipe operator composes inside graphs.
5Vercel AI SDK adapters convert LCEL .stream output into RSC stream parts, the streaming contract is what makes the integration straightforward.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does LCEL handle parallel branches that produce structured output?
Sign in or go Pro to see the approach for this follow-up.
QWhat breaks if a step in the chain cannot stream?
Sign in or go Pro to see the approach for this follow-up.
QHow does LCEL interact with LangSmith tracing?
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
Thinking of `|` as a Python pipe for shell-style data flow. It is operator overloading on a Runnable interface, not Unix piping.