PHASE 0Beginner ~19 min· topic 6 of 7

Topic 0.6

How This Course Runs Code

In one line

Every key example runs on the page in Python, Java and JavaScript and prints the same output, using small scripted fake models so runs are free and repeatable. Real-model labs send your own requests to a free hosted model and show the real reply, tokens, timing and limits.

Think of it like this

Learning to drive in a simulator before the real road. The simulator is safe, free and lets you repeat the same tricky turn ten times. Then a real drive with an instructor shows you what the simulator can't: real traffic, real weather. This course has both: fake models for the mechanics and real-model labs for the real thing.

Words you'll meet

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

Fake model: A few lines of code that return scripted replies in the same shape as a real model API, used for learning and tests.
Simulated clock: A counter that stands in for time, so timing examples print the same numbers every run.
Lab: A block on the page that sends your request to a real, free hosted model and shows the full response.
finish_reason: The field in a reply that says why the model stopped: stop (finished), length (hit the token limit), or others (Topic 2.3).
Time to first token: How long you wait before the first piece of a streamed reply arrives.

Step by step

01Step 1: run the fake stream

The first example is a fake model that hands out its reply in eight pieces, the way real streaming APIs do. A simulated clock adds 300 ms before the first piece and 40 ms per piece. Run it in each language: the timeline is identical.

02Step 2: read the three versions

Python uses a generator (yield), JavaScript a generator function (function*), Java an Iterator. Three idioms, one idea: the caller gets pieces one at a time and can show each as it arrives. Phase 5 builds real streaming on exactly this.

03Step 3: make your first real call

Open the first lab below and press Send. Then look at three things: the reply, finish_reason (it should be stop), and the token counts. Open Raw HTTP to see the exact JSON request and response, and the x-ratelimit-* headers the provider sent back.

Step 3: make your first real calldiagram

Rendering diagram…

04Step 4: fall into the max_tokens trap on purpose

The second lab sets max_tokens to 60 on a reasoning model. Such models write hidden reasoning tokens before the answer, and those count against max_tokens. When the budget runs out mid-thought, you get finish_reason: "length" and little or no visible answer, while still paying for every token. Fix it: lower reasoning effort to low, ask for less, or give the model more tokens. Topic 1.8 explains reasoning models.

05Step 5: send the same request twice

Send the first lab again without changing anything. The wording probably changes. That is sampling (Topic 0.2) on a real model, and it is why the fake models exist: the course needs examples that print the same thing every time; your product needs code that copes when they don't.

Try it yourself

1
Change the simulated speed
In the stream example, change the per-piece time from 40 ms to 25 ms. Predict the last timestamp before you run it (300 + 8 × 25).
2
Switch languages
Run the stream example in all three languages and confirm the output is the same. Then find the line in each that formats [ 340 ms] with padding.
3
Compare models
In the first lab, switch the model to qwen/qwen3.8-27b and send. It doesn't write hidden reasoning: compare the completion token count and the total time with openai/gpt-oss-20b.

Code & diagrams

A fake model that streams, timed with a simulated clock New tab

Each language uses its own idiom for "one piece at a time": a generator in Python and JavaScript, an Iterator in Java.

Expected output

[ 340 ms] "Hel"
[ 380 ms] "lo"
[ 420 ms] "!"
[ 460 ms] " How"
[ 500 ms] " can"
[ 540 ms] " I"
[ 580 ms] " help"
[ 620 ms] "?"
reply: Hello! How can I help?
first piece after 340 ms, finished after 620 ms
average: 70.0 ms per extra word

Your first real model callreal model

Try: Press Send. Read the reply, then check finish_reason and the token counts below it. Open Raw HTTP to see the JSON and the rate-limit headers. Send again: is the sentence 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 (finish_reason is stop)
It is one short sentence (40 words or fewer)

The max_tokens trapreal model

Try: Send it as it is: with only 60 tokens the reasoning model probably runs out while thinking (finish_reason: length). Then make it finish properly without raising max tokens above 120: try reasoning effort low, or a shorter request.

System

user

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

Goals

finish_reason is stop
The answer is not empty

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

Print a raw list

In the Python stream example add print(list(fake_stream("hi"))[:2]), and the matching line in another language (System.out.println(List.of("Hel", "lo")) in Java, console.log(["Hel", "lo"]) in JavaScript). Run both.

terminal

$ Run

── what you'll see ──

Python prints ['Hel', 'lo'], Java prints [Hel, lo], JavaScript prints [ 'Hel', 'lo' ]

Myth vs fact

Myth

Fake models make the examples unrealistic.

Fact

The fakes return the same shapes real APIs return; everything around them (parsing, retries, streaming, validation) is real code. The labs cover what only a real model can show.

Myth

Running a model in a web page means the key is in the page.

Fact

Here the key stays on the server, which forwards your request. Never put a key in browser code: anyone can read it (Topic 2.4).

Pro corner

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

▸
The fake-model approach is also how professional teams test LLM code: unit tests use fakes, a smaller set of recorded real responses checks integration, and evaluations run against the real model (Topic 9.6).
▸
Reasoning tokens are billed as output tokens on most providers even though you don't see them. Watch completion_tokens_details.reasoning_tokens in usage when you budget (Topic 6.1).
▸
Free tiers have low shared limits. The lab shows 429 errors honestly when the shared quota is used up; production code must handle the same (Topic 6.7).

Remember this

1
Why fake models? A real model call needs an API key, costs money, takes a second or more, and gives a different answer each time. That makes it a poor teaching tool for mechanics like parsing, retries or streaming, where you need to see the same thing happen every run. A fake model is a few lines that return scripted replies in the same shape a real API uses. The mechanics around it are real code.
2
Three languages, same output. Pick Python, Java or JavaScript on any example; your choice is remembered across the site. All three versions do the same thing and print exactly the same lines. A checker runs every version on every change, so if a page says the output is X, all three really print X. Reading the other tabs is a quick way to learn how the same idea looks in another language.
3
How the code runs in your browser. Python 3.13 runs through Pyodide, Java 17 through a Java runtime compiled for the browser, and JavaScript in a Web Worker, all on your own device, with nothing installed. You must be signed in to press Run. Each run has a time limit, so a loop that never ends is stopped.
4
Rules that keep the three languages identical (useful in your own cross-language work): print strings you build yourself (Python prints True and ['a'], Java true and [a]); format decimals explicitly (f"{x:.2f}", String.format(Locale.ROOT, "%.2f", x), x.toFixed(2)); never rely on real randomness or the clock: examples use a seeded random generator and a simulated clock (clock_ms += 40).
5
The real-model lab. Lab blocks let you edit a real request (system prompt, messages, model, temperature, maximum tokens, streaming, JSON mode) and send it to a free model hosted by Groq. You see the reply, the model's hidden reasoning, finish_reason, token counts, time to first token, the raw HTTP request and response, and the provider's rate-limit headers. The API key stays on Hectal's server: your browser never sees it, which is exactly the pattern you will use in your own apps (Topic 2.4). Each signed-in learner has a daily number of lab requests.
6
Copy as code. Every lab can turn your current request into a program for your own machine, in curl, Python, JavaScript or Java, ready to run with your own free key. Topic 0.7 starts the playbook you will keep adding to in every phase.

Explain it without notes

Why does this course use fake models in runnable examples instead of real ones?

Why must an API key never be in browser code, and how does this site's lab avoid it?

What is the max_tokens trap with reasoning models?

Practice

Write a Python generator fake_stream(text, size) that yields the text in pieces of size characters, and print how many pieces "Hello! How can I help?" makes with size 5.

Write seeded_numbers(seed, n) that returns n numbers between 0 and 1 using state = state * 48271 % 2147483647, and print the first three for seed 42 to 4 decimal places.

Trade-offs

↔
Fake models: free, repeatable, fast, but only as realistic as their script. Real models: the true behaviour, but cost, limits and variation.

Done when you can

Done when you can run an example in all three languages.
Done when you have sent a lab request and found finish_reason, token usage and the rate-limit headers.
Done when you can explain why the key never reaches the browser.
Done when you can explain why reasoning models need a bigger max_tokens.

Command Palette