What it is
An AI SDK is a software development kit: functions in Python, TypeScript or another language that call a model API so you do not hand-build every HTTP request. An official SDK (the OpenAI SDK, Google's Gen AI SDK, Anthropic's SDK, Azure's client) tracks one provider's features: chat, tools, streaming, file uploads. A multi-provider SDK tries to offer one interface across vendors. The Vercel AI SDK is a well-known TypeScript example aimed at streaming UI, especially with Next.js and React.
The SDK is not the service. If the provider is down, the SDK cannot invent a completion. If you need a feature the SDK has not wrapped, you either wait, send raw HTTP, or misuse an escape hatch.
Why and when it is used
Use an official SDK when you are committed to one provider and want types, auth helpers and streaming that match the docs. Use a multi-provider SDK when you genuinely swap models and can live with the lowest common denominator, plus occasional provider-specific options. Use raw HTTP when you want the smallest dependency, when you are debugging a weird error, or when you are teaching yourself what the wire looks like (Calling AI and Model APIs with Python, Calling AI Services from JavaScript and TypeScript).
Do not add an SDK, a framework and a second wrapper that all retry the same call. Pick one place that owns the request.
How it works
You construct a client with a key from the environment. You call a method such as chat.completions.create or the SDK's equivalent, passing messages and options. The library serialises JSON, sets Authorization, and decodes the response into objects. Streaming methods return an iterator or a web stream. Some UI kits then pipe that stream into a React hook so tokens render as they arrive. Tool helpers validate arguments against a schema you provide.
Retries, timeouts and error types differ by SDK. Read those defaults. A library that retries a non-idempotent "charge the card" tool call is dangerous. Your code should still check the model's output. Types in TypeScript describe the happy path the SDK knows, not the truth of a free-text field.
Technologies and dependencies
The language runtime, the SDK package pinned in your lockfile, and network access to the provider. UI streaming in the Vercel AI SDK depends on the framework adapter you choose (Next.js route handlers are the common demo). Keys stay in environment variables on the server. LangChain is a higher-level framework that may use SDKs or HTTP underneath; you do not need both for a single call. API keys and cloud IAM are the actual credentials; the SDK only carries them.
How to get started
- Call the API once with curl or a few lines of HTTP so you have seen the JSON.
- Install the official SDK. Repeat the same call. Diff the request if the SDK lets you log it.
- Set a timeout explicitly if the SDK's default is vague.
- Add streaming only after the non-streaming path stores a correct final answer in your database. Streaming is a transport optimisation, not the data model.
- If you adopt a UI kit, keep the model call on the server. The browser should receive tokens, not the secret.
- Pin the SDK version. Provider SDKs ship often and rename methods.
Write an interface your app uses (complete(prompt) -> text) and implement it with the SDK. Tests use a fake implementation. That interface is the seam that lets you leave the SDK later.
Cautions and trade-offs
SDKs lag and they also leap. A major bump can break compilation across the app if you passed SDK types into every function. Keep the SDK at the edge. Multi-provider kits hide parameters that matter (which safety setting, which region). Inspect what is actually sent.
Never import a server SDK into a client component. Bundlers will inline the key if you reference process.env carelessly in the wrong file. Some "AI UI" helpers assume a single-user demo and have no auth on the route. Add auth before you add personality. And do not confuse SDK convenience with evaluation. A typed stream of a wrong answer is still wrong.