Single input, single output, synchronous. The simplest call shape
List of inputs processed in parallel up to `max_concurrency`, results in input order
Single input yielding incremental output chunks to a synchronous iterator
Single input yielding chunks via an async generator suitable for `async for`
List of inputs in an async context with the same input-order guarantee as batch
Every LCEL Runnable in LangChain, a model, a prompt template, a chain composed with the pipe operator, exposes the same set of standard call methods. The five core ones map onto two axes.
**Axis 1: how many inputs.** invoke and stream (plus their async siblings) take a single input. batch and abatch take a list of inputs.
**Axis 2: how the output arrives.** invoke returns a complete result synchronously. stream yields chunks incrementally to a synchronous iterator. The `a` prefix (`.ainvoke`, `.astream`, `.abatch`) marks the async-context version, which works inside `async def` functions and returns awaitables or async generators.
Matching the five methods:
- `.invoke(input)`. One input, complete sync output.
- `.batch(inputs)`. List of inputs, parallel execution up to a configurable concurrency cap, results returned in input order.
- `.stream(input)`. One input, chunks via a sync iterator.
- `.astream(input)`. One input, chunks via an async generator (`async for chunk in chain.astream(x)`).
- `.abatch(inputs)`. List of inputs in an async context, parallel up to the same concurrency cap, results in input order.
LCEL standardises the call surface across every Runnable so that a `ChatPromptTemplate`, a chat model, a chain, and a custom function all expose the same five core methods. The methods are arranged on a 2x3 grid where one axis is input shape (single vs list) and the other is output delivery (sync complete, sync streaming, async).
**The five methods.**
- `.invoke(input)`. Single input, blocks until the full output is ready, returns it synchronously. The simplest shape.
- `.batch(inputs)`. List of inputs, runs them in parallel up to a configurable concurrency cap (default 5), returns a list of outputs in input order even though execution interleaves. The parallelism is essentially free for IO-bound LLM calls.
- `.stream(input)`. Single input, returns a synchronous iterator that yields chunks as they arrive from the provider. Used for token by token UI rendering in non-async code.
- `.astream(input)`. Async variant of stream. Returns an async generator; consumed with `async for chunk in chain.astream(x)`. The right shape for web frameworks (FastAPI, Starlette) where the request handler is `async def`.
- `.abatch(inputs)`. Async list-input. Same input-order guarantee as batch, runs inside an async context.
Matching the pairs is a name-decomposition exercise. The `a` prefix → async context. `batch` in the name → list input. `stream` in the name → incremental output. Anything without `batch` or `stream` is the single-input complete-output shape.
Quick reference
TL;DR
Every LCEL Runnable exposes five core call methods on a 2-axis grid: input is single or list; output is sync, async, or streaming chunks; the `a`-prefix marks async.
Think of a coffee shop with one barista. You can place a single order and wait at the counter (invoke). You can hand over a list of five orders to be prepared together (batch). You can ask for a drip coffee where the cup fills sip by sip while you watch (stream). The same three shapes exist in an async version of the shop where you can walk away and come back when notified (astream and abatch). One axis is 'how many drinks am I ordering,' the other is 'do I want it now, or to receive it as it pours.' The five LCEL methods are exactly the cells in that grid.
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.
Calling the batch method against a provider that does not support concurrent requests well Hitting rate limits cancels the parallelism gain; lower max-concurrency or back off to serial single-shot calls with retries
Using the sync stream method inside an async server handler The sync iterator blocks the event loop; reach for the async stream method and async-for instead
Streaming a step that does not yield meaningfully (e.g. a deterministic output parser) You pay the streaming overhead with no UX benefit; a plain single-shot call is simpler
Per-step observability needs beyond what the async stream method exposes The async event-stream and async log primitives are the right choice for structured per-node events
Quick scan · 2–4 min
Everything important, quickly.
5 minutes: the two-axis grid, the five core methods, why `.batch` is free parallelism, and when `.astream_events` beats plain `.astream`.
Code example
python
from langchain_anthropic import ChatAnthropic
from langchain_core.prompts import ChatPromptTemplate
prompt = ChatPromptTemplate.from_template("Summarise {topic} in 3 bullets.")
chain = prompt | ChatAnthropic(model="claude-sonnet-4-6")
# 1. Single sync call
result = chain.invoke({"topic": "OpenTelemetry"})
# 2. List of inputs, parallel up to max_concurrency
results = chain.batch([{"topic": t} for t in topics], config={"max_concurrency": 8})
# 3. Sync streaming for a CLI
for chunk in chain.stream({"topic": "vector databases"}):
print(chunk.content, end="", flush=True)
# 4. Async streaming for FastAPI / SSE
async def handler(topic: str):
async for chunk in chain.astream({"topic": topic}):
yield chunk.content
Side-by-side
Method
Input shape
Output delivery
Async?
Typical use
`.invoke`
Single
Complete value
No
Simple sync call
`.batch`
List
List of complete values, in order
No
Parallel sync evaluation
`.stream`
Single
Sync iterator of chunks
No
CLI / sync UI streaming
`.astream`
Single
Async generator of chunks
Yes
FastAPI SSE / WebSocket
`.abatch`
List
List in input order
Yes
Async eval / web batch jobs
Real-world examples
Real products, models, and research that use this idea.
1FastAPI servers commonly expose LCEL chains via `astream` mounted on an SSE endpoint, with each token surfaced to the browser as a Server-Sent Event.
2LangChain's evaluation tooling (LangSmith and the open-source evaluators) defaults to `.abatch` over the eval set so a 1000-example evaluation finishes in roughly `1000 / max_concurrency` per-call latencies.
3LangChain's `RunnableParallel` and `RunnableLambda` both implement the same five methods, which is why `prompt | model | parser` and `prompt | RunnableLambda(my_fn)` are interchangeable from a consumer perspective.
4Anthropic's, OpenAI's, and Google's chat APIs all expose native streaming endpoints; LangChain's `.stream` / `.astream` are thin wrappers that map the provider's streaming protocol to the uniform iterator interface.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat is the difference between `.astream` and `.astream_events`?
Sign in or go Pro to see the approach for this follow-up.
QHow does `.batch` preserve input order when execution is interleaved across concurrent workers?
Sign in or go Pro to see the approach for this follow-up.
QWhat controls `max_concurrency` and what is the right default?
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
Calling `.invoke` in a hot loop over a list of inputs when `.batch` would parallelise the same work for free, then debugging 'why is my pipeline slow?'