LangChain/Core Concepts
Intermediate12 min

Standard Content Blocks

LangChain v1 normalizes every provider's output into standard content_blocks — one API for text, reasoning, citations, tool calls, and images across Anthropic, OpenAI, and Google.

Quick Reference

  • →content_blocks is always a list of TypedDicts — access fields with block['type'], not block.type
  • →Block types: text, reasoning, thinking, citation, tool_call, web_search_call, image, audio
  • →Replaces per-provider additional_kwargs parsing for reasoning, citations, and multimodal output
  • →.text is a property (not a method) — returns concatenated text from all text blocks
  • →HumanMessage(content_blocks=[{'type':'text','text':'...'},{'type':'image','url':'...'}]) for multimodal input
  • →LC_OUTPUT_VERSION=v1 makes .content return blocks instead of raw provider format
  • →content_blocks coexists with .content — backward-compatible, no opt-in required to read it
  • →Guard every block access: check block['type'] before accessing type-specific fields

When to Use Content Blocks (and When Not To)

Standard content blocks exist to solve one problem: every provider returns reasoning traces, citations, and images in a different format, so multi-provider code needed separate parsing for each. Before LangChain v1, accessing Anthropic's thinking required one code path, OpenAI reasoning required another, and Google citations required a third.

Before v1 — three providers, three code paths
When to use content_blocks
Use content_blocks if: (1) you switch between providers, (2) you need reasoning traces or citations, (3) you're building multimodal pipelines. The API is clean and future-proof.
When .text is enough
If you only need the text response from a single provider and don't use reasoning or citations, response.text is simpler and equally correct. content_blocks adds complexity you don't need in that case.