Keys, caps, and not doing something stupid
Three things can go genuinely wrong with a first AI project, and all three are avoidable in about twenty minutes. This lesson is that twenty minutes.
Do not leak your key
The rule from lesson 3, restated because it is the one that costs real money: the key never appears in code. Colab secrets, environment variables, or a secrets manager. Never a cell, never a config file you commit, never a screenshot.
If you ever suspect a key has been exposed, revoke it immediately in the provider's console and issue a new one. Revocation is instant and free. Deliberating about whether it was really exposed is how people end up on the wrong side of a bill.
Two habits that make this a non-issue: separate keys for separate projects, so revoking one does not break everything; and a monthly glance at the key list to delete anything you have stopped using.
Cap the spend, before you need to
Every provider offers spending limits and usage alerts. Set them now, while the number is small and hypothetical.
A hard monthly cap — the amount you are genuinely willing to lose. For learning, $10 or $20 is more than enough; lesson 4 showed a year of weekly runs coming to $181, so a low cap will not interfere with anything real.
An alert at half the cap, which is what actually tells you something is wrong.
The runaway is not exotic. A loop over a list you thought had 40 items and had 4,000. A retry with no attempt limit. A Gradio share link someone found. Each is a normal mistake, and a cap turns all of them into a lesson rather than an incident.
Three code habits that prevent the runaway
Always cap max_tokens. It bounds the most expensive part of every call.
Always bound retries. Lesson 10's loop stops at two attempts. An unbounded retry against a persistent failure is the classic way to run up a bill overnight.
Always run on five first. items[:5]. Every time, without exception. It is the single habit that catches the most expensive class of mistake, and it costs four keystrokes.
Choosing a model, cheaply
Providers offer a range: small and fast and cheap, up to large and slow and expensive, usually differing by ten times or more in price.
Develop on the small one. While you are debugging your loop and your parsing, model quality is irrelevant — you are testing plumbing. Switching to the cheap model during development costs nothing in learning and saves most of what you would otherwise spend.
Then compare on your real task. Run twenty real inputs through both and look at the outputs side by side. Often the cheap model is entirely adequate, which is a genuinely common finding and the reason "which model is best" is usually the wrong question. Where it is not adequate, you now know precisely what you are paying the difference for.
And check whether prompting fixes it before paying for it. A cheap model with a well-specified prompt and one retry frequently beats an expensive model with a vague one.
Data, briefly
Two questions worth answering once for whatever you build.
What are you sending? Look at the actual text going into the API. It is easy to build a pipeline that includes an entire file when the model needs two paragraphs, which costs more and sends more than you intended.
What does the provider do with it? API usage is generally not used for training by default on the major providers, and consumer chat products often differ from their APIs. Read the current policy for the endpoint you are using rather than assuming, and if you are handling anyone's data but your own, read it before you start rather than after.
The pre-flight list
Five checks before any run over more than about twenty items.
Estimated cost calculated. max_tokens set. Retries bounded. Tested on five. Results written to a file as they arrive.
Thirty seconds, and it is the difference between a run you can walk away from and one you cannot.
Do this today: set a spending cap and an alert in your provider's console. It takes four minutes and it is the only thing in this course that protects you from a mistake you have not yet imagined.