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).