Why the contract and the invoice should be yours
When a supplier or consultant uses their own account, your data passes under their agreement with the AI provider, and the cost becomes a line on someone else's invoice. If the relationship ends, the application stops working the day the key is withdrawn. With your own account, you accept the provider's terms directly, choose the data processing options it offers business customers, see usage on your own invoice and can hand a key to whoever builds the next thing. OpenAI and Anthropic both offer API accounts for organisations, with several members and roles.
Where keys must never be kept
An API key in frontend code is public. Anything that runs in the browser or ships inside a mobile app can be read by anyone who looks, and automated scanners search public code for leaked keys all the time. Keys do not belong in the repository either, not even a private one, because the history is kept and repositories are copied, shared and made public by mistake. The same goes for chat messages, tickets and shared documents. A key that has ended up in any of those places should be revoked and replaced, not just deleted from the file.
Where keys should be kept
Keys belong on the server side, in environment variables or a secrets manager, read only by the code that calls the provider. Locally that means an .env file listed in .gitignore; in production, the hosting platform's secret store or a dedicated vault. Each environment gets its own key, so a test system can be shut off without touching production. When several applications call AI, a gateway can hold the provider keys and hand out its own keys per application, as described in what an AI gateway is.
One key per project, not one for everything
Both OpenAI and Anthropic let you divide usage up: OpenAI into projects and Anthropic into workspaces, each with its own keys and its own usage figures. When every application and environment has its own key, it is clear what drives the cost, the damage from a leak is limited, and one key can be revoked without stopping everything else. Name keys after what uses them, write down who created them and remove keys that are no longer used. A single shared key for the whole company makes all of that impossible.
Spending limits at the provider and in a gateway
The first line of defence is the limit you set in the provider's console, for the organisation and, where it is offered, per project or workspace. It is coarse but reliable, because it applies whatever happens in your own code. The second line is caps closer to the application: budgets per project, customer or feature, rate limits per key and alerts before a limit is reached. A gateway such as ModelHarbour combines the two, with budget caps, rate limits and a webhook when a budget nears its limit, plus a hard cap set at the provider.
What usage costs depend on
Providers charge per token, the pieces of text models read and write, with separate prices for input and output, and output usually costs more. The choice of model matters most: the largest models can cost many times more per token than the small ones, and a small model is often enough for sorting, extraction and short answers. Prompt length comes next, since a long system prompt or a large document is paid for on every call. Prompt caching lowers the price of input that repeats between calls, and batch interfaces are cheaper for work that can wait. Current prices are on each provider's pricing page.
Following usage over time
A sudden jump in cost tends to come from a loop, a retry without a limit, a prompt that has grown or a new feature that calls the model on every page view. In the beginning, look at usage per key every week, and compare what the application itself has counted with what the provider invoices. A difference between the two is the earliest sign that something is calling the model outside your control.