Why Your AI Integration Should Use the Client's API Key (Not the Vendor's)

Here's a pattern you'll see across the industry: studio builds an AI feature for client. Studio bills the client for "AI usage" on top of build cost. Studio uses their own Anthropic or OpenAI account. The client never sees the underlying API costs.

This is a bad arrangement for the client. Here's why we don't do it, and what we do instead.

The mark-up problem

API providers charge by tokens. Anthropic Sonnet is currently around $3/million input tokens, $15/million output tokens. A typical chat conversation costs a few cents.

When a studio bills "AI usage" without showing the underlying costs, they're marking up those numbers — usually 3-10x. A $5/month real cost becomes a $25-50/month line item on the client's invoice. Across hundreds of clients, that's a meaningful margin.

From the client's perspective, they're being charged opaquely for a commodity. They have no way to verify the costs. They have no way to negotiate. And if they ever switch studios, they have to rebuild the entire AI integration.

The lock-in problem

When the AI feature runs on the studio's account, the client has no direct relationship with the AI provider. They can't see logs. They can't tune parameters without going through the studio. They can't take the integration with them if the relationship ends.

This is vendor lock-in dressed up as service. It works fine when the relationship is healthy. It becomes hostile the moment something goes wrong.

The pattern we use instead

The client signs up for their own Anthropic (or OpenAI) account. They generate their own API key. We help them with this — it's a 5-minute task, not a barrier.

The integration we build uses that key. The keys live in environment variables on the client's hosting environment. Costs go directly to the client's account. They see every charge in real time. They control rate limits. They own the relationship with the AI provider.

If they ever leave us, the AI integration keeps working. They keep the code. They keep the API key. They keep the relationship. Nothing breaks.

What this costs us

Some studios think this pattern costs them margin. It doesn't. We charge for the build (the IP, the prompt engineering, the integration work), not for the API usage (which is a commodity). The build is the actual value. The usage is just the meter running.

What it earns us: clients who trust us. Word of mouth from clients who realized — usually after they migrated away from a previous studio that had been double-billing them — that this is how it should work. Long-term relationships built on transparency rather than dependence.

The implementation pattern

For AI features we build, the architecture is:

1. Client creates their own Anthropic or OpenAI account.
2. Client generates an API key, stores it in a password manager.
3. We add the key to the production environment as a secret env var.
4. The application reads the env var at runtime, no key in source code.
5. Client can rotate the key any time without our involvement.

Total setup time: about 10 minutes. Total cost saved over 12 months at typical usage: $300-1,500 per client, depending on volume. Total trust earned: substantial.

What to ask any studio you're hiring

"Whose API key will the AI feature run on?" If the answer is "ours, we'll handle it" — push back. Ask for the architecture in writing. If they refuse to use your API key, that tells you something about how they think about the relationship.

The right studios will be relieved you asked. It's the simplest signal that you understand what you're paying for.