For most people, "AI" means a chat window — ChatGPT, Claude. That window is a product, not the model itself. This lesson shows the other door into the exact same model, and how parameters and tokens — the words you already have — combine into a price you can go and look at today.
ChatGPT.com and Claude.ai are polished, friendly front doors — a conversation window, a send button, a company's own design — built by OpenAI and Anthropic around their models. That's a real, deliberate product. It is not the only way in, and for most of what actually gets built with this technology, it isn't even the usual way in.
There's a second door into the same model, meant for software rather than a person typing in a browser. It's called an API — the letters stand for Application Programming Interface, though almost nobody says the long version out loud.
An API is simply a door a piece of software can knock on: send some text in, get the model's prediction back out, with no chat window anywhere in between. Any business — one far smaller than OpenAI — can build its own product on top of that same door: its own interface, its own prompts and context from Lesson 8, wrapped around someone else's model.
Underneath the JSON and the pricing ahead, "the model" is still the coin-and-pegs machine from Lesson 1 — just enormous, and reached through a door instead of a hand. See the real device this course is modeled on.
Every provider phrases this a little differently, but the shape underneath is always close to this. Not a working example — no key here would get you a real answer — but the real shape of what a piece of software actually sends through that door.
curl https://api.example.com/v1/messages \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "model-large-2026",
"max_tokens": 60,
"messages": [
{"role": "user", "content": "In two sentences, why do Labradors make good family pets?"}
]
}'Look familiar? messages is Lesson 8's backpack, spelled out literally — "role": "user" is the dashed, just-added piece. Anything carried over from earlier in the conversation would sit right above it in that same array, unchanged, exactly like the boxed history in that diagram.
What comes back is just as recognizable:
{
"model": "model-large-2026",
"content": [
{"type": "text", "text": "Labradors are famously gentle and patient, which makes them steady around children and easy to train. Their friendly, people-focused temperament is exactly what most families are hoping to find in a dog."}
],
"usage": {
"input_tokens": 18,
"output_tokens": 42
}
}Two numbers at the bottom, and you already know exactly what they mean: input_tokens and output_tokens — the same two words the pricing strip ahead uses, reporting precisely what got charged for this one call. Nothing about a real API call was ever a mystery beyond this.
Remember Lesson 7's list of things a model genuinely can't do on its own — live facts, exact counting? This is how the wrapper covers for it, without changing what the model actually is.
A model can be trained to recognize one more shape of reply besides prose: a request. Instead of writing an answer, it writes something like "call this, with these inputs" — and the app watches every reply for exactly that shape. Watch the same messages array from a moment ago carry the whole exchange.
You ask something the model can't just know:
{"messages": [
{"role": "user", "content": "What's the weather in Provo, Utah right now?"}
]}The model doesn't answer in prose. It asks for help:
{"content": [
{"type": "tool_use", "name": "get_weather", "input": {"location": "Provo, UT"}}
]}The app actually calls a weather service — somewhere outside the model entirely — then pours the whole backpack through again: the original question, the model's request, and the real answer, all now sitting in the array together.
{"messages": [
{"role": "user", "content": "What's the weather in Provo, Utah right now?"},
{"role": "assistant", "content": [{"type": "tool_use", "name": "get_weather", "input": {"location": "Provo, UT"}}]},
{"role": "tool", "content": "72°F, clear skies"}
]}Only now does the model write something you actually see: "It's a clear 72°F in Provo right now."
Notice what didn't happen: the model never reached outside itself. It can't — all it has ever done, since Lesson 1, is predict the next tokens. Something outside the model made the real call, then poured the answer back in as one more piece of the backpack. The model just did what it always does: read everything in front of it, and leaned toward the likeliest next word. This time, the likeliest next word happened to be true, because the app made sure it was sitting right there in the context.
This is also the trick Lesson 7 promised. The weather lookup itself is deterministic — ask ten times, get 72°F back every time, because it's a real call to a real service, not a stray pick from a pile. The model's own phrasing of it can still vary a little; the fact it's phrasing now can't.
Walking through the API door isn't free the way the chat window often feels free. It's priced per token — almost always quoted per million tokens, because a single token costs a tiny fraction of a cent and nobody wants to read that many decimal places.
Two patterns are worth knowing, and both follow straight from what you already have. Bigger models — more parameters — cost more per token, because every prediction takes more computing to make. And output almost always costs more than input: reading your whole prompt happens in one pass, but Lesson 3's loop means writing the reply back out takes one full pass through the model per token, one at a time.
| Model size | Example price — input | Example price — output |
|---|---|---|
| ~3 billion | a few cents / million | a bit more |
| ~30 billion | tens of cents / million | a few times more |
| ~1 trillion + | a few dollars / million | several times more |
Illustrative shape, not live pricing — real rates vary by provider and change often. The pattern is what matters: bigger model, pricier token; output pricier than input.
Multiply this across many agents and many calls, and the bill becomes a real design problem — worth engineering against, not just budgeting for. How orqo engineers it down.
Sites like OpenRouter list dozens of models side by side — a menu a developer or a business picks from. Every row names a model, its size where it's published, and its price per million input and output tokens, exactly the shape of the table above, with real numbers instead of illustrative ones.
The first time this page makes sense to you, the fog around "AI pricing" mostly clears. It was never a mystery — it's a menu, priced the way we just described, and you now have every word on it.
Open a listing on a site like OpenRouter and you'll see a short line like this, for almost every model:
Three of those four words you already have. Context is the funnel size from Lesson 6 — this one holds up to a million tokens in view at once. Input and output are exactly the pricing pair from the table above — and notice output here really is nearly ten times pricier than input, the same pattern, now with real numbers behind it: one pass to read your prompt, one pass per token to write the reply.
The fourth word is new. Cache is the discount for not making the model repeat itself. Remember Lesson 3's loop: every single pass re-pours the entire growing line back through the funnel, from the very start — including everything that was already there a moment ago. If the model just walked through that same beginning on the last pass, a cache lets it remember that work instead of redoing it from scratch. You pay the small cache rate for the part it's just recalling, and the full input rate only for what's genuinely new. That's why $0.30 is so much smaller than $1.60 — it's the price of memory, not the price of reading something fresh.
When a business builds something powered by AI — a report generator, an assistant, an agent — it is almost never building a new model from scratch. It's choosing a door, pouring in carefully designed prompts and context, and wrapping the answer in its own product. The exact same pattern OpenAI used for ChatGPT itself, just a different front door.
It's the same path this platform itself takes. orqo is model-agnostic: every agent you build here calls out through exactly this kind of door, using whichever provider and model you connect. orqo handles the prompts, the context, and the orchestration; the answer comes back through the same door, priced the same way, and gets woven into your workflow. The same door, the same table, put to work. See how those workflows actually get built.
One door or the other, you're sending your words somewhere. The last lesson answers the question underneath all of this: what happens to it — so the last of the worry can go.
Everything from the lessons before this one, plus what this lesson added.
| The board | The word for it |
|---|---|
| The board and its pegs | The structure — the model |
| A single peg | A neuron |
| A single step from one peg to the next | A connection |
| How red or blue a patch of floor is | A weight — a parameter |
| The whole painted floor | The trained model |
| Boards stacked, one on the next | Layers — "deep" |
| Smearing the floor in, coin by coin | Training |
| Dropping one coin through a finished board | Using it — inference |
| Which slot you pour into | Your input — your prompt |
| The bins, relabelled with tokens | The vocabulary — every token it could pick |
| The tallest pile among the bins | The prediction — the likeliest next token |
| Feeding the growing line back in and running again | The loop — how one guess becomes a sentence |
| One bin's label, precisely | A token — not always a whole word |
| How many bins there are, in total | Vocabulary size — tens of thousands |
| The size of the mountain of text it was shown | Training data — measured in tokens |
| A bin's own address, plotted in space | An embedding — meaning turned into a list of numbers |
| How close two addresses sit | Similarity — how related two things are |
| The measurement's real name, out in the wild | Cosine similarity — same idea as similarity, different name |
| About meaning, not exact spelling | Semantic |
| A neighbourhood of addresses that share a topic | A domain — a cluster of related meaning |
| Scanning every address for whichever one sits closest to a new point | Nearest neighbor — the closest real match to a computed point |
| A small, separate machine that only plots words as points — it never writes a sentence | An embedding model — not the same as a language model |
| The total number of coloured patches, across every board | Parameters — the number people quote |
| How many tokens the funnel can hold in one pour | Input tokens — the context window |
| How many tokens come back out | Output tokens — what it writes back |
| Everything you've met so far, built at real-world size | A Large Language Model — an LLM |
| A shorter pile winning, extended forward with full confidence | A hallucination |
| The point where the training reading stopped | The knowledge cutoff |
| How sharp or blended the colour stays before a coin is poured | Temperature — the dial on how often a stray pick wins |
| Pouring the same slot twice, not always the same pile | Non-deterministic — same input, no guaranteed identical output |
| Background, examples, or a role, added right into the pour | Context |
| Asking for many small steps instead of one big leap | Chain-of-thought prompting |
| + New in this lesson | |
| A friendly chat window built around the board | A product — like ChatGPT or Claude.ai |
| A door that lets software pour in and read out directly | An API |
| What each million tokens costs to send in or get back | API pricing — pricier for bigger models, and for output |
| Recalling the start of the line instead of re-pouring it | Cached tokens — priced far cheaper than fresh input |
| The board asking the app to go do something real before it answers | Tool use — or function calling |
37 rows now. It keeps growing as the course goes on.