Navigate the Library
The AI SDK is organized around public layers that solve different parts of an AI application rather than around one monolithic runtime. New projects usually begin with the ai package because it is the provider-agnostic Core entry point for model calls. A UI package such as @ai-sdk/react is added when the product needs client-side chat state, streaming message updates, or generative interface helpers. @ai-sdk/rsc is a separate React Server Components path for server-to-client generative UI streaming, and the official navigation page marks it experimental while recommending AI SDK UI for most new work.
Sources: content/docs/02-getting-started/01-navigating-the-library.mdx, packages/ai/package.json, packages/react/package.json, packages/rsc/package.json
Purpose and Scope
Use this page when you know you want to build with the AI SDK but are not yet sure which package, runtime, or documentation area applies to your project. The key decision is the boundary where AI behavior meets your application. A server endpoint, worker, or script needs model access and response handling. A chatbot additionally needs message state and streaming UI updates. A React Server Components application may need to stream generated UI elements across the server-client boundary. The official navigation documentation names those choices as AI SDK Core, AI SDK UI, and AI SDK RSC.
This separation matters because the same model call can appear in several shapes. A server-only workflow can call Core APIs such as generateText or streamText from ai and return the result directly. A React or Next.js application may still use those Core functions in a server route, but then pair them with UI hooks that manage requests, messages, and streamed updates in the frontend. RSC projects evaluate a different integration point: whether server-rendered component streaming is the right architecture, while accepting the experimental status called out in the navigation docs.
Sources: content/docs/02-getting-started/01-navigating-the-library.mdx
Relevant Source Files
content/docs/02-getting-started/01-navigating-the-library.mdx- Defines the first-party reader flow for choosing between AI SDK Core, AI SDK UI, and AI SDK RSC, including the environment compatibility tables and the experimental guidance for RSC.packages/ai/package.json- Describes the publishedaipackage, its Core role, Node engine requirement, public export map, dependencies on provider infrastructure, and the package description that mentions Vercel AI Gateway and direct providers.packages/react/package.json- Defines the@ai-sdk/reactpackage as the React UI integration surface, including its dependency onai, React peer dependency, and supporting packages for UI-oriented streaming state.packages/rsc/package.json- Defines the@ai-sdk/rscpackage, including its RSC-specific export conditions, React and optional Zod peer dependencies, and tests for node, UI, end-to-end, and edge behavior.
Core Primitives
The first primitive is AI SDK Core. Core is the unified, provider-agnostic layer for generating text, producing structured objects, and making tool calls with language models. The navigation page uses generateText and streamText as representative examples, and the ai package manifest describes the package as a single interface for models through Vercel AI Gateway or direct provider packages. Start here when your immediate task is prompting a model, streaming text, generating typed data, using tools, building lower-level agent behavior, or writing code that should not depend on a frontend framework.
The second primitive is AI SDK UI. The navigation page defines UI as framework-agnostic hooks for building chat and generative user interfaces across React and Next.js, Vue and Nuxt, and Svelte and SvelteKit. In this source set, @ai-sdk/react is the concrete UI package. Its manifest depends on ai, provider utilities, SWR, throttling, and @ai-sdk/mcp, while declaring React as a peer dependency. That dependency shape is important: UI packages sit above Core and coordinate application state around streams; they do not replace the model execution layer.
The third primitive is AI SDK RSC. The navigation page describes RSC as a way to stream generative user interfaces from server to client using React Server Components, with development currently experimental and AI SDK UI recommended instead. The @ai-sdk/rsc manifest reinforces that specialization through separate react-server, module, import, and type export targets. Choose RSC only when the application architecture intentionally depends on React Server Components and the team is comfortable adopting the experimental integration rather than the more broadly recommended UI package path.
Sources: content/docs/02-getting-started/01-navigating-the-library.mdx, packages/ai/package.json, packages/react/package.json, packages/rsc/package.json
Choosing by Environment
Start with the runtime you already have. For Node.js, Deno, browser-capable JavaScript, workers, or server-side application code without a UI framework, use AI SDK Core through ai. The package publishes its main module at ./dist/index.js, types at ./dist/index.d.ts, and public exports for ., ./internal, ./test, and ./package.json. Its manifest requires Node.js >=22, depends on gateway and provider workspace packages, and keeps zod as a peer dependency for schema-oriented workflows.
For React or Next.js interfaces, use Core for model calls and add the UI package that matches the frontend. @ai-sdk/react exports a single public package entry, declares React peer support for React 18 and 19 ranges, and depends on ai, @ai-sdk/provider, @ai-sdk/provider-utils, @ai-sdk/mcp, swr, and throttleit. That tells you where responsibilities sit: server code and shared SDK primitives handle provider-normalized generation, while React-specific code manages hook-driven state, request lifecycle, and streaming updates in the application.
For Vue, Nuxt, Svelte, and SvelteKit projects, the official navigation table still points readers to AI SDK UI alongside Core. The supplied package manifests show the React package specifically, but the documentation frames UI as a framework-agnostic family rather than a React-only feature. For Next.js App Router, both Core and UI are relevant, and RSC can be considered when React Server Components are a deliberate requirement. For Next.js Pages Router, the navigation table supports Core and UI, while RSC is not the compatible path.
Sources: content/docs/02-getting-started/01-navigating-the-library.mdx, packages/ai/package.json, packages/react/package.json
System-to-Code Mapping
| Reader need | Start with | Why | Source signal |
|---|---|---|---|
| Call a model from server code, a route, or a script | ai | Core is the unified provider-agnostic API for generation, structured output, and tool calls | packages/ai/package.json describes one interface for Gateway or direct providers |
| Build a streaming React or Next.js chatbot | ai plus @ai-sdk/react | UI hooks sit above Core and manage framework state around streamed responses | packages/react/package.json depends on ai and declares React peer support |
| Build with Vue, Nuxt, Svelte, or SvelteKit | AI SDK UI documentation plus Core APIs | The navigation table lists those environments as UI-compatible | content/docs/02-getting-started/01-navigating-the-library.mdx contains the compatibility matrix |
| Stream generative UI through React Server Components | @ai-sdk/rsc | RSC is a specialized experimental package with server and client export conditions | packages/rsc/package.json exposes a react-server target |
| Access many model providers | ai with Gateway model strings, or direct provider packages | Provider access is decoupled from the UI layer | packages/ai/package.json names Vercel AI Gateway and direct providers |
Provider selection runs across these layers instead of replacing them. The official provider documentation lists AI Gateway, OpenAI, Anthropic, Google, xAI, Azure, Bedrock, Groq, Cohere, Mistral, community providers, and OpenAI-compatible providers. The ai manifest describes the same product goal as one interface for any model through Gateway or direct provider packages. In practical terms, pick Core, UI, or RSC based on runtime and application state first. After that, decide whether Gateway, a direct provider package, an OpenAI-compatible package, or a custom provider best matches your model access requirements.
Sources: content/docs/02-getting-started/01-navigating-the-library.mdx, packages/ai/package.json
Package Reference
| Package | Public role | Export shape visible here | Runtime and peer signals |
|---|---|---|---|
ai | Core SDK entry point for provider-agnostic model calls and shared APIs | Exports ., ./internal, ./test, and ./package.json | Node.js >=22, zod peer dependency, gateway/provider/provider-utils dependencies |
@ai-sdk/react | React UI integration package for AI SDK UI workflows | Exports . and ./package.json | React peer dependency, depends on ai, SWR, throttling, provider utilities, and @ai-sdk/mcp |
@ai-sdk/rsc | Experimental React Server Components integration | Exports . with react-server, module, import, and type targets | React and optional zod peers, RSC-focused dependencies and multi-environment test scripts |
The manifest versions in this snapshot are ai 7.0.9, @ai-sdk/react 4.0.10, and @ai-sdk/rsc 3.0.9. Treat those as independently published packages within one SDK ecosystem, not as separate product families. The documentation is intentionally organized by reader task rather than only by package version. A useful reading path is to learn Core first, then add UI when you need framework state and streaming interfaces, and only then evaluate RSC if your Next.js or React Server Components architecture requires it.
Sources: packages/ai/package.json, packages/react/package.json, packages/rsc/package.json
Practical Navigation Flow
A safe navigation flow is to start at the application boundary, then move inward. If you are building a backend endpoint, CLI, worker, or script, read the AI SDK Core overview and import from ai. If you are building a chatbot, keep Core on the server path and read AI SDK UI next, choosing the package that matches your frontend. If your project is RSC-first, read the RSC docs with the experimental warning in mind and compare the feature against AI SDK UI before committing to @ai-sdk/rsc. This prevents coupling a project to a UI transport when the real requirement is only a model call.
After the runtime choice, choose model access. The ai package description supports both Vercel AI Gateway and direct provider packages. Gateway is the simplest mental model when you want to pass a model string and avoid per-provider setup early. Direct provider packages are useful when you need provider-specific configuration, account setup, or package-level capabilities. MCP appears in the React package dependencies and in the broader provider ecosystem, but it is best explored after you understand the Core call shape and the UI layer that will present results.
Sources: content/docs/02-getting-started/01-navigating-the-library.mdx, packages/ai/package.json, packages/react/package.json
Next Steps
Read AI SDK Core Overview next if you are deciding how generation, tools, structured output, embeddings, media, or agents work at the API level. Read UI Overview and Chatbot if you already know the product is a streaming application interface. Read Provider Overview and AI Gateway once the runtime decision is clear and you need to choose Gateway, a direct provider package, an OpenAI-compatible provider, or a community provider. If the project specifically depends on React Server Components, continue to RSC Generative UI, but keep the navigation page’s recommendation toward AI SDK UI in mind.