LLM Best Practices

OpenAI SDK vs LangChain

4 min read

View markdown source

Overview

Use the native provider SDK (OpenAI, Anthropic, etc.) for production agents. Native SDKs are thin, stable, and version-locked to the API surface you need. Use LangChain only during rapid prototyping when its pre-built chains or integrations let you reach a working demo significantly faster, and when you accept that the abstraction may need to be replaced before production. See multi-agent for agent architecture patterns.

When native SDK wins

The native SDK is the correct choice for production work.

  • Stability: native SDKs version-lock to the provider API. A breaking change in OpenAI or Anthropic’s API ships as a major SDK version bump with a clear changelog. LangChain’s abstractions add a middle layer that may break independently.
  • Debuggability: every request and response is visible without peeling through abstraction layers. Logging, tracing, and error handling attach directly to the HTTP client.
  • Performance: native SDK calls have no LangChain overhead. On high-throughput agents (hundreds of calls per minute), the overhead of LangChain’s chain execution, callbacks, and schema validation is measurable.
  • Control: structured output, tool use, streaming, function calling, and prompt caching are fully accessible from the native SDK. LangChain’s abstractions occasionally lag provider features by weeks or months.
  • Dependency surface: the native SDK is one package. LangChain pulls in dozens of transitive dependencies; version conflicts are a recurring issue in monorepos.
  • Long-term maintainability: engineers not familiar with LangChain’s mental model (chains, runnables, LCEL) need time to read the code. Native SDK code reads like direct API calls.
# Native Anthropic SDK: straightforward, debuggable
client = anthropic.Anthropic()
message = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": prompt}],
)

When LangChain wins

LangChain is justified in narrow prototyping scenarios.

  • Pre-built integrations: LangChain ships connectors for vector stores (Chroma, Pinecone, pgvector), document loaders (PDFs, URLs, Notion), and retrievers. If building a RAG prototype in a day, these integrations save boilerplate. See rag.
  • Multi-provider switching: if the prototype needs to swap between OpenAI, Anthropic, and local models without rewriting orchestration, LangChain’s provider abstraction is useful. In production, committing to one provider and using its native SDK is usually the right call.
  • Existing LangChain codebase: if the team already runs LangChain in production and knows the patterns well, new features in the same codebase stay on LangChain for consistency.
  • Exploration and demos: LangChain’s ecosystem of example notebooks and prebuilt chains can accelerate feasibility research. Throw it away before production.

Trade-offs at a glance

DimensionNative SDKLangChain
StabilityHigh; versioned to provider APIModerate; abstraction layer adds breakage risk
DebuggabilityDirect request/response visibilityAbstracted; harder to trace individual calls
PerformanceMinimal overheadOverhead from chains, callbacks, validation
Feature currencyImmediate on provider releaseLags provider features occasionally
Dependency count1 to 2 packagesDozens of transitive dependencies
RAG integrationsManual (Chroma, pgvector clients)Built-in loaders, retrievers, splitters
Multi-provider supportPer-provider; no abstractionUnified interface across providers
Learning curveLow; mirrors the API docsModerate; LCEL, runnables, chains, callbacks
Production incidentsProvider bugs onlyProvider bugs plus abstraction bugs
TypeScript/PythonExcellent types in both SDKsPython stronger; JS types vary by version

Migration cost

LangChain to native SDK is a rewrite, not a migration. Plan it as a deliberate replacement.

  • Extract the business logic (prompts, tool definitions, retrieval queries) from the LangChain chains. These are the assets that transfer.
  • Rewrite orchestration using native SDK calls. Function calling and tool use map directly to the provider’s tool API.
  • Replace LangChain retrievers with direct vector store client calls. The queries are the same; the client is different.
  • Effort: one to two engineer-weeks per complex chain or agent, depending on the number of integrations. Simple chains migrate in a day.

Do not migrate a working LangChain production system unless there is a concrete problem. Stability, a new provider feature you cannot access, or dependency conflicts are real reasons. “Best practices” is not.

Recommendation

  • New production agent: native SDK from the start.
  • Feasibility prototype with RAG and multiple integrations: LangChain for speed. Plan to rewrite before production.
  • Existing LangChain production system with no active problems: stay. Invest engineering time elsewhere.
  • Multi-provider evaluation: LangChain or provider SDKs with a thin adapter you own. Own the adapter; do not let LangChain own the abstraction.

Graph View