Keys, spend caps, and the bill nobody wants

The failure that hurts

A student pushes a small project to a public code repository. The API key is in a configuration file. Automated scanners find keys on public repositories within minutes (this is a well-documented, industrialised activity) and someone else’s job now runs on that account. The first the student knows is the invoice.

This is common enough that the major providers scan public code themselves and revoke keys they find. Do not rely on being rescued.

Five rules, in order of importance

1. Set a hard spend limit on day one. Every provider console has a billing page with a maximum monthly spend and email alerts at thresholds. Set the maximum to something you could pay without difficulty: for a person learning, $5 or $10. This is the single most important step and it takes ninety seconds. Do it before your first request, not after your first surprise.

2. Never put a key in a file you might share. Keys live in environment variables or in a .env file that is listed in .gitignore.

export OPENAI_API_KEY="sk-..."          # in ~/.zshrc or ~/.bashrc
echo ".env" >> .gitignore               # before the first commit, not after

Note the ordering. Adding .env to .gitignore after you have committed it does nothing; the key is already in the history, and deleting the file in a later commit does not remove it from the repository.

3. One key per use. A key for your laptop, a key for the small tool you wrote, a key for the front-end app. When one leaks, you revoke one key and everything else keeps working. A single shared key means a leak takes down everything you have.

4. Revoke rather than investigate. If you think a key may have leaked, delete it in the console and make a new one. It takes twenty seconds and costs nothing. There is no situation where waiting to be sure is the better move.

5. Check the bill in the first week. Usage dashboards show spend by day and by model. Look on day three. The gap between what people expect and what they spend is largest at the start, and it is almost always a loop that ran more times than intended.

Where the money actually goes on an API

Three patterns account for nearly every unexpected bill:

Resending the conversation. In a chat, every turn resends everything before it. A long conversation’s twentieth message costs many times its first. Most front-ends let you limit how many previous messages are sent; a window of the last ten is usually plenty.

A loop with no limit. Something that retries on failure, or processes a list that is longer than you thought. Always test on ten items before running on ten thousand, and print the running cost.

Thinking mode left on. Hidden reasoning tokens are billed at the output rate. A per-request cost can be ten times what the visible answer suggests.

Sharing a key with other people

Do not. If a colleague needs access, they create their own account, or you use a provider or router that issues separate keys with separate limits per person. A shared key means shared spending, no way to tell whose request cost what, and no way to cut off one person.

The same applies to a key inside anything a user can reach. A key in a mobile app or in a web page’s JavaScript is a public key, no matter how it is obfuscated, because anyone can read what their own device received. Requests from a browser or an app have to go through a small server of yours that holds the key.

The honest comparison with a subscription

A subscription has one genuine advantage that gets overlooked: it cannot surprise you. The price is the price, and a runaway loop just gets you rate-limited rather than billed. For somebody on a tight budget who is not confident about what they are running, that predictability is worth real money.

Use the API when you want control and low cost per use, and set the cap so that the worst case is a bad afternoon rather than a bad month.