Concept Walkthrough

The adapter pattern you already know

Think of how an ORM like Prisma lets you write the same query for Postgres or MySQL. You still pick a database, and some features only exist on one of them, but day-to-day code looks the same. The AI SDK plays that role for LLM providers.

AI SDK Core is built on a published language model specification. Each provider package (@ai-sdk/openai, @ai-sdk/anthropic and others) implements that specification. Your code calls generateText or streamText and passes a model. The provider adapter turns that into the provider's own HTTP request and turns the response back into the SDK's shape.

What the SDK standardises

• Calling a model: one function shape for text generation and streaming, with common settings like maxOutputTokens and abortSignal.
• Message format: you pass messages in one format and the adapter converts them for each provider.
• Tools: you define tools once with tool({ description, inputSchema, execute }) and the SDK runs the call loop, with stopWhen to limit steps.
• Streaming to the UI: the server turns a streamText result into a UI message stream, and useChat on the client knows how to read it. You never parse provider-specific streaming events yourself.

What stays provider-specific

• Capabilities: the AI SDK docs keep a table showing that image input, object generation, tool usage and tool streaming vary by model. The API accepting an option does not mean the model supports it.
• Tokenization and pricing: each provider counts tokens its own way and charges its own prices. A cost estimate for one does not carry over.
• Special features: prompt caching, reasoning controls and similar knobs work differently per provider. These go in providerOptions, an object keyed by provider name.
• Behaviour: how well a model follows your instructions, how long it answers and how it handles tools. No SDK can hide that, so you still need evals.

In AI SDK 7, there is also a top-level reasoning option, and the migration guide notes that provider-specific reasoning settings in providerOptions take precedence over it.

Key Code Explained

// lib/models.ts
import 'server-only';
import { openai } from '@ai-sdk/openai';

// One place to change the provider. Every route imports this.
export const chatModel = openai('gpt-5.4');

// app/api/summary/route.ts
import { streamText, toUIMessageStream, createUIMessageStreamResponse } from 'ai';
import { chatModel } from '@/lib/models';

export async function POST(req: Request) {
  const { text }: { text: string } = await req.json();

  const result = streamText({
    model: chatModel, // swap here, the rest of the call stays the same
    instructions: 'Summarise the text in three bullet points.',
    prompt: text,
    maxOutputTokens: 300, // standard setting, every provider adapter maps it
    providerOptions: {
      // Only read by the OpenAI adapter. Other providers ignore this key.
      openai: { reasoningEffort: 'low' },
    },
  });

  // Standard UI stream: the client code does not care which provider answered.
  return createUIMessageStreamResponse({
    stream: toUIMessageStream({ stream: result.stream }),
  });
}

The important part is what does not change when you switch providers: the route, the response helper and the React code reading the stream. The parts that may change are the model line, the providerOptions block and your expectations about quality and cost.

Tradeoffs

What Interviewers Actually Check

• Whether you can name concrete things the SDK standardises, not just "it is a wrapper"
• Whether you know capabilities differ by model even when the API looks the same
• Whether you mention tokenization and pricing as provider-specific
• Whether you know where provider-only settings go (providerOptions)
• Whether you plan to re-run evals before switching providers

Follow-Up Questions

1. How would you route cheap requests to one model and hard requests to another without duplicating code?
2. A model on the new provider does not support tool streaming. How does that change your UI?
3. How do you handle a feature that only one provider offers, such as a specific caching mode?
4. What would you log so you can compare two providers on cost and latency in production?
5. When would you skip the SDK and call the provider directly?

Common Candidate Mistakes

• Saying the SDK makes models interchangeable in quality, not just in API shape
• Assuming the option being accepted means the model supports it
• Spreading openai(...) calls across many files, which makes a switch painful
• Carrying cost estimates from one provider to another without checking tokenization and prices
• Passing provider-only settings as top-level options instead of in providerOptions

Interview Readiness Checklist

Before you leave this question, make sure you can answer:

• Can you explain the AI SDK with an adapter or ORM analogy?
• Can you name four things it standardises and four things it does not?
• Can you write a providerOptions block and explain who reads it?
• Can you keep the model choice in one module?
• Can you describe the checks you would run before a provider switch?

Summary

The AI SDK is an adapter layer. It standardises how you call models, how messages and tools are described and how streams reach the UI, using a shared language model specification that each provider package implements. It does not standardise the models themselves. Capabilities, tokenization, pricing, special features and output quality stay provider-specific. Keep the model choice in one module, pass provider-only settings through providerOptions, and re-run your evals whenever you change providers.