Coursework

lesson 01

What is an API?

API stands for Application Programming Interface. Strip the words down and it means: a defined way for one piece of software to talk to another. It's not a product you buy — it's a contract. One side promises "ask for things in this format, and you'll get answers in that format." The other side makes the ask.

On the internet, APIs are how almost everything works. Your weather app doesn't invent forecasts — it calls a weather service's API. Your banking app checks your balance through an API. A game fetches the leaderboard through an API. In practice it's a plain request over HTTPS to a URL (called an endpoint), carrying your question, and a response carrying the answer — usually as JSON, which is just structured text a program can parse.

lesson 02

What is a provider?

A provider is a company or service that runs AI models and sells you access to them over an API. They own the servers, the GPUs, the billing system, and the key management. You send requests, they send answers, they charge by usage.

Keep two words straight, they get mixed up constantly:

• Provider — who serves it. (The restaurant.)
• Model — what's being served. (The dish.)

One restaurant serves many dishes, and one dish can appear on many menus — open-weight models can be hosted by their original maker or by other companies.

lesson 03

What is a model?

The model is the thing itself: a large trained neural network that takes text in and produces text out. It's what people mean by "AI" in "AI tool" — everything else on this track is infrastructure around it.

How it works, honestly and without magic: a language model is an enormous pattern-matcher trained on mountains of text, learning to predict what chunk of text plausibly comes next. Ask it a question, and it generates an answer one piece at a time, each piece chosen by probability. "Autocomplete on a colossal scale" is reductive, but it's the right intuition to start from.

Two consequences fall straight out of that design, and they explain most of what confuses beginners:

• It doesn't look things up — it generates plausible continuations. When plausibility and truth diverge, you get a hallucination: stated with total confidence, and wrong.
• It has a knowledge cutoff — a date after which its training data simply stops. It doesn't know what happened last week unless you or a tool hand it that information.

Models are versioned. Providers ship updates under new names, retire old ones, and the names carry version markers. When a tool shows a model dropdown, each entry is one of these versions — and switching entries changes capability, speed, and price.

lesson 04

What is an API key?

An API key is a long, secret string of characters that identifies you to the provider. Every request you send carries it, and it does two jobs: it proves who's asking, and it points the bill at your account.

The rules, and they're all one rule: the key is you.

• Never hardcode it into code. Code gets shared — pasted into chats, pushed to GitHub, shown in tutorials. Assume anything in source code becomes public.
• Never paste it anywhere textual — chat logs, issue threads, screenshots, terminal recordings, streams. The classic leak is a key visible in a shared screenshot for eleven seconds.
• Keep it in an environment variable (lesson 05), not in your files. Code holds the name of the variable; the secret stays outside.
• If it leaks: revoke it first, ask questions after. Deleting the line from your file changes nothing — assume it's compromised, kill it in the provider's console, generate a new one.
• One key per project. Kill a compromised key without breaking everything else — and you can tell which project is spending what.

What actually goes wrong when a key leaks: automated scanners find it — often within minutes — and start sending requests against your account, burning your credit until someone notices. Provider consoles let you set spend limits on keys; set them before you need them (lesson 09).

lesson 05

What is an environment?

This word carries two meanings in daily use, and beginners get tangled because nobody flags that they're different things. Learn both — you'll meet both.

Meaning one: an environment is where software runs. Your laptop is an environment; a cloud server is an environment. Teams habitually label them — development (you, experimenting, breaking things freely), staging (a rehearsal copy), production (where the public is, do not experiment here). The point of separate environments is that config differs between them: development might use a free test key; production uses the real one with real limits.

Meaning two: environment variables are named slots of configuration your programs inherit from the system. Think of them as labeled bottles sitting in the process's environment — the OS fills them, every program that runs can read them. One bottle might be named OPENAI_API_KEY and hold your secret. Your program reads the bottle by name; the secret itself never appears in the code.

This is why every setup guide says "export your key" or "add it to your environment." It's the wall between the two kinds of information:

• Code — shareable, committed to git, shown to the world.
• Config — secrets, per machine, never committed.

One more piece of vocabulary: .env files. Developers keep a small local file listing a project's environment variables — one line per bottle — so they don't retype them every session. Two habits make this safe: .env goes in .gitignore so it never travels to GitHub, and a template file like .env.example lists the names with placeholder values so teammates know which bottles to fill.

lesson 06

What is a prompt?

A prompt is the text you send to the model — your side of the conversation. Nothing more mystical than that. It's what lesson 03's autocomplete reads before guessing the next piece.

What you type is rarely the whole prompt, though. Real tools send a stack:

• System prompt — standing rules written by the app: who the assistant is, how to behave, what to refuse. You don't see it, but it's why the same model feels different in two different tools.
• Conversation history — everything said so far, replayed each turn (which is why history matters and why tokens add up).
• Your message — this turn's instruction.

What makes a prompt actually work comes down to three ingredients:

• Context — the background the model can't guess: who's the audience, what's already been tried, what the constraints are.
• Specificity — the exact ask. "Make it good" means nothing; "cut it to three bullets, plain language, no marketing words" means everything. Example beats adjective — show one paragraph you like and say "like this."
• Output shape — the format you want back: a list, a table, code only, under 100 words. Say it and you won't have to redraft.

lesson 07

What is a token?

A token is the unit models actually work in. Before anything runs, your text gets chopped into subword chunks — tokens — and every limit, every price, every "the AI forgot" moment traces back to counting them.

Common words fit in one token; unusual or long words split into several. A workable rule of thumb for English: one token ≈ ¾ of a word — so 100 tokens is roughly 75 words. It's a thumb, not a law; but it gets you in the neighborhood whenever you're reading a bill or a limit.

Two numbers that suddenly make sense once you know tokens:

• Context window — how many tokens fit into the model's working memory at once: your message, the whole history, everything else in the request, minus the room reserved for its reply. Run past it and either the oldest content gets dropped or the request is rejected — either way, that's "why did it forget what we said twenty messages ago."
• Price — providers bill per input token (what you send) and per output token (what it writes), usually with output costing more per token. Long prompts plus long answers multiply, and suddenly the metered feeling of AI billing is obvious.

lesson 08

How one request actually flows

Every lesson above is a station on one line. Here's the whole journey — you type a message, and about a second later words appear on screen:

1. The app builds the request. Your message joins the system prompt and the conversation history. (Lessons 06, 01.)
2. It reads your key from the environment — the bottle named OPENAI_API_KEY — and attaches it to the request. The secret never sat in the code. (Lessons 05, 04.)
3. It sends the request — one HTTPS call to the provider's endpoint. (Lessons 02, 01.)
4. The provider checks the key, confirms the account exists and has quota left, then routes the request to the model running on their servers. (Lessons 04, 02, 03.)
5. The model generates — tokens produced one after another, not all at once. (Lessons 03, 07.)
6. The response streams back — that smooth "typing" effect you've watched a hundred times is exactly this: tokens arriving as they're made, not a message held back until it's finished.
7. The app renders it, records the token usage, and the provider's meter adds input and output tokens to your bill. (Lesson 07.)

That's the full loop, end to end. Every entry in the field log on this site started as a request shaped exactly like this one — and when one broke, the debugging was walking this list in order: key? endpoint? quota? model? output?

lesson 09

Keeping your keys and your bill safe

Lesson 04 covered what a key is. This is the standing routine — boring on purpose, because everything here is the cheap version of a very expensive mistake.

• Set a spend limit before real use. Every provider console has caps — daily or monthly hard limits. A key with no cap is a key that can spend without you. Set the cap while nothing's wrong.
• One key per project, revoke freely. Rotation is routine, not an emergency drill. If you even suspect exposure, kill the key — a false alarm costs two minutes.
• Check the usage dashboard weekly until you trust your setup. A surprise spike means one of two things: runaway code, or someone else has your key. Either way you want to find out on a Tuesday, not on an invoice.
• 429 means slow down, not broken. That's a rate limit — the provider asking for fewer requests per minute. Back off and retry later; hammering it changes nothing.
• Screenshot discipline. Before sharing any terminal, config, or log: scan it for key-shaped strings. Blur or don't share. This one habit prevents the most common leak there is.
• Privacy is part of safety. Whatever you send to the API is visible to the provider. Check retention settings, and never send credentials or data you're not allowed to share — including in prompts "just to test."
• Free tiers are for learning — they exist so you can do exactly what this track teaches without risk. Use them until the setup is habits, then scale.

recap

Every term in one line

• API — the contract that lets software talk to software.
• Endpoint — one address on that contract; you ask here.
• Provider — the company that runs models and sells access.
• Model — the trained network that turns text into text.
• Prompt — the text you send: system rules, history, your ask.
• API key — your secret identity, and the tab your usage is billed to.
• Environment — where the code runs; environment variables — named config slots it inherits, where keys are supposed to live.
• Token — the chunk models read, count, and bill by (≈ ¾ of a word).
• Context window — how much fits in working memory at once.
• Streaming — tokens arriving as they're generated; the typing effect.

Track 02 (workflows) and 03 (experiments) build on these — same vocabulary, put to work.