16 — Implementing AI — Three Providers, One Shape

"Implementing AI" sounded enormous until I noticed every provider does the same thing. But before any of it, three words need pinning down, because the whole topic is built from them.

A model provider is a company that runs an AI model on its own servers and lets you borrow it over the internet. Anthropic (models called Claude), OpenAI (GPT), and Google (Gemini) are the three big ones. An API is just a door for that borrowing: a standard way for your program to send a request to their server and get an answer back. And an API key is the password that proves it's you — and, just as importantly, tells them whose account to bill.

So "implementing AI" collapses to one sentence: call a provider's API from your app to power a feature — smart form validation, a chatbot, recommendations. You send a request, you get text back, and that text becomes your feature. All three providers expose the same shape, which leaves three real decisions: which provider, which model tier, and where the call runs.

Here's the whole picture before I walk through it — your app, one request, three interchangeable doors:

The common shape, before the providers

The part I had to see clearly is that there isn't really an "AI integration skill" separate from "calling an HTTP API" [1]. Whatever the provider, the request is the same three pieces:

• A messages array — the conversation, written out as a list. It starts with a system message (the standing instructions, "you're a helpful assistant…"), then the back-and-forth of user and assistant turns. It's just the chat history, spelled out.
• A model name — a string saying which AI to use, like gpt-4o or a Claude model.
• A couple of knobs — like temperature (a dial controlling how adventurous the guessing is) and max tokens (a cap on how long the reply can be).

The response is the text the model generated, made of tokens — small chunks of text the model reads and writes, which is also the unit you're billed by. The reply comes back one of two ways: all at once (a completion), or piece by piece as it's produced (a stream). Streaming is what makes a chatbot feel live instead of making the user stare at a spinner for eight seconds.

That's the whole exchange. Each provider ships a SDK — a small helper library (Anthropic's @anthropic-ai/sdk, OpenAI's openai, Google's @google/genai) so you don't hand-write the request yourself — but the SDKs are thin convenience wrappers around that same exchange [2][3][4]. Knowing the shape is 80% of "implementing AI." The remaining 20% is three decisions, and the first one is which door to knock on.

The three providers, in one line each

The three doors differ in flavor, not in shape. I don't need a deep dive on each — one line apiece covers the decision:

• Anthropic (Claude) — the safety-focused one, built around "Constitutional AI" (training guided by an explicit set of principles); my pick for careful long-context reading and reasoning [5].
• OpenAI (GPT) — the broad default; most tutorials, SDKs, and community examples assume it [3][6].
• Google (Gemini) — the multimodal one: "multimodal" means the model accepts more than text, so it takes images, audio, and video as one input stream [7].

You send the same shape at every door. The flavor only matters when a feature leans on a specific strength — and the one that shows up most often in practice is multimodality: if the feature reads an image or an audio clip, Gemini is the natural first choice.

Picking a model tier within a provider

Each provider isn't one model — it's a ladder, and a tier is one rung on that ladder. There's usually a flagship (best reasoning, highest cost, slowest), a balanced mid-tier, and a mini/flash/haiku tier (cheap, fast, good enough for most UI work). The mistake I made early was reaching for the flagship for everything. A chat widget that answers FAQs does not need it; a mini model is a tenth of the cost and feels faster to the user. The question to ask is "what's the cheapest tier that still does this task acceptably?" — and to re-run the answer whenever a provider ships a new tier.

The decision that actually matters: where the call runs

This is the one I got wrong first, and the one I now think about before provider or model. There are two places the API call can live, and they are not equally safe:

• Server-side — code that runs on a computer you control (a route handler, a server action, an API route). The API key lives in an environment variable — a secret stored on the server, kept out of the code the browser receives. The browser never sees it. This is the correct default [1][2].
• Client-side — code running in the user's browser. Any key shipped to the browser is retrievable by anyone who opens devtools (the browser's built-in inspector). For a public site this is a leaked key waiting to happen.

So the rule I hold to: the provider key never reaches the client. The browser calls my own endpoint; my endpoint calls the provider with the secret; the response (or stream) flows back. The provider choice is almost secondary to getting this one right, because a leaked key is a bill with my name on it regardless of which provider it belongs to.

The shape of a correct integration, then, is two hops:

How I use this

The way of thinking leaves me with one triage whenever a feature needs AI. First, where does the call run — server, always, so the key is safe. Second, which provider — Anthropic for careful long-context reasoning, OpenAI for the broad default and easiest examples, Gemini for genuinely multimodal input. Third, which tier — start at the cheapest mini/flash/haiku that does the job, only climb when the output actually degrades. Get those three right and the integration itself is just the same shaped POST every time.

References

[1] Anthropic, "Anthropic API overview," Anthropic Docs, 2024. [Online]. Available: https://docs.anthropic.com/en/api/getting-started

[2] Anthropic, "Messages API," Anthropic Docs, 2024. [Online]. Available: https://docs.anthropic.com/en/api/messages

[3] OpenAI, "API overview," OpenAI Platform Docs, 2024. [Online]. Available: https://platform.openai.com/docs/overview

[4] Google, "Gemini API overview," Google AI for Developers, 2024. [Online]. Available: https://ai.google.dev/gemini-api/docs

[5] Anthropic, "Constitutional AI: Harmlessness from AI Feedback," Anthropic Research, 2022. [Online]. Available: https://www.anthropic.com/research/constitutional-ai

[6] OpenAI, "Models," OpenAI Platform Docs, 2024. [Online]. Available: https://platform.openai.com/docs/models

[7] Google, "Gemini — multimodal models," Google AI for Developers, 2024. [Online]. Available: https://ai.google.dev/gemini-api/docs/models