SDKs and Abstraction Layers: Provider SDKs vs. the AI SDK
When to call a provider SDK directly and when a multi-provider toolkit like the Vercel AI SDK earns its place — with the same feature written both ways.
Every AI feature makes the same architectural choice early, often without anyone noticing: which library sits between your code and the model? You can call a provider's own SDK, like @anthropic-ai/sdk or openai. You can use a multi-provider toolkit, most commonly the Vercel AI SDK (the ai package), which wraps many providers behind one interface and adds UI helpers for React. Or you can put a gateway in the middle. Each choice is reasonable. Each one also costs something that won't be obvious until month three.
In this lesson you'll write the same Deskmate feature both ways, a streaming reply drafter in a Next.js route handler plus a structured triage call, so you can see exactly what each layer gives you and where it leaks. You'll finish with a clear rule of thumb for choosing per project, and per feature.
Three layers between you and the model
Think of your options as layers, each built on the one below:
| Layer | Example | What you get | What you give up |
|---|---|---|---|
| Raw HTTP | fetch to the provider's endpoint | Total control, zero dependencies | Types, retries, streaming parsing, helpers: you write all of it |
| Provider SDK | @anthropic-ai/sdk, openai, @google/genai | Typed access to every feature the provider ships, usually on day one | One provider per SDK; your code uses that provider's shapes |
| Multi-provider toolkit | ai with @ai-sdk/anthropic, @ai-sdk/openai | One interface across providers, React streaming hooks, unified tools and structured output | Lag on new provider features; a normalization layer that can hide details |
Raw HTTP is rarely worth it for application code. You saw a curl request in Anatomy of a Model API Call, and it's useful for debugging, but the SDKs handle retries, typed errors, and stream parsing that you'd otherwise rewrite badly. The real decision is between the second and third layers.
A fourth option, an LLM gateway (a proxy service between your app and providers, handling keys, fallbacks, and spend tracking), is about operations more than code, and works with either library. It's covered in LLM Gateways and Provider Fallbacks.