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