From Model to Tool
- Terminology and concepts to look out for: client · server · request
- Relevance to me: So far this unit has been about the model. Starting today, it is about the other parts of a tool. These are the parts that turn a model into something people can use.So far this unit has been about the model, the part everyone talks about. Starting today, it is about the other parts of a tool, the ones that do the unglamorous work. These are the parts that turn a model into something people can use.
- Board Question: When you type into MuggsAI (should I bring it back?), where is the answer made: on your Chromebook or somewhere else? Pick one and give your evidence.
Open the discussion form on the right and answer Section 1 from your first reading.
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.
I Do questions
-
notebook cue: client
In this room, which machine is the client when you use MuggsOfPrompts?
Check
The Chromebook is the client, because its web browser sends the request and waits for the answer. It is never the server in this exchange. See Clients and Servers, and the first step in The Path of One Prompt.
-
notebook cue: server
The server has no screen you can see. What is its job?
Check
A server waits for requests and sends back a response. In MuggsOfPrompts there are two: the course site's server checks the station's runs and passes the request on, and Mistral's servers run the models and send the text back. See Clients and Servers and The Path of One Prompt.
-
notebook cue: request
What does a request carry out, and what comes back?
Check
A request carries a URL, a method and sometimes extra information such as a cookie; in MuggsOfPrompts the browser's request carries only a cookie naming the station, not the prompt. A response comes back with a status code and the content, which here is the model's text in pieces. See What a Request Carries and The Path of One Prompt.
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.
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. The Chromebook, as usual, gets the applause.
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
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).
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.
I Do questions
-
notebook cue: client
In this room, which machine is the client when you use MuggsOfPrompts?
Check
The Chromebook is the client, because its web browser sends the request and waits for the answer. It is never the server in this exchange. See Clients and Servers, and the first step in The Path of One Prompt.
-
notebook cue: server
The server has no screen you can see. What is its job?
Check
A server waits for requests and sends back a response. In MuggsOfPrompts there are two: the course site's server checks the station's runs and passes the request on, and Mistral's servers run the models and send the text back. See Clients and Servers and The Path of One Prompt.
-
notebook cue: request
What does a request carry out, and what comes back?
Check
A request carries a URL, a method and sometimes extra information such as a cookie; in MuggsOfPrompts the browser's request carries only a cookie naming the station, not the prompt. A response comes back with a status code and the content, which here is the model's text in pieces. See What a Request Carries and The Path of One Prompt.
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.
I Do questions
-
notebook cue: client
In this room, which machine is the client when you use MuggsOfPrompts?
Check
The Chromebook is the client, because its web browser sends the request and waits for the answer. It is never the server in this exchange. See Clients and Servers, and the first step in The Path of One Prompt.
-
notebook cue: server
The server has no screen you can see. What is its job?
Check
A server waits for requests and sends back a response. In MuggsOfPrompts there are two: the course site's server checks the station's runs and passes the request on, and Mistral's servers run the models and send the text back. See Clients and Servers and The Path of One Prompt.
-
notebook cue: request
What does a request carry out, and what comes back?
Check
A request carries a URL, a method and sometimes extra information such as a cookie; in MuggsOfPrompts the browser's request carries only a cookie naming the station, not the prompt. A response comes back with a status code and the content, which here is the model's text in pieces. See What a Request Carries and The Path of One Prompt.
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.
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. The Chromebook, as usual, gets the applause.
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
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).
Each table decides: on the Chromebook or somewhere else. The table agrees on one answer and names one piece of evidence it could test.
Chromebooks stay closed while your table talks. Sections 1 and 2 of the discussion form are already done. After you talk, finish Section 3 right here under My View. Submit before the exit ticket.
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.
This form has three sections. Section 1: answer today's Board Question. Section 2: after the reading. Section 3 opens later in class. Today's Board Question: When you type into MuggsAI (should I bring it back?), where is the answer made: on your Chromebook or somewhere else? Pick one and give your evidence.
CR 1. Board Question: When you type into MuggsAI (should I bring it back?), where is the answer made: on your Chromebook or somewhere else? Pick one and give your evidence. Give your answer and one reason.
Write your answer in your lab notebook, labeled CR 1.
MC 1. Think about your answer to the board question. When you type into MuggsAI (should I bring it back?), where is the answer made: on your Chromebook or somewhere else? Pick one and give your evidence. Which position is closest to yours now?
- On the Chromebook, because that is where the answer appears.
- Somewhere else, on a server.
- Partly on the Chromebook and partly on a server.
MC 2. (Statement 1) A game that is already loaded can keep running after the wifi goes off.
- Agree
- Disagree
MC 3. (Statement 2) The web browser is the server.
- Agree
- Disagree
MC 4. (Statement 3) A request carries what a person typed to another computer.
- Agree
- Disagree
CR 2. (A different view) Write the view at your table that was most different from yours. If everyone agreed, write the strongest argument against your table's answer.
Write your answer in your lab notebook, labeled CR 2.
CR 3. Think about the Board Question again: When you type into MuggsAI (should I bring it back?), where is the answer made: on your Chromebook or somewhere else? Pick one and give your evidence. Do you have the same opinion as when you first answered the board question? If it is the same, what from the reading or table talk reaffirmed your opinion? If it is different, what from the reading or table talk changed your opinion?
Write your answer in your lab notebook, labeled CR 3.