PHASE 0Beginner ~24 min· topic 1 of 5

Topic 0.1

What an AI Feature Is

In one line

An AI feature sends text to a language model and shows the text that comes back. For the frontend, a model is a service that is slow, answers in small pieces, can answer differently each time, can be wrong without any error, and charges for every word.

Think of it like this

Asking a very well-read friend a question over a slow phone line. They start talking almost at once, but the answer arrives a few words at a time. Ask the same question tomorrow and they phrase it differently. Now and then they say something wrong in a perfectly confident voice. And the call is charged by the word. A language model is that friend, and your screen is the phone.

Words you'll meet

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

Language model (LLM): A program that takes text in and writes text out, one small piece at a time.
Prompt: The text you send to the model: a question, instructions, or content to work on.
Token: A small piece of text the model reads or writes: a short word, part of a word, or punctuation.
Streaming: Sending the answer piece by piece as it is produced, instead of waiting for the whole thing.
Time to first token: How long the user waits before the first piece of the answer appears.
Provider: The company whose servers run the model. Your server calls their API.
API: A set of web addresses on a server that programs (not people) call to get something done, such as POST a question and get an answer back.
Hallucination: A fluent, confident answer that is wrong or made up. Nothing in the response marks it.
Usage: The token counts a response reports: tokens in, tokens out and the total. Cost is based on them.
AI feature: A part of a product where a model's output is shown to a user or acts for them.

Step by step

01An ordinary request, for comparison

A normal API call is quick and exact. Ask for order ORD-1042 and you get that order: the same bytes every time, in milliseconds. You can show a spinner for a blink and then the result.

ordinary.jswhole filejs

const res = await fetch("/api/orders/ORD-1042");
const order = await res.json(); // { id: "ORD-1042", status: "shipped" }
// fast, always the same, either right or an error

02A model request: the answer arrives in pieces

The first example below reads a model's answer the way the browser really receives it: as a stream of small pieces. Each read() hands you the next piece. The console prints each one, and the sentence grows on the page.

Notice the leading spaces: " is", " tea". Tokens usually carry the space before the word, so joining the pieces with nothing in between gives the right sentence.

03Ask twice, get two answers

The second example asks the same question three times. The stand-in model is scripted to answer three ways, the way a real model does by itself. All three are correct. A test that expects one exact sentence would fail two times out of three.

04Wrong, with a success status

In the third example the model was never told the shop's policy (7 days), so it answers "30 days". Look at what your code can see: status 200, finish_reason: "stop" (the model finished normally), a tidy sentence. There is no field that says "this is a guess".

This is the most important habit in AI frontend work: a successful response is not a correct answer. Error handling protects you from failures. Only design (labels, sources, a way to check) protects the user from a wrong answer.

05Every answer has a price tag

The same response carries usage: how many tokens went in and came out. Providers bill on these numbers. You'll use them later to show a meter and to enforce limits (Phase 13).

Every answer has a price tagdiagram

Rendering diagram…

Try it yourself

1
Slow the model down
In the first example, change the call to tokenStream("…", { delayMs: 300 }). Predict how long the whole sentence takes now (9 pieces).
Each piece now takes about a third of a second, so about two and a half seconds in all (measured: 2.6 s). Imagine waiting that long with a blank screen instead of watching the words arrive: that is what streaming saves you from.
2
Make the time to first token long
Now try { firstDelayMs: 2000, delayMs: 20 }. The page is empty for two seconds, then the sentence appears quickly.
Real models often behave like this. It is the reason a waiting indicator ("Mitra is thinking…") matters even when you stream.
3
Spot the invented fact
In the third example, change the scripted answer to "Returns are accepted within 7 days." Run it again and compare the status, the finish reason and the usage with before.
Status and finish reason are identical, and the token count only changes a little (completion_tokens goes from 8 to 6). Your code has no way to tell which answer was true.
4
Stream Hindi text and an emoji
In the first example, change the sentence to "नमस्ते chai ☕". It arrives as three pieces: "नमस्ते", " chai" and " ☕", and the page shows them correctly.
The stand-in cuts on spaces, so every piece is a whole word. A real model cuts wherever its tokenizer says, and may split one emoji or one Hindi word over several pieces. Always append what arrives and never assume a piece is a word (Topic 2.3).

Code & diagrams

An answer arrives in pieces

tokenStream is this course's stand-in for a model's output: the same sentence, one piece at a time, with a short pause between pieces. The reading code is exactly what you would write for a real model. Press Run and watch the sentence grow.

Preview

Press Run to see the page.

Console

Nothing logged yet.

Expected console output

"Chai"
" is"
" tea"
" boiled"
" with"
" milk,"
" sugar"
" and"
" spices."
done: 9 pieces

The same question, three different answers

serve() and fakeOpenAI are explained in Topic 0.3. For now: the fetch call is real, and the answers are scripted to differ the way a real model's would.

Preview

Press Run to see the page.

Console

Nothing logged yet.

Expected console output

1. It ships in 2 days.
2. Delivery usually takes two days.
3. Expect it in about 48 hours.

A wrong answer looks exactly like a right one

Everything your code can check says success. The answer is still wrong. The last line is the usage the provider bills for.

Preview

Press Run to see the page.

Console

Nothing logged yet.

Expected console output

HTTP status: 200 (success)
finish_reason: stop
answer: You can return any item within 30 days.
tokens used: { prompt_tokens: 14, completion_tokens: 8, total_tokens: 22 }

Meet a real modelreal model

Try: Send this request to a real model. Watch the answer stream in. Then press Send two more times and compare the three answers: are any two word-for-word the same?

System

user

Modelsmall, fast, reasons firstTemperature · 1.0Max tokens (1–1024)Reasoning effort Stream (SSE) JSON mode

Goals

The reply finished on its own

Break it on purpose

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

Break #1

Expect one exact answer

In the second example, add a line at the end: console.log((await ask("How long does shipping take?")) === "It ships in 2 days.");

terminal

$ Console (last line)

── what you'll see ──

false

Myth vs fact

Myth

If the request succeeded, the answer is correct.

Fact

A 200 status only means the model produced text. The text can be wrong or invented, and nothing in the response marks it.

Myth

Streaming makes the model faster.

Fact

The total time is the same. Streaming shortens the time until the user sees something, which changes how the wait feels.

Myth

The same prompt always gives the same answer.

Fact

Models add randomness on purpose. Expect different wording each time, and design retries and tests around that.

Pro corner

Extra depth for experienced readers. New to this? Skip it for now and come back later.

▸
Token boundaries are not word boundaries, and they differ by model. Long or rare words split into several tokens, and a single emoji can be several. Never count on a token being a whole word or a whole character: Phase 2 shows a multi-byte character arriving in two network chunks.
▸
Time to first token is influenced by queueing and prompt length at the provider, and it has a long tail: typical requests can start quickly while a few in a hundred take many times longer. Design the waiting state for the slow case, and measure the 95th percentile in production (Topic 13.5), not the average.
▸
Usage is reported per response, and on a streamed response it usually arrives only in the final chunk (providers differ in whether you must ask for it). A request the user stops halfway can still be charged for the tokens produced so far, and you may never receive the usage numbers for it.
▸
A model has a maximum length for one answer. When it hits that limit it stops in the middle of a sentence, and the status is still 200: only the finish reason (length instead of stop) tells you. An answer can also come back empty. So a very long answer is not an error, but the screen should notice a cut-off one (Topic 1.1 shows the field).
▸
Non-English text and emoji usually cost more tokens than the same number of English letters, because tokenizers are built mostly around common English words. Two consequences: the same limit in tokens holds fewer characters, and a user writing in Hindi pays and waits more than one writing in English. Never size limits in characters and assume tokens follow.

Remember this

1
The problem this solves: An ordinary web page asks a server for data and gets a fixed, correct answer in a fraction of a second. A language model behaves nothing like that, and a screen built the ordinary way feels broken: it freezes for ten seconds, then dumps a wall of text. This topic gives you the five facts about models that every AI screen is designed around.
2
A language model (often called an LLM, large language model) is a program that takes text in and produces text out. You send it a prompt (your text: a question, instructions, a document) and it writes a reply. To the frontend it is one more service you call over the network. You don't need to know how it works inside to build good screens for it; the Hectal LLM Engineering course (/llm-engineering) covers that side.
3
Fact 1: it writes in pieces. A model doesn't produce a whole answer at once. It produces one token at a time. A token is a small piece of text: a short word, part of a longer word, a space with a word, a punctuation mark. "Chai is tea" might be three or four tokens. Because tokens come out one after another, the provider can send each one to you the moment it exists. That is streaming, and it is why AI apps show text appearing word by word.
4
Fact 2: it is slow. A database answers in milliseconds. A model may take half a second before the first token and several seconds, sometimes a minute, for a long answer. Two numbers matter: time to first token (how long the user stares at nothing) and total time (how long until the answer is complete). Streaming doesn't make the total shorter, but it makes the wait feel short, because the user is reading instead of waiting.
5
Fact 3: it varies. Ask the same question twice and you may get two different wordings, both fine. Models pick the next token with some randomness on purpose. For you this means: never write code that depends on exact words coming back, never treat two answers as "the same answer", and expect a retry to produce something new.
6
Fact 4: it can be confidently wrong. If the model doesn't know your shop's return policy, it may invent one, in fluent, certain language. Nothing in the response says so: the HTTP status (the number that tells you how the request went, where 200 means success) is 200, and the reply ends normally. Your code cannot tell a correct answer from a made-up one. So the screen must help the human judge it: say that it is AI-written, show sources where you have them, and never present a guess as an official fact. (Giving the model the right facts is the job of retrieval, taught in /rag.)
7
Fact 5: it costs money per token. Providers charge for tokens in (your prompt, including everything you resend) and tokens out (the answer). Every response reports the counts as usage. A feature that sends too much, or lets one user ask a thousand questions, runs up a real bill. That's why later phases cover limits, budgets and telling users when they have hit one.
8
Put together, an AI feature is any part of a product where a model's output is shown to, or acts for, a user: a chat assistant, a "summarise this" button, autocomplete, search that answers in sentences, a form that fills itself from a pasted email. The model is the engine; the hard part this course teaches is everything around it: waiting, streaming, stopping, failing, and staying safe and honest.

Explain it without notes

From a frontend developer's point of view, how is calling a language model different from calling an ordinary API?

What is a token, and why does it matter to the UI?

Why can't your code detect a wrong answer, and what does the UI do about it?

What is the difference between time to first token and total time?

Practice

List three AI features you have used in real products. For each, say whether it streamed its answer and how it told you the content was AI-generated.

Change the third example so the page (not only the console) shows the answer with a short honest label under it. Write the label text.

Trade-offs

↔
Streaming gives a fast first impression but means your UI must handle half-finished text, layout that keeps moving and a request that can fail in the middle. For very short answers, or output you can't show until it's complete, waiting for the whole response can be simpler and just as good (Topic 2.1).
↔
Labels and disclaimers build honest trust but become noise if overdone. One clear, calm label near the answer works better than warnings on every line.

Done when you can

I can explain what a language model is in one sentence a non-programmer would understand.
I can name the five facts about models that shape an AI screen: pieces, slow, varies, can be wrong, costs per token.
I can explain why a 200 response does not mean a correct answer.
I can explain time to first token and why streaming changes how a wait feels.
I can read a stream of pieces in the live editor and see them arrive.

Command Palette

Words you'll meet

Step by step

01An ordinary request, for comparison

02A model request: the answer arrives in pieces

03Ask twice, get two answers

04Wrong, with a success status

05Every answer has a price tag

Try it yourself

Slow the model down

Make the time to first token long

Spot the invented fact

Stream Hindi text and an emoji

Code & diagrams

Break it on purpose

Expect one exact answer

Myth vs fact

Pro corner

Remember this

Explain it without notes

Practice

Trade-offs

Done when you can