CS I · Thu Dec 10 · 18.4 · Do Now

Review 2: The Parts of a Tool

Open the discussion form on the right and answer Section 1 from your first reading.

Announcements

The Parts Between a Click and an Answer

This section reviews the parts that carry one Code Coach question from a Chromebook to a model and back, and what a user sees when one part fails.

Clients, Servers and the Model

In a web-based tool, each program plays one of two roles. A client is the program that starts an exchange by sending a request. A server is a program that waits for requests, handles each one and sends back a response. For example, when a student in the school library opens B24 and asks Code Coach about one line, the browser on her Chromebook is the client, because it sends both requests, one for the bench page and one for the explanation. The host is a server, not a client. It waits for requests and answers them.

The model runs on a server that belongs to Mistral, the company whose model Code Coach uses, and not on the Chromebook, because the computer that runs a model has to load its whole parameter file into memory. Hugging Face estimates that a model with 70 billion parameters needs about 140 GB of GPU memory, far more than a school Chromebook's 4 GB or 8 GB. A system prompt is a set of instructions that the builder writes ahead of time and sends to the model in every request. Code Coach's system prompt has six lines, and the bench puts the same six lines into each request beside the student's code. On October 19, 2026, the four lines below were sent to the class endpoint with that system prompt.

1int total = 25;
2int groups = 4;
3double each = total / groups;
4System.out.println(each);
6.0

The model's second explanation is quoted below, word for word.

This is Java code.

Line 1: Creates an integer variable named `total` and stores the value `25` in it.
Line 2: Creates an integer variable named `groups` and stores the value `4` in it.
Line 3: Creates a double variable named `each` and stores the result of `25 / 4`. Since both values are integers, it performs integer division, resulting in `6.0`.
Line 4: Prints `6.0` to the console.

The explanation matches the real output, because 25 divided by 4 is 6 in whole-number division.

The Host, DNS and HTTPS

A host is a server that stays connected to the internet, stores a site's files and sends them to any browser that requests them. The class site's host is Cloudflare, and deploying copies the site's current files from the repository to the host, so a fix that is committed but not deployed stays in the repository while browsers keep receiving the older files. The class endpoint is a different server from the host. One serves the page, and the other passes requests to the model. Both run on Cloudflare's network, and Mozilla's guide to HTTP notes that several server programs can run on the same machine.

A browser reaches a host through an IP address, which is a number, and IP addresses are hard to remember and can change over time, so people use a domain name such as muggsofcompsci.net. DNS, the Domain Name System, finds the IP address for a domain name, so that the browser knows where to send its request. DNS finds an address. It does not send the page, because the host sends the files once the request arrives.

HTTPS encrypts the data that travels between the browser and each server, but the code of the page still arrives in the browser, and anyone who opens a page can read that code. An API key is a secret string that lets its holder use a model account and spend its budget, so Code Coach's key is kept on the class endpoint as a secret setting and never appears in the bench page.

When One Part Fails

Figure 1 shows the parts in order, from the browser to the model's server. If the wifi fails, the browser cannot send any request, so neither the page nor an answer arrives. The network is one of the parts, too. If DNS fails, the browser has no IP address for the host, so the page does not load, while the host, the class endpoint and Mistral's server keep running. If the host fails, the page does not arrive either.

A failure past the page looks different, because the page and the answers come from different servers. If Mistral's server fails, the class endpoint sends back a message that begins "The model could not answer just now." in place of an answer. If the class endpoint cannot be reached at all, the bench shows its own note, quoted below.

Code Coach did not answer. The bench still works without it.

Every job and check still works, because the checks run in the bench page, and credit codes still work, because they come from a separate bench server, not the class endpoint. A page that loads and then gives no answers points past DNS and the host, to the class endpoint or the model's server.

Summary

The browser is the client: the host sends the bench page, the class endpoint holds the API key, and Mistral's server runs the model. DNS finds the host's IP address, and HTTPS encrypts the data on the way. A failure in the network, DNS or the host stops the page, while a failure at the class endpoint or the model's server leaves the page without answers.

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 a web server? (n.d.); MDN Web Docs, What is a domain name? (2025); MDN Web Docs, HTTPS (n.d.); Hugging Face, Optimizing LLMs for Speed and Memory (n.d.); Google Cloud, Best practices for managing API keys (2026); CS I passages of Oct 21–23 and Nov 16–19 (2026); Code Coach bench, class endpoint and captured request, course site (2026).

I Do questions
  1. notebook cue: client

    When you ask Code Coach about a line on the bench, what is the client?

    Check

    The client is the browser on the Chromebook, which runs the bench page. It starts the exchange by sending the request to the class endpoint, and the servers only answer. See Clients, Servers and the Model, paragraph 1.

  2. notebook cue: host

    The bench page comes from one server, and Code Coach's answers come through another. Name both.

    Check

    The bench page comes from the host, Cloudflare, at muggsofcompsci.net. The answers come through the class endpoint, which adds the API key and passes each request on to Mistral's server, where the model runs. See The Host, DNS and HTTPS, paragraph 1, and Figure 1.

  3. notebook cue: DNS

    If DNS failed, what would you see when you typed the course site's address, and which parts would still be working?

    Check

    The browser would have no IP address for the host, so the bench page would not load at all. The host, the class endpoint and Mistral's server would all still be running, because DNS only finds the address. See When One Part Fails, paragraph 1.

Figure 1. The parts of Code Coach from left to right, with DNS above the first arrow and HTTPS along each arrow from the browser.
I Do questions
  1. notebook cue: client

    When you ask Code Coach about a line on the bench, what is the client?

    Check

    The client is the browser on the Chromebook, which runs the bench page. It starts the exchange by sending the request to the class endpoint, and the servers only answer. See Clients, Servers and the Model, paragraph 1.

  2. notebook cue: host

    The bench page comes from one server, and Code Coach's answers come through another. Name both.

    Check

    The bench page comes from the host, Cloudflare, at muggsofcompsci.net. The answers come through the class endpoint, which adds the API key and passes each request on to Mistral's server, where the model runs. See The Host, DNS and HTTPS, paragraph 1, and Figure 1.

  3. notebook cue: DNS

    If DNS failed, what would you see when you typed the course site's address, and which parts would still be working?

    Check

    The browser would have no IP address for the host, so the bench page would not load at all. The host, the class endpoint and Mistral's server would all still be running, because DNS only finds the address. See When One Part Fails, paragraph 1.

The Parts Between a Click and an Answer

This section reviews the parts that carry one Code Coach question from a Chromebook to a model and back, and what a user sees when one part fails.

Clients, Servers and the Model

In a web-based tool, each program plays one of two roles. A client is the program that starts an exchange by sending a request. A server is a program that waits for requests, handles each one and sends back a response. For example, when a student in the school library opens B24 and asks Code Coach about one line, the browser on her Chromebook is the client, because it sends both requests, one for the bench page and one for the explanation. The host is a server, not a client. It waits for requests and answers them.

The model runs on a server that belongs to Mistral, the company whose model Code Coach uses, and not on the Chromebook, because the computer that runs a model has to load its whole parameter file into memory. Hugging Face estimates that a model with 70 billion parameters needs about 140 GB of GPU memory, far more than a school Chromebook's 4 GB or 8 GB. A system prompt is a set of instructions that the builder writes ahead of time and sends to the model in every request. Code Coach's system prompt has six lines, and the bench puts the same six lines into each request beside the student's code. On October 19, 2026, the four lines below were sent to the class endpoint with that system prompt.

1int total = 25;
2int groups = 4;
3double each = total / groups;
4System.out.println(each);
6.0

The model's second explanation is quoted below, word for word.

This is Java code.

Line 1: Creates an integer variable named `total` and stores the value `25` in it.
Line 2: Creates an integer variable named `groups` and stores the value `4` in it.
Line 3: Creates a double variable named `each` and stores the result of `25 / 4`. Since both values are integers, it performs integer division, resulting in `6.0`.
Line 4: Prints `6.0` to the console.

The explanation matches the real output, because 25 divided by 4 is 6 in whole-number division.

The Host, DNS and HTTPS

A host is a server that stays connected to the internet, stores a site's files and sends them to any browser that requests them. The class site's host is Cloudflare, and deploying copies the site's current files from the repository to the host, so a fix that is committed but not deployed stays in the repository while browsers keep receiving the older files. The class endpoint is a different server from the host. One serves the page, and the other passes requests to the model. Both run on Cloudflare's network, and Mozilla's guide to HTTP notes that several server programs can run on the same machine.

A browser reaches a host through an IP address, which is a number, and IP addresses are hard to remember and can change over time, so people use a domain name such as muggsofcompsci.net. DNS, the Domain Name System, finds the IP address for a domain name, so that the browser knows where to send its request. DNS finds an address. It does not send the page, because the host sends the files once the request arrives.

HTTPS encrypts the data that travels between the browser and each server, but the code of the page still arrives in the browser, and anyone who opens a page can read that code. An API key is a secret string that lets its holder use a model account and spend its budget, so Code Coach's key is kept on the class endpoint as a secret setting and never appears in the bench page.

When One Part Fails

Figure 1 shows the parts in order, from the browser to the model's server. If the wifi fails, the browser cannot send any request, so neither the page nor an answer arrives. The network is one of the parts, too. If DNS fails, the browser has no IP address for the host, so the page does not load, while the host, the class endpoint and Mistral's server keep running. If the host fails, the page does not arrive either.

A failure past the page looks different, because the page and the answers come from different servers. If Mistral's server fails, the class endpoint sends back a message that begins "The model could not answer just now." in place of an answer. If the class endpoint cannot be reached at all, the bench shows its own note, quoted below.

Code Coach did not answer. The bench still works without it.

Every job and check still works, because the checks run in the bench page, and credit codes still work, because they come from a separate bench server, not the class endpoint. A page that loads and then gives no answers points past DNS and the host, to the class endpoint or the model's server.

Summary

The browser is the client: the host sends the bench page, the class endpoint holds the API key, and Mistral's server runs the model. DNS finds the host's IP address, and HTTPS encrypts the data on the way. A failure in the network, DNS or the host stops the page, while a failure at the class endpoint or the model's server leaves the page without answers.

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 a web server? (n.d.); MDN Web Docs, What is a domain name? (2025); MDN Web Docs, HTTPS (n.d.); Hugging Face, Optimizing LLMs for Speed and Memory (n.d.); Google Cloud, Best practices for managing API keys (2026); CS I passages of Oct 21–23 and Nov 16–19 (2026); Code Coach bench, class endpoint and captured request, course site (2026).

Table Talk
A web-based AI tool stops answering. List three parts that could have failed.

Each table agrees on three parts, and on a way to test one of them.

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.

Open the discussion form

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: A web-based AI tool stops answering. List three parts that could have failed.

CR 1. Board Question: A web-based AI tool stops answering. List three parts that could have failed. 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. A web-based AI tool stops answering. List three parts that could have failed. Which position is closest to yours now?

  • The wifi, the Chromebook and the browser.
  • The host, the class endpoint and the model's server.
  • The system prompt, the user's question and the daily request limit.

MC 2. (Reading claim 1) A tool's page and its model can be on different servers.

  • Agree
  • Disagree

MC 3. (Reading claim 2) If the model's server fails, the tool's page will not load at all.

  • Agree
  • Disagree

MC 4. (Reading claim 3) An API key is kept on a server.

  • Agree
  • Disagree

MC 5. (Reading claim 4) When a student asks Code Coach about a line, the host is the client.

  • Agree
  • Disagree

MC 6. (Reading claim 5) DNS sends the bench page to the browser once it finds the host's IP address.

  • Agree
  • Disagree

MC 7. (Reading claim 6) In Figure 1, the class endpoint sits between the browser and the model's server.

  • Agree
  • Disagree

MC 8. (Reading claim 7) A fix that is committed but not deployed is not yet on the host.

  • Agree
  • Disagree

MC 9. (Reading claim 8) HTTPS hides the bench page's code from anyone who opens the page.

  • 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: A web-based AI tool stops answering. List three parts that could have failed. 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.