Every model provider ships its own SDK with its own quirks. OpenAI streams differently than Anthropic, Anthropic handles tools differently than Google, and the moment you want to swap providers you end up rewriting half your application. The Vercel AI SDK exists to make that pain go away — one API for every model, with first-class React hooks layered on top.
\nA year ago the AI SDK was mostly known for its useChat hook, the easy way to wire up a streaming chat UI in Next.js. Today it’s grown into a complete toolkit: a typed core for any TypeScript runtime, a UI layer that powers chat and assistant interfaces in any framework, an RSC layer for streaming React components from the server, and an agent loop for tool-using workflows. In this post we’ll walk through how the pieces fit together and the patterns that have become standard for shipping AI features in production Next.js apps.
The Vercel AI SDK is split into three layers, each useful on its own:
\ngenerateText, streamText, generateObject, streamObject, embed, and embedMany all work the same way regardless of provider.useChat, useCompletion, useObject, useAssistant) for React, Svelte, Vue, and Solid. Handles streaming, message state, optimistic updates, and error recovery.streamUI, createStreamableUI, createStreamableValue) for streaming UI components from the server as the model generates them.You install only what you need. A backend cron job doing structured extraction needs Core but not UI. A Pages Router chat widget needs Core and UI but not RSC. A Next.js App Router app with generative UI uses all three.
\nnpm install ai @ai-sdk/openai @ai-sdk/anthropic zodThe provider packages are small adapters that translate the unified interface into provider-specific API calls. Adding a new provider means installing one more package, not rewriting your code.
\nThe lowest-level call is generateText — give it a model and a prompt, get text back:
import { generateText } from 'ai';\nimport { openai } from '@ai-sdk/openai';\n\nconst { text, usage, finishReason } = await generateText({\n model: openai('gpt-5'),\n prompt: 'Explain quantum entanglement in two sentences.',\n});\n\nconsole.log(text);\nconsole.log(`Used ${usage.totalTokens} tokens`);Switching to Anthropic is a one-line change:
\nimport { anthropic } from '@ai-sdk/anthropic';\n\nconst { text } = await generateText({\n model: anthropic('claude-opus-4-7'),\n prompt: 'Explain quantum entanglement in two sentences.',\n});The return shape — text, usage, finishReason, response, warnings — is identical. The same goes for system prompts, conversation history, temperature, max tokens, stop sequences, and the rest of the standard knobs.
For chat interfaces you almost always want streamText instead of generateText. It returns a result object with multiple consumption styles:
import { streamText } from 'ai';\nimport { openai } from '@ai-sdk/openai';\n\nexport async function POST(req: Request) {\n const { messages } = await req.json();\n\n const result = streamText({\n model: openai('gpt-5'),\n system: 'You are a helpful assistant.',\n messages,\n });\n\n return result.toUIMessageStreamResponse();\n}The toUIMessageStreamResponse() helper returns a Response whose body is the AI SDK’s data stream protocol — a format the useChat hook on the client knows how to parse. You can also iterate the stream manually with result.textStream (just the text deltas) or result.fullStream (every event: text, tool calls, tool results, finish reasons).
generateObject is one of the most useful tools in the SDK. Give it a Zod schema and it returns a typed, validated object:
import { generateObject } from 'ai';\nimport { z } from 'zod';\n\nconst { object } = await generateObject({\n model: openai('gpt-5'),\n schema: z.object({\n recipe: z.object({\n name: z.string(),\n ingredients: z.array(z.object({\n name: z.string(),\n amount: z.string(),\n })),\n steps: z.array(z.string()),\n prepMinutes: z.number(),\n }),\n }),\n prompt: 'Generate a recipe for sourdough focaccia.',\n});\n\nobject.recipe.ingredients.forEach((i) => {\n console.log(`${i.amount} ${i.name}`);\n});Under the hood the SDK uses each provider’s native structured output mode — OpenAI’s response format, Anthropic’s tool-call coercion, Google’s response schema — and validates the result against your Zod schema. Invalid responses throw a NoObjectGeneratedError you can catch and retry.
For long objects there’s streamObject, which streams partial objects as they’re generated. The matching useObject hook on the client gives you a typed, progressively filling object that’s perfect for forms that auto-populate or dashboards that build themselves.
Tool calling — letting the model invoke functions in your code — is where AI applications start feeling agentic. The SDK normalises tools across providers so you write them once:
\nimport { streamText, tool } from 'ai';\nimport { z } from 'zod';\n\nconst result = streamText({\n model: openai('gpt-5'),\n messages,\n tools: {\n getWeather: tool({\n description: 'Get the current weather for a city',\n inputSchema: z.object({\n city: z.string().describe('The city name'),\n units: z.enum(['celsius', 'fahrenheit']).default('celsius'),\n }),\n execute: async ({ city, units }) => {\n const data = await fetchWeather(city, units);\n return {\n temperature: data.temp,\n conditions: data.conditions,\n humidity: data.humidity,\n };\n },\n }),\n searchProducts: tool({\n description: 'Search the product catalog',\n inputSchema: z.object({\n query: z.string(),\n limit: z.number().default(10),\n }),\n execute: async ({ query, limit }) => {\n return await db.products.search(query, limit);\n },\n }),\n },\n stopWhen: stepCountIs(5),\n});The model sees tool descriptions and input schemas. When it decides to call one, the SDK invokes your execute function, captures the return value, and feeds it back as a tool result message. The stopWhen option caps how many tool-call rounds the model can perform before the loop ends — a critical safety valve. Without it a stuck model can chew through your budget calling the same tool forever.
For tools that need user confirmation (transferring money, deleting data, sending an email), omit execute and handle the call on the client instead. The model proposes the call, your UI shows a confirmation dialog, and you submit the result back through the chat hook. This pattern keeps destructive actions human-in-the-loop without giving up the conversational flow.
useChat is the AI SDK UI workhorse. It manages messages, handles streaming, surfaces tool calls, and gives you input state and submission handlers:
'use client';\n\nimport { useChat } from '@ai-sdk/react';\n\nexport function Chat() {\n const { messages, input, handleInputChange, handleSubmit, status, stop } =\n useChat({ api: '/api/chat' });\n\n return (\n <div className=\"flex flex-col gap-4\">\n {messages.map((m) => (\n <div key={m.id} className={m.role === 'user' ? 'text-right' : ''}>\n <strong>{m.role}: </strong>\n {m.parts.map((part, i) => {\n if (part.type === 'text') return <span key={i}>{part.text}</span>;\n if (part.type === 'tool-call') {\n return (\n <pre key={i}>\n Calling {part.toolName}({JSON.stringify(part.args)})\n </pre>\n );\n }\n return null;\n })}\n </div>\n ))}\n\n <form onSubmit={handleSubmit}>\n <input\n value={input}\n onChange={handleInputChange}\n placeholder=\"Ask something...\"\n disabled={status !== 'ready'}\n />\n {status === 'streaming' && (\n <button type=\"button\" onClick={stop}>\n Stop\n </button>\n )}\n </form>\n </div>\n );\n}The messages array uses a parts-based shape so a single assistant message can include text, tool calls, tool results, reasoning steps, and inline files. Rendering by part type is the recommended pattern — it scales cleanly as you add more capabilities.
The status field has four values: submitted, streaming, ready, error. Use it to disable the input while a request is in flight, show a typing indicator, and expose a stop button so users can interrupt long responses.
Need to persist conversations? Pass id and initialMessages from a server-loaded conversation. The hook handles the rest, including reconciling new server-side messages once the stream completes.
The most distinctive AI SDK feature is generative UI — letting the model stream actual React components from the server, not just text. streamUI is the entry point:
import { streamUI } from 'ai/rsc';\nimport { openai } from '@ai-sdk/openai';\nimport { z } from 'zod';\nimport { WeatherCard } from '@/components/weather-card';\nimport { ProductList } from '@/components/product-list';\n\nexport async function ask(question: string) {\n 'use server';\n\n const result = await streamUI({\n model: openai('gpt-5'),\n prompt: question,\n text: ({ content }) => <p>{content}</p>,\n tools: {\n showWeather: {\n description: 'Display a weather card for a city',\n inputSchema: z.object({ city: z.string() }),\n generate: async function* ({ city }) {\n yield <WeatherCard city={city} loading />;\n const data = await fetchWeather(city);\n return <WeatherCard city={city} data={data} />;\n },\n },\n showProducts: {\n description: 'Display matching products',\n inputSchema: z.object({ query: z.string() }),\n generate: async ({ query }) => {\n const products = await db.products.search(query);\n return <ProductList products={products} />;\n },\n },\n },\n });\n\n return result.value;\n}The model chooses which tool to call, and the generate function returns a React element (or yields multiple, for progressive states). The element is streamed to the client and rendered in place. You can yield a loading skeleton, fetch data, then yield the populated component — all from one async generator.
This sidesteps the usual “model returns JSON, client renders a card” dance entirely. The server owns the rendering, which means you can use server-only data sources, keep API keys out of the bundle, and ship richer UI without re-architecting your data layer.
\nThe SDK isn’t just for chat — it’s also the simplest way to generate embeddings for semantic search, retrieval, and clustering:
\nimport { embedMany } from 'ai';\nimport { openai } from '@ai-sdk/openai';\n\nconst { embeddings, usage } = await embedMany({\n model: openai.embedding('text-embedding-3-large'),\n values: docs.map((d) => d.content),\n});\n\nawait db.documents.insertMany(\n docs.map((d, i) => ({\n ...d,\n embedding: embeddings[i],\n }))\n);For a query, use embed for a single vector and run a similarity search against your vector store. The Drizzle and Prisma ecosystems both support pgvector columns now, so this slots cleanly into a normal Postgres-backed Next.js app without a separate vector database.
Because every provider exposes the same interface, switching is a matter of changing the model passed to a call. In practice teams take this further with a small wrapper that selects a model based on environment or feature flag:
\nimport { openai } from '@ai-sdk/openai';\nimport { anthropic } from '@ai-sdk/anthropic';\nimport { google } from '@ai-sdk/google';\n\nfunction pickModel(task: 'fast' | 'smart' | 'cheap') {\n switch (task) {\n case 'fast':\n return google('gemini-2.5-flash');\n case 'smart':\n return anthropic('claude-opus-4-7');\n case 'cheap':\n return openai('gpt-5-mini');\n }\n}\n\nconst { text } = await generateText({\n model: pickModel('smart'),\n prompt,\n});Vercel’s hosted AI Gateway takes this one step further. It provides a single endpoint, a single API key, automatic failover between providers, request-level analytics, and unified billing. You point your AI SDK provider at the gateway and gain provider-agnostic observability without changing application code:
\nimport { createGateway } from '@ai-sdk/gateway';\n\nconst gateway = createGateway({ apiKey: process.env.AI_GATEWAY_KEY });\n\nconst { text } = await generateText({\n model: gateway('anthropic/claude-opus-4-7'),\n prompt,\n});If the upstream provider is down, the gateway can route to a fallback model you configure. For production apps this turns model outages from a Sev 1 into a logged warning.
\nMulti-step agents — model calls a tool, sees the result, calls another tool, eventually answers — are first-class in the SDK. streamText with tools already loops automatically up to your stopWhen limit, but for richer control there’s the experimental_Agent class:
import { Agent } from 'ai';\n\nconst supportAgent = new Agent({\n model: anthropic('claude-opus-4-7'),\n system: 'You are a support engineer. Use the tools to investigate.',\n tools: {\n searchTickets,\n readLogs,\n queryDatabase,\n pageOncall,\n },\n stopWhen: stepCountIs(10),\n});\n\nconst { text, steps } = await supportAgent.generate({\n prompt: 'Investigate why customer 4271 cannot log in.',\n});Each step in steps includes the model’s reasoning, the tool calls it made, and their results. Log these to your observability platform and you get an audit trail of every decision the agent took — invaluable when something goes wrong and you need to debug an autonomous workflow.
Every model call passes through any middleware you register, which is where caching, logging, and guardrails live:
\nimport { wrapLanguageModel, type LanguageModelV2Middleware } from 'ai';\n\nconst cacheMiddleware: LanguageModelV2Middleware = {\n wrapGenerate: async ({ doGenerate, params }) => {\n const key = hashParams(params);\n const cached = await redis.get(key);\n if (cached) return JSON.parse(cached);\n\n const result = await doGenerate();\n await redis.set(key, JSON.stringify(result), 'EX', 3600);\n return result;\n },\n};\n\nconst model = wrapLanguageModel({\n model: openai('gpt-5'),\n middleware: [cacheMiddleware],\n});For telemetry, pass experimental_telemetry: { isEnabled: true } to any call and the SDK emits OpenTelemetry spans for the request, tool calls, and token usage. Pipe those into Langfuse, Helicone, or PostHog LLM Analytics and you have full observability of every model interaction without bespoke instrumentation.
When does the AI SDK earn its keep over calling provider SDKs directly?
\n| Concern | \nRaw SDK | \nVercel AI SDK | \n
|---|---|---|
| Provider switching | \nRewrite call site | \nChange one import | \n
| Streaming protocol | \nProvider-specific SSE | \nUnified data stream | \n
| Tool calling | \nDifferent shape per provider | \nOne tool() helper | \n
| Structured output | \nManual schema handling | \ngenerateObject with Zod | \n
| React integration | \nBuild it yourself | \nuseChat, useObject | \n
| RSC streaming | \nBuild it yourself | \nstreamUI | \n
| Multi-step agents | \nBuild the loop | \nAgent + stopWhen | \n
The trade-off is a thin abstraction layer between you and the model. For 95% of applications that’s a win — the SDK exposes every provider feature that matters and adds capabilities the raw SDKs lack. The exceptions are research code that needs the absolute newest provider-specific feature within hours of release, and apps that only ever talk to one model and want zero dependencies.
\nA few patterns that have become standard once you’re past the first prototype:
\nstopWhen on tool-enabled calls. Stuck loops are the most common way to burn a budget..describe() on each field — the model reads descriptions and they noticeably improve tool-call accuracy.onFinish in your route handler to write the assistant response to your database. Don’t rely on the client to round-trip the full transcript.experimental_telemetry from day one. Cost surprises are easier to diagnose when every call is traced.There are still cases where reaching for the AI SDK is overkill. A one-off script that calls OpenAI once and exits is fine with the raw openai package. Edge functions where every kilobyte counts can benefit from skipping the abstraction. And if you’re building a non-React Vue or vanilla TypeScript app, AI SDK UI is less compelling — though Core still wins on provider abstraction.
For anything beyond a single call from a single provider in a frontend codebase, the SDK pays for itself within an afternoon of work saved.
\nThe Vercel AI SDK has quietly become the default way to ship AI features in a TypeScript app. It papers over the provider differences that make integration tedious, gives you a real React hook for chat instead of a DIY SSE parser, and unlocks patterns — generative UI, streamed structured output, agentic loops — that would be weeks of work to build from scratch.
\nPair it with the AI Gateway for production routing, with PostHog LLM Analytics for observability, and with Zod for input validation, and you have a stack that handles every layer of an AI feature from the model call up to the rendered UI. The model landscape will keep churning — new providers, new modalities, new capabilities — but the SDK absorbs that churn so your application code doesn’t have to.
\n‘Till next time!
","rawMarkdownBody":"\n## A Unified Toolkit for AI in TypeScript\n\nEvery model provider ships its own SDK with its own quirks. OpenAI streams differently than Anthropic, Anthropic handles tools differently than Google, and the moment you want to swap providers you end up rewriting half your application. The Vercel AI SDK exists to make that pain go away — one API for every model, with first-class React hooks layered on top.
\n\nA year ago the AI SDK was mostly known for its `useChat` hook, the easy way to wire up a streaming chat UI in Next.js. Today it's grown into a complete toolkit: a typed core for any TypeScript runtime, a UI layer that powers chat and assistant interfaces in any framework, an RSC layer for streaming React components from the server, and an agent loop for tool-using workflows. In this post we'll walk through how the pieces fit together and the patterns that have become standard for shipping AI features in production Next.js apps.\n\n### What the SDK Actually Is\n\nThe Vercel AI SDK is split into three layers, each useful on its own:\n\n- **AI SDK Core** — A unified TypeScript API for calling LLMs. `generateText`, `streamText`, `generateObject`, `streamObject`, `embed`, and `embedMany` all work the same way regardless of provider.\n- **AI SDK UI** — Framework hooks (`useChat`, `useCompletion`, `useObject`, `useAssistant`) for React, Svelte, Vue, and Solid. Handles streaming, message state, optimistic updates, and error recovery.\n- **AI SDK RSC** — React Server Components helpers (`streamUI`, `createStreamableUI`, `createStreamableValue`) for streaming UI components from the server as the model generates them.\n\nYou install only what you need. A backend cron job doing structured extraction needs Core but not UI. A Pages Router chat widget needs Core and UI but not RSC. A Next.js App Router app with generative UI uses all three.\n\n```bash\nnpm install ai @ai-sdk/openai @ai-sdk/anthropic zod\n```\n\nThe provider packages are small adapters that translate the unified interface into provider-specific API calls. Adding a new provider means installing one more package, not rewriting your code.\n\n### The Core API\n\nThe lowest-level call is `generateText` — give it a model and a prompt, get text back:\n\n```typescript\nimport { generateText } from 'ai';\nimport { openai } from '@ai-sdk/openai';\n\nconst { text, usage, finishReason } = await generateText({\n model: openai('gpt-5'),\n prompt: 'Explain quantum entanglement in two sentences.',\n});\n\nconsole.log(text);\nconsole.log(`Used ${usage.totalTokens} tokens`);\n```\n\nSwitching to Anthropic is a one-line change:\n\n```typescript\nimport { anthropic } from '@ai-sdk/anthropic';\n\nconst { text } = await generateText({\n model: anthropic('claude-opus-4-7'),\n prompt: 'Explain quantum entanglement in two sentences.',\n});\n```\n\nThe return shape — `text`, `usage`, `finishReason`, `response`, `warnings` — is identical. The same goes for system prompts, conversation history, temperature, max tokens, stop sequences, and the rest of the standard knobs.\n\n#### Streaming\n\nFor chat interfaces you almost always want `streamText` instead of `generateText`. It returns a result object with multiple consumption styles:\n\n```typescript\nimport { streamText } from 'ai';\nimport { openai } from '@ai-sdk/openai';\n\nexport async function POST(req: Request) {\n const { messages } = await req.json();\n\n const result = streamText({\n model: openai('gpt-5'),\n system: 'You are a helpful assistant.',\n messages,\n });\n\n return result.toUIMessageStreamResponse();\n}\n```\n\nThe `toUIMessageStreamResponse()` helper returns a `Response` whose body is the AI SDK's data stream protocol — a format the `useChat` hook on the client knows how to parse. You can also iterate the stream manually with `result.textStream` (just the text deltas) or `result.fullStream` (every event: text, tool calls, tool results, finish reasons).\n\n#### Structured Output\n\n`generateObject` is one of the most useful tools in the SDK. Give it a Zod schema and it returns a typed, validated object:\n\n```typescript\nimport { generateObject } from 'ai';\nimport { z } from 'zod';\n\nconst { object } = await generateObject({\n model: openai('gpt-5'),\n schema: z.object({\n recipe: z.object({\n name: z.string(),\n ingredients: z.array(z.object({\n name: z.string(),\n amount: z.string(),\n })),\n steps: z.array(z.string()),\n prepMinutes: z.number(),\n }),\n }),\n prompt: 'Generate a recipe for sourdough focaccia.',\n});\n\nobject.recipe.ingredients.forEach((i) => {\n console.log(`${i.amount} ${i.name}`);\n});\n```\n\nUnder the hood the SDK uses each provider's native structured output mode — OpenAI's response format, Anthropic's tool-call coercion, Google's response schema — and validates the result against your Zod schema. Invalid responses throw a `NoObjectGeneratedError` you can catch and retry.\n\nFor long objects there's `streamObject`, which streams partial objects as they're generated. The matching `useObject` hook on the client gives you a typed, progressively filling object that's perfect for forms that auto-populate or dashboards that build themselves.\n\n### Tool Calling\n\nTool calling — letting the model invoke functions in your code — is where AI applications start feeling agentic. The SDK normalises tools across providers so you write them once:\n\n```typescript\nimport { streamText, tool } from 'ai';\nimport { z } from 'zod';\n\nconst result = streamText({\n model: openai('gpt-5'),\n messages,\n tools: {\n getWeather: tool({\n description: 'Get the current weather for a city',\n inputSchema: z.object({\n city: z.string().describe('The city name'),\n units: z.enum(['celsius', 'fahrenheit']).default('celsius'),\n }),\n execute: async ({ city, units }) => {\n const data = await fetchWeather(city, units);\n return {\n temperature: data.temp,\n conditions: data.conditions,\n humidity: data.humidity,\n };\n },\n }),\n searchProducts: tool({\n description: 'Search the product catalog',\n inputSchema: z.object({\n query: z.string(),\n limit: z.number().default(10),\n }),\n execute: async ({ query, limit }) => {\n return await db.products.search(query, limit);\n },\n }),\n },\n stopWhen: stepCountIs(5),\n});\n```\n\nThe model sees tool descriptions and input schemas. When it decides to call one, the SDK invokes your `execute` function, captures the return value, and feeds it back as a tool result message. The `stopWhen` option caps how many tool-call rounds the model can perform before the loop ends — a critical safety valve. Without it a stuck model can chew through your budget calling the same tool forever.\n\nFor tools that need user confirmation (transferring money, deleting data, sending an email), omit `execute` and handle the call on the client instead. The model proposes the call, your UI shows a confirmation dialog, and you submit the result back through the chat hook. This pattern keeps destructive actions human-in-the-loop without giving up the conversational flow.\n\n### The useChat Hook\n\n`useChat` is the AI SDK UI workhorse. It manages messages, handles streaming, surfaces tool calls, and gives you input state and submission handlers:\n\n```tsx\n'use client';\n\nimport { useChat } from '@ai-sdk/react';\n\nexport function Chat() {\n const { messages, input, handleInputChange, handleSubmit, status, stop } =\n useChat({ api: '/api/chat' });\n\n return (\n\n Calling {part.toolName}({JSON.stringify(part.args)})\n \n );\n }\n return null;\n })}\n {content}
,\n tools: {\n showWeather: {\n description: 'Display a weather card for a city',\n inputSchema: z.object({ city: z.string() }),\n generate: async function* ({ city }) {\n yield