How to Give Every Developer Their Own AI API Key (and See Who Spends What)

Short answer: stop sharing one AI API key. Put your team on one account with one balance, invite each developer by email, and have everyone create their own keys, plus one key per service and environment. Then usage is attributed automatically: you can see spend by person, key, project, environment and model without asking anyone. On the LazySusan API that's built in: invites are a one-click link, roles decide who sees what, and suspending someone stops all their keys at once.

Here's how to set it up properly, and the conventions that keep it tidy six months from now.

Why the shared key has to go

Almost every team starts with one key in a shared .env file. It works until it doesn't, and when it stops working it tends to stop all at once:

• No attribution. The bill doubled. Was it the new feature, a load test, or someone's weekend side project? With one key, every request looks the same.
• Rotation breaks everything. The key leaks in a screenshot or a public repo. Rotating it means updating every service and every laptop at the same time, so people put it off.
• Offboarding is a guess. When a developer leaves, they still know the key. Changing it is the rotation problem again.
• Limits are all or nothing. You can cap the whole account, but you can't stop one runaway script without stopping production too.

Every one of those problems disappears when each person and each service has its own key.

The model: one team, one balance, many keys

The structure that works:

• One team account that owns the balance and the billing. Credits are shared, so nobody has to top up their own key.
• Members who each sign in with their own login and have a role.
• Keys that belong to a member and carry a project, an environment and optional limits.

On LazySusan, every API account is already a team, and whoever creates it is the owner. A team can have up to 100 members (pending invites included) and 200 active keys; revoked keys don't count.

Pick roles before you invite anyone

Roles decide what people can change and, just as important, what they can see:

The common mistake is making everyone an admin to save a click. Developers only need their own keys. Give admin to the one or two people who manage spend, and viewer to whoever has to explain the bill.

Invite the team

In the console, open Team, enter one or more email addresses and pick a role. Each person gets an email with a one-click link:

• If they're new to LazySusan, clicking it creates their account and signs them in.
• If they already have an account, they sign in and they're on the team.
• Nobody needs a subscription, and links expire after 7 days (you can resend from the console).

A person can belong to several teams and switch between them, which is handy for agencies and contractors. Keys always belong to one team, and usage is billed to that team's balance.

Create keys with a naming convention

Every key has a name, a description, a project and an environment (production, staging, development or test). Use all four. A convention that scales:

Two kinds of key, two rules:

1. Personal keys are for a developer's laptop and experiments. Tag them development, give them a modest budget, and let them expire.
2. Service keys are for things that run without a person: production services, staging, CI. Create one per service and environment, so revoking one can't break the others.

Who should own service keys? Someone who isn't leaving soon. Removing a member revokes every key they own, which is exactly what you want for personal keys and exactly what you don't want for production. Give production keys to a lead or an admin.

Store keys like the secrets they are

A few rules that save a bad afternoon:

• Keys are shown once at creation. LazySusan stores only a one-way hash, so a lost key can't be recovered. Create a new one.
• Keep keys on your server. Never ship them in browser or mobile app code, where anyone can read them.
• Put service keys in your secrets manager and personal keys in a local .env that's in .gitignore.
• The SDK reads LAZYSUSAN_API_KEY from the environment, so code never has to mention the key:

import LazySusan from "lazysusan";

const ls = new LazySusan(); // LAZYSUSAN_API_KEY from the environment

await ls.chat.create({
  model: "anthropic/claude-haiku-5-5",
  messages: [{ role: "user", content: "ping" }],
  maxTokens: 50,
  metadata: { feature: "healthcheck" },
});

See who spends what

With keys split this way, the console's dashboard answers the questions you'd otherwise ask in Slack. Spend, requests, tokens, errors and latency are charted over any date range up to a year, by hour or by day, and you can break them down by:

• member: who made the requests
• key: which laptop or service
• project and environment: which product, and whether it was production or a test
• model and provider: what it ran on
• endpoint: chat, images or video

Every filter applies to the chart, the breakdowns and the request log at once. So "show me staging traffic on Claude Opus 5.5 last week" is three clicks, and the request log under it lists each call with its time, key, member, model, status, tokens, cost and latency. You can search by request id, filter by status or by a metadata tag such as feature=summaries, and export the filtered list as CSV.

Visibility follows the roles: owners, admins and viewers see the whole team, while developers see their own keys. If you want a weekly cost review without handing out admin rights, the viewer role is made for it. There's a fuller routine in AI API cost tracking for engineering managers.

Put limits on keys and people

Separate keys also make separate limits possible:

• Monthly budget per key. A personal key with a 20,000-credit ($20) budget can't turn into a $2,000 surprise.
• Monthly budget per member. Covers all of a person's keys, so creating more keys doesn't get around it.
• Allowed models. Limit a key or a person to a list of models. A member's list can be narrowed by a key's list, never widened.
• Expiry dates. Contractor keys and experiment keys should end on a date.

Requests outside those limits are refused before they run, so nothing is charged. The details, including how to size budgets, are in setting AI API budgets per developer, project and environment.

Offboarding and rotation

When someone leaves: remove them from the team. Every key they own is revoked, and it shows up in the audit log. If you're not sure yet (a long leave, a contract that might be renewed), suspend them instead: their keys stop at once, and you can lift it later.

When a key leaks: create a replacement, deploy it, then revoke the old one. Revocation takes effect on the next request, so there's no waiting for caches to expire. Because each service has its own key, only that service needs the new secret.

Routine rotation: for production keys, set an expiry date a few months out and calendar the swap a week before. An expired key fails with 401 api_key_expired, which is a much better way to find a forgotten key than a leak.

The audit trail

Owners and admins see a log of every invite, join, removal, role change, suspension, key creation, edit and revocation, budget and allowed-model change, alert, setting and credit purchase, each with who did it and when. When someone asks "who gave the intern access to Claude Fable 5.1?", that's where the answer is.

A one-page policy you can copy

1. Everyone gets their own login. Nobody shares a key.
2. Developers create personal keys tagged development, with a monthly budget and an expiry date.
3. Every production service has its own key, owned by a lead, tagged with its project and production.
4. Keys live in the secrets manager or a git-ignored .env, never in client code.
5. Every call carries a metadata tag for its feature.
6. Leavers are removed on their last day; leaked keys are replaced, then revoked.
7. Finance gets the viewer role and the CSV export.

It takes about twenty minutes to set up, and it's the last time anyone has to ask who spent what.

FAQ

Can I share one OpenAI or Anthropic API key with my whole team? You can, but you lose attribution, per-person limits and clean offboarding. A team account with a key per developer and per service keeps one bill while showing exactly who used what.

How do I see API usage per developer? On the LazySusan API, every key belongs to a member, so the dashboard breaks spend, requests and tokens down by member, key, project, environment, model and provider automatically.

What happens to a developer's keys when they leave? Removing them from the team revokes every key they own immediately. Suspending them stops their keys too, and can be undone later.

Can developers see each other's usage? Not with the developer role: they see their own keys and the usage of those keys. Owners, admins and viewers see the whole team.

How many keys can a team have? Up to 200 active keys and 100 members, including pending invites. Revoked keys don't count toward the limit.