CS I · Wed Oct 21 · 12.3 · We Do

Before the bell

You are responsible for all of this before the end of class.

The discussion form in the I Do deck. All three sections. If you are here, this should be done.
Your classwork. This form on the right. Section 1 before the exit ticket pops up; Section 2 past the floor.
Today's Bench Basics activity: Zip It. It opens later in class and lives on slide 4 of this deck.
The exit ticket. It opens 15 minutes before the bell and lives on the last slide of this deck.

Classwork

Sign out of Google when you finish on a shared computer, so the next student can sign in as themselves. Google then shows a "Redirect notice" page. Click the muggsofcompsci.net/cs1 link on it to come back.

One Prompt, Start to Finish

This reading follows one MuggsOfPrompts prompt through six steps and then describes three ways the path can break.

The Six Steps

(1) First, a student presses the RUN button, and the browser sends a request to the course site's server. (2) Next, that server reads the station's cookie and counts the station's previous runs today. (3) Then the server adds the day's stored prompt and sends three requests to Mistral's API, one for each model. (4) After that, Mistral's servers run the three models, and each model generates a separate response. (5) Next, Mistral's servers send the text back in pieces to the course site's server. (6) Finally, the course site's server passes each piece to the browser, which displays it in one of three panes.

While the student waits, the button reads "SENDING…" and a timer counts the seconds, which separates a working run from a stalled one. The panes fill with text as the pieces arrive, so the three answers grow at different rates.

Three Ways the Path Breaks

The first break is a lost network connection, which happens when the wireless network is disconnected. Without a connection, the browser cannot send its request, so nothing reaches either server, and the message "Lost the connection." appears on the page.

The second break is a server that does not answer, such as when Mistral's servers cannot be reached from the course site. In that case, the course site's server still responds to the browser, and the pane displays the words "Could not reach the model" instead of generated text. If a model has not finished within 45 seconds, the course site's server stops waiting, and the pane reports that no response came back in time.

The third break is too many requests arriving at once. A server that refuses requests arriving too quickly is practicing rate limiting, and its refusal carries the status code 429, which means Too Many Requests. MuggsOfPrompts displays "Rate limited." in the pane whenever Mistral refuses a request this way. The course site enforces its own limit as well by refusing a station's fourth run of the day.

Sources: MuggsOfPrompts code, course site (2026); MDN Web Docs, 429 Too Many Requests (2026); Mistral AI, Chat Completion API (n.d.).

One Prompt, Start to Finish, With Breakdowns

This entry follows one MuggsOfPrompts prompt through six steps and then describes three ways the path can break, because paths do.

The Six Steps

(1) First, a student presses the RUN button, and the browser sends a request to the course site's server. (2) Next, that server reads the station's cookie and counts the station's previous runs today, like a bouncer with a clipboard. (3) Then the server adds the day's stored prompt and sends three requests to Mistral's API, one for each model. (4) After that, Mistral's servers run the three models, and each model generates a separate response. (5) Next, Mistral's servers send the text back in pieces to the course site's server. (6) Finally, the course site's server passes each piece to the browser, which displays it in one of three panes.

While the student waits, the button reads "SENDING…" and a timer counts the seconds, which is how you tell a working run from one that has quietly given up. The panes fill with text as the pieces arrive, so the three answers grow at different rates, like a race nobody entered on purpose.

Three Ways the Path Breaks

The third break is too many requests arriving at once. A server that refuses requests arriving too quickly is practicing rate limiting, and its refusal carries the status code 429, which means Too Many Requests. It is the computer version of "one at a time, please." MuggsOfPrompts displays "Rate limited." in the pane whenever Mistral refuses a request this way. The course site enforces its own limit as well by refusing a station's fourth run of the day.

Sources: MuggsOfPrompts code, course site (2026); MDN Web Docs, 429 Too Many Requests (2026); Mistral AI, Chat Completion API (n.d.).

Clients, Servers and Requests

This section explains how a prompt travels from a web browser to the computer that runs a language model, and how the answer comes back.

Clients and Servers

Computers connected to the internet play one of two roles when they exchange messages. A client is a program that sends a request to another computer and then waits for an answer. A web browser, such as Chrome, is a client. The Chromebook running that browser is the client when a student visits a website, and it is never the server, because the browser always starts the exchange. A server is a computer that waits for requests and sends back a response. For example, the computer that stores a website is a server, and it sends a copy of the site to any browser that requests it. A server can be a single machine or a group of machines that share the work. The screen a student looks at is never the server, because a screen only displays what the browser has received.

What a Request Carries

Every exchange between a client and a server begins with a message from the client. A request is a message that a client sends to a server to ask for a file, some data or an action. Each request names the server and the item it is requesting with a web address called a URL, and it also states a method, such as getting a file or saving new data. A request can also carry extra information, such as form text or a cookie, which is a small piece of data that identifies the sender. The server reads the request and sends back a response, which includes a status code, such as 200 for success or 404 when the item cannot be found, along with the content that was requested.

For example, when a person types a web address, the browser first requests the site from its server. Next, the server sends the site's files in small chunks called packets. Finally, the browser puts the chunks together and displays the page. The HTML, CSS and JavaScript of a web page are downloaded this way and then run in the browser, on the client.

The Path of One Prompt

MuggsOfPrompts uses two servers, one after the other, and Figure 1 shows the path. First, a student presses the run button, and the browser sends a request to the course website, muggsofcompsci.net. That website is a Cloudflare Worker, a program that runs on Cloudflare's network of data centers. The request from the browser carries no prompt, only a cookie that identifies the lab station. The day's prompt is already stored on the course site's server, so a browser cannot change it.

Next, the course site's server checks how many runs the station has used. The limit is three runs per station per day, and the server refuses a fourth request. Then the course site's server sends three requests of its own to Mistral's API at api.mistral.ai, one for each of the three models. Each request carries the model's name, the instructions for the model, the prompt and a limit on how many tokens the model may generate. At this step the course site's server acts as a client, because it is the program sending the request.

Mistral's servers run the three models and generate the text, which then travels back along the same path it went out. Mistral's servers send the text in pieces to the course site's server, which passes each piece to the browser, where it appears in one of three panes as it arrives. The answer is generated on Mistral's servers and only displayed on the Chromebook.

Testing Where the Work Happens

A test with the network turned off shows which tools depend on a server. A student game in MuggsArcade, such as Snake Attack, is a single file that the browser downloads once, and after the game loads, it runs entirely in the browser. A MuggsArcade game sends no further request once it has loaded, so it keeps playing when the wifi goes off. MuggsOfPrompts cannot produce an answer without a request, because the prompt and the model are on servers. With the wifi off, the browser cannot send its request, and no answer comes back. Most web tools that use a model follow the same pattern as MuggsOfPrompts: a web page that sends a request, and a server that sends back a response.

Summary

A client sends requests, and a server waits for requests and sends back responses. In MuggsOfPrompts, the browser sends a request to the course site's server, which sends requests to Mistral's servers, where the model runs. A loaded MuggsArcade game sends no further request, so it keeps working without the network.

Sources: MDN Web Docs, Client-server overview (2026); MDN Web Docs, Overview of HTTP (2026); MDN Web Docs, How the web works (2026); MDN Web Docs, What is JavaScript? (2026); Mistral AI, Chat Completion API (n.d.); Cloudflare, How Workers works (2026); MuggsOfPrompts and MuggsArcade code, course site (2026).

Clients, Servers and Requests, or: Who Asks and Who Answers

This entry explains how a prompt travels from a web browser to the computer that runs a language model, and how the answer finds its way home.

Clients and Servers

Computers on the internet play one of two roles when they exchange messages, and neither role involves much small talk. A client is a program that sends a request to another computer and then waits for an answer, like a customer at a counter. A web browser, such as Chrome, is a client. The Chromebook running that browser is the client when a student visits a website, and it is never the server, because the browser always starts the exchange. A server is a computer that waits for requests and sends back a response. It spends its whole life waiting, and it does not seem to mind. For example, the computer that stores a website is a server, and it sends a copy of the site to any browser that asks. A server can be a single machine or a group of machines that share the work. The screen a student looks at is never the server, because a screen only shows what the browser has received. Screens take credit for a great deal they did not do.

What a Request Carries

Every exchange between a client and a server begins with a message from the client. A request is a message that a client sends to a server to ask for a file, some data or an action. Each request names the server and the item it wants with a web address called a URL, and it also states a method, such as getting a file or saving new data. A request can also carry extra information, such as form text or a cookie, which is a small piece of data that identifies the sender. It is not edible. The server reads the request and sends back a response, which includes a status code, such as 200 for success or 404 when the item cannot be found, along with the content that was requested.

For example, when a person types a web address, the browser first requests the site from its server. Next, the server sends the site's files in small chunks called packets. Finally, the browser puts the chunks back together and shows the page, rather like assembling furniture from a box, except it works. The HTML, CSS and JavaScript of a web page are downloaded this way and then run in the browser, on the client.

The Path of One Prompt

MuggsOfPrompts uses two servers, one after the other, and Figure 1 shows the path. First, a student presses the run button, and the browser sends a request to the course website, muggsofcompsci.net. That website is a Cloudflare Worker, a program that runs on Cloudflare's network of data centers. The request from the browser carries no prompt at all, only a cookie that identifies the lab station. The day's prompt is already stored on the course site's server, so a browser cannot change it, however creative it is feeling.

Next, the course site's server checks how many runs the station has used. The limit is three runs per station per day, and the server refuses a fourth request, politely and without exception. Then the course site's server sends three requests of its own to Mistral's API at api.mistral.ai, one for each of the three models. Each request carries the model's name, the instructions for the model, the prompt and a limit on how many tokens the model may generate. At this step the course site's server acts as a client, because it is now the program doing the asking. Roles, apparently, are about what you are doing, not who you are.

Testing Where the Work Happens

A test with the network turned off shows which tools depend on a server. A student game in MuggsArcade, such as Snake Attack, is a single file that the browser downloads once, and after the game loads, it runs entirely in the browser. A MuggsArcade game sends no further request once it has loaded, so it keeps playing when the wifi goes off, cheerfully unaware that anything has happened. MuggsOfPrompts cannot produce an answer without a request, because the prompt and the model are on servers. With the wifi off, the browser cannot send its request, and no answer comes back. Most web tools that use a model follow the same pattern as MuggsOfPrompts: a web page that sends a request, and a server somewhere else that sends back a response.

Summary

Classwork · Section 1 — Reading 2

MC 1. (Figure 1 · client) Which box in Figure 1 is the client?

Chromebook (browser), because it sends the first request and waits for the answer
muggsofcompsci.net/prompts, because it is the part closest to the student
Mistral API, because it is the part that sends the answer to the student
MuggsArcade game, because it runs on the Chromebook with no server at all

MC 2. (Figure 1 · server) Figure 1 shows two servers. Which one runs the model and generates the text?

Mistral API
muggsofcompsci.net/prompts
Chromebook (browser)
Both servers share the work of generating each answer

MC 3. (Figure 1 · request) In Figure 1, what does the first request arrow, from the Chromebook to muggsofcompsci.net/prompts, carry?

A request for a run, with a cookie that identifies the station
The day's prompt, which the browser sends to the course site
The model's text, on its way to the three panes
A copy of the model, so the Chromebook can run it

MC 4. (Six steps · first step) In Reading 2, what is the first step after a student presses the RUN button?

The browser sends a request to the course site's server
The course site's server sends three requests to Mistral's API
Mistral's servers run the three models
The browser displays the text in three panes

MC 5. (Six steps · second step) In Reading 2, after the browser's request reaches the course site's server, what does that server do before contacting Mistral?

It reads the station's cookie and counts the station's previous runs today
It copies the model's files to the Chromebook so the browser can run them
It asks Mistral's servers whether the station has runs left
It writes the student's prompt into the request before sending it

MC 6. (Six steps · third step) In Reading 2, how many requests does the course site's server send to Mistral's API for one RUN, and why that number?

Three requests, one for each of the three models
One request, which Mistral splits across the three models
Three requests, one for each pane in the browser
Three requests, one for each run the station has left

MC 7. (Six steps · fifth step) In Reading 2, after Mistral's servers generate the text, where does the text go next?

Back to the course site's server, in pieces
Straight to the browser, bypassing the course site
Into the station's cookie, so the next run can reuse it
Into the day's stored prompt, so the course site can read it later

MC 8. (First break · message) In Reading 2, which message appears when the wireless network is disconnected and the browser cannot send its request?

"Lost the connection."
"Could not reach the model"
"Rate limited."
"SENDING…"

MC 9. (Second break · timeout) In Reading 2, after how many seconds does the course site's server stop waiting for a model and report that no response came back in time?

45 seconds
30 seconds
60 seconds
3 seconds, the per-day run limit

MC 10. (Third break · status code) In Reading 2, what status code does a server send when it refuses requests that arrive too quickly, which MuggsOfPrompts reports as "Rate limited."?

429, Too Many Requests
404, Not Found
200, Success
45, the course site's timeout in seconds

CR 1. (MC 3 revisited) The first request arrow in Figure 1 carries a cookie, not the day's prompt. Explain why the browser does not send the prompt itself. Use one word from today's terms.

Write your answer in your lab notebook, labeled CR 1.

CR 2. (MC 6 revisited) The course site's server sends three requests to Mistral for one RUN. Explain why three, and name what is different between the three requests.

Write your answer in your lab notebook, labeled CR 2.

Figure 1. The path of one MuggsOfPrompts request through two servers and back, beside a MuggsArcade game that sends no further request once it has loaded.Figure 1. The path of one MuggsOfPrompts request through two servers and back, a fairly long trip for one answer, beside a MuggsArcade game that sends no further request once it has loaded and is perfectly content on its own.

Classwork · Section 2 — Past the floor

CR 3. (A time the path broke) Describe one time a website or app showed an error, timed out or refused a request. It can come from your own use, from someone you know or from the news. Say what the person was trying to do, what message appeared and what the person did next.

Write your answer in your lab notebook, labeled CR 3.

CR 4. (Which part failed) Look at the event you described in CR 3. Which part of the path failed: the client, the network connection or a server? Explain how you know, using one specific detail from the event.

Write your answer in your lab notebook, labeled CR 4.

Bench Basics

Zip It

Open the bench, do its six jobs, then paste your credit code into the credit-code form. You can turn in up to three codes per bench; your best score is your grade.

Bench Basics opens during your class period.

Classwork

Exit Ticket

This opens during your class period.