Every AI project we take on starts with the same question, and it isn’t “which model.” It’s “what shape is this thing.” A chat box bolted onto one product needs different plumbing than an agent that edits files, and both need different plumbing than a product that has to swap models without a rewrite. The SDK follows from that shape. This is the reasoning we actually use on client work.
We list these same four on the AI solutions page and the stack page: the OpenAI SDK, the Anthropic SDK, the Vercel AI SDK, and OpenRouter. Here’s what each one is actually for.
OpenAI: a feature that lives in one product
If the job is a chat feature, a support assistant, or a voice line bolted onto an existing product, the OpenAI SDK is usually the shortest path there. The Responses API handles the core chat-and-tools loop, and prompt caching kicks in automatically once a prompt passes roughly a thousand tokens, so a system prompt you send on every request gets cheaper to reuse without any code on your end. For voice, the Realtime API is what we use for the booking and intake lines we build on our AI agents page.
When the feature needs to plan across steps, call several tools, or hand off between specialized roles, the Agents SDK adds that on top: an agent loop, guardrails on input and output, and tracing so you can see what a run actually did. It ships for TypeScript and Python. The broader OpenAI API also has official client SDKs in .NET, Java, Go, and Ruby, for the projects that call the models directly without the agent framework.
Anthropic: an agent that reads, plans, and touches files
The Claude API is the direct route: a Messages API with tool use and streaming, official client SDKs across Python, TypeScript, C#, Go, Java, PHP, and Ruby. For a straightforward integration where you’re calling a model and handling the response yourself, that’s the whole story.
Where Anthropic gets more interesting for us is the Claude Agent SDK, which is built differently from most agent frameworks: it’s the same agent loop, tool set, permission system, and session handling that runs Claude Code itself, packaged as a library for Python and TypeScript. That matters for one specific case, an agent that has to read a codebase, a long document, or a pile of files and actually act on what it finds. Hooks let you run custom code at points in the agent’s lifecycle, subagents let you spawn a focused helper for one part of the task, and permissions decide what runs automatically versus what waits for a human. If the job looks like “point this at a repository and let it work,” this is what we reach for.
For high-volume, non-interactive work, the Message Batches API processes large sets of requests asynchronously at close to half the standard price, which is the right tool for the kind of batch classification or document processing where nobody’s waiting on the response in real time.
Vercel AI SDK: one app, more than one model
Most client products don’t stay on a single provider forever, and rewriting the model-calling code every time that changes is wasted effort. The Vercel AI SDK exists for exactly that: a TypeScript interface that sits over OpenAI, Anthropic, and dozens of other providers, so switching or A/B testing models is a config change instead of a rewrite. We reach for it on Next.js, React, Svelte, and Node projects where the whole product needs to stay model-agnostic.
The part that saves the most build time in practice is the UI layer: hooks for streaming chat interfaces, structured data, and tool calls, built for the frameworks we already use. A short example of the shape of it:
const result = streamText({
model: openai('gpt-5'),
prompt: 'Summarize this support ticket',
});
return result.toTextStreamResponse();Swap openai('gpt-5') for an Anthropic or any other supported model and the rest of the call doesn’t change.
OpenRouter: cost-sensitive work and trying models without committing
OpenRouter’s pitch is a single API key that reaches hundreds of models through one endpoint, in a format compatible enough with the OpenAI SDK that it often works as a drop-in target. The feature we actually use most is the fallback list: pass an ordered array of models, and if the first one errors, rate-limits, or refuses, OpenRouter tries the next one automatically, still billing you for whichever model actually answered.
That earns its place in two situations on client work. First, batch or background jobs where being picky about exact model version matters less than throughput and uptime. Second, the early phase of a project where we’re testing three or four candidate models against real traffic before locking one in, without wiring up three or four separate provider integrations to do it.
Which one when
- A chat feature or voice line inside one product: OpenAI, with the Agents SDK if it needs to take actions, not just answer.
- An agent that reads a codebase or a pile of documents and acts on it: the Claude Agent SDK, because the tool loop and permissions are already built for exactly that.
- A product that needs to swap or mix models without a rewrite, especially with a TypeScript frontend: the Vercel AI SDK.
- Cost-sensitive batch work, or evaluating several models before committing: OpenRouter.
- Large volumes of non-interactive requests where nothing is waiting on the response: Anthropic’s Message Batches API, or an OpenRouter batch run if the job needs to try more than one provider.
None of this is exclusive. A project can call the Claude API directly for its core agent and use OpenRouter for a secondary classification step that doesn’t need Claude specifically. That decision gets made per feature, sometimes more than once inside the same project.
What we skip, and why
We don’t reach for a general orchestration framework on top of these SDKs. The tool-calling loop that a framework like that automates is a few dozen lines with any of the SDKs above, and once a project is past the demo stage, the parts that actually take engineering time are the retrieval pipeline, the evals, the cost controls, and the guardrails, which we build directly rather than through another layer of abstraction. Fewer dependencies means fewer places for a bug to hide when a client’s production traffic doesn’t look like the demo did.
The part that doesn’t change
Whichever SDK ends up in a given feature, the harder work sits around it: retrieval that grounds answers in real data, evals that catch a regression before a release does, cost monitoring so a runaway loop doesn’t show up as a surprise invoice. That’s most of what we describe on the AI integration and AI SaaS pages, and it’s the same discipline behind why our own site is built the way it is: pick the tool for the job in front of you, and don’t claim more than you can show.
If you’ve got a project and aren’t sure which shape it is yet, that’s a normal place to start. Tell us what you’re building, or look at the full range of what we build in services.