You are at a cafe with a club friend, and the tidy page is open on the laptop that has run the site since the train ride. You paste a messy group-chat message and press the button. The spinner that usually clears in a few seconds is past twenty, and the friend asks whether it is broken. You cannot answer. The cafe Wi-Fi may have dropped, your site may have failed, or the AI company may be slow; nothing on the screen says which. Twenty-three seconds after the press, the clean post appears. The panel that keeps a row for every press has been in your browser the whole time, and reading that row tells you which of the three it was.

What happens between the press and the answer

A request is the small note your device sends when you press a button: your text and which page it came from. When you pressed tidy, your browser put the pasted message on that note and sent it to your server, the site running on your laptop. A response is what the server sends back, and the browser puts it on the screen the moment it lands. Here is one press at the cafe:

You sent:   sat run?? 7am from the boathouse, 8k,
            coffee after, bring lights its dark
Came back:  Weekend run: 7:00 am from the boathouse,
            8 km, lights needed, coffee after.

A round trip means your device sends a request, a server does some work, and a response comes back. Every press on a connected product is one, and a like is the simplest: it asks the server to add one to a count.

Every tap on a connected product is a round trip: your device sends a request, a server does some work, and a response comes back.

Why the words appear one at a time in an AI chat is a screen behavior, taught in Frontend, what users see.

Open the panel and read your own row

DevTools is the inspection panel built into every browser, behind the page you are reading; right-click the page and choose Inspect to open it. The Network tab is the part of DevTools that lists every request the page sent, one row each. It records only while open, so at the cafe you open it, press tidy again, and watch. For 23 seconds the new row shows a pending mark and a clock counting, and then it fills in: 200 in one column, 23.4 s in the next.

The row's name says where the note went. An endpoint is the specific door on the server a request knocks on; builders also call it a route. An API is a door a company opens for programs instead of people. The tidy page's code knocks on /api/tidy; the RSVP page knocks on another.

The next column is the verdict. A status code is the server's verdict on the request, written as a number. A 200 means it worked, a code starting with 4 means the server refused the note, and a code starting with 5 means the server itself failed. The pending mark you stared at for 23 seconds means no verdict yet, and a row the browser could not send at all reads failed, in red.

A status code is the server's verdict: 200 means it worked, a code starting with 4 means the server refused it, and a code starting with 5 means the server failed.

The wait is the time from sending the request to the response finishing. Builders call it latency, and the Time column holds it: 23.4 s at the cafe.

Why a trip that worked still took 23 seconds

Distance versus work means the wait has two parts: travel time to the server, plus the time the server spends before it answers. Distance stays small: a note can cross an ocean and come back in around a tenth of a second. The tidy button asks for a whole message, and the model spends seconds producing the words, so nearly all of that wait is work.

The cafe row is the long bar. The note crossed the cafe Wi-Fi in a blink, and the rest of the 23 seconds was the model producing the message at the far end. The provider is the AI company whose model you rent, and that far end is the provider's computers, not your server.

The obvious objection: a spinner is a spinner

Why does it matter which side failed, when the user sees the same spinner either way? Each suspect needs a different move from you and a different message to the user.

If the row reads failed or never appears, the user's connection is the problem: say so, and fix nothing on your side.
If the verdict starts with 4 or 5, your server refused or failed: the fix is yours, and the user should hear that you are on it.
If there is no verdict for a long time and then a 200, the provider was slow. Wait it out, or set a limit on the wait and tell the user to try again.

The second trip, and the one thing that travels only on it

Your server did not write that message. It sent a note of its own to the provider's API, the way your browser knocked on /api/tidy. Builders count this as two trips: the first trip runs from your user's browser to your server, and the second from your server to the AI company.

The second note carries one thing the first never does. An API key is a long secret string sent with the request that tells the provider whose account to bill. It is the pass from the plan's secrets line, and it works like a membership card. The key lives on your server, and only your server shows it to the provider. Anything sent to a browser can be read by whoever holds it, so a key on the first trip could be copied and billed to you.

In the drawing, the key is the only label that differs between the two trips.

Every AI answer you ship is two round trips: your user's browser to your server, then your server to the AI company. Your API key travels only on the second one, because anything sent to a browser can be read by whoever holds it.

Try it now

This drill takes about ten minutes. The no-setup path costs nothing, and the tooled path costs a few cents of usage: a fraction of a cent per short request, charged to the account the API key names. You arrive with the idea file and the verdict list from Where software lives; pick an app you marked remote, ideally an AI chat.

No setup: Open that AI chat in a desktop browser, right-click the page, choose Inspect, and click Network in the panel that opens. Expect a wall of rows, one per image and font the page loaded. Press the clear control so the list empties. Then type one message into the chat: "Give me a two-line summary of the water cycle." Read the new row at the top: its name, then the status staying pending while the words arrive, then the 200 and the time. Last, find the slowest row and decide whether its wait was distance or work.

With your tools: With the Network tab open on the running-club site, paste a messy message into tidy and read the /api/tidy row. Then ask Claude Code, the AI coding tool we use in this course: "Which file sends the request to the AI provider, and where does the API key come from? Do not print the key." It names app/api/tidy/route.js (the door, written as a file) and the secrets file from the plan. The page your browser receives, app/tidy/page.js, never holds the key. In Codex or Cursor, ask the same question in the app's chat box and keep the do-not-print line. The Setup Clinic gets you installed.

Either way, you leave with the idea file one line longer and one row read. The line to add: "My AI feature is two trips; the key stays on my server; the slowest request I read was [what], [how long], mostly [distance or work]."

Chapter Summary

Every press on a connected product is a round trip: your device sends a request, a server does some work, and a response comes back.
The Network tab in your browser's DevTools lists every request the page sent, one row each, and it records only while it is open.
A row tells you three things: where the request went (the endpoint, a door on the server), the server's verdict (the status code), and how long it took (the wait).
200 means it worked, a code starting with 4 means the server refused the request, a code starting with 5 means the server failed, and a pending mark means no verdict yet.
Every wait is distance plus work: the trip to the server is small, and for an AI answer nearly all of the wait is the model producing the words at the far end.
A slow or failed request has three possible causes, each with its own fix. A row marked failed means the user's connection dropped, a code starting with 4 or 5 means your server is at fault, and a long pending mark followed by a 200 means the AI provider was slow.
Every AI answer you ship is two trips, browser to your server and your server to the AI company, and the API key travels only on the second one, because anything sent to a browser can be read.
A 200 says the trip worked, not that the answer is right; reading the answer is still your job.
Your artifacts from this chapter are the idea file, now carrying the two-trips line, and one row read from your own browser.
Next, Languages and frameworks: approve the pick asks what both ends of that trip are written in, and how to approve the agent's pick.

Sources

Chrome DevTools documentation, Network panel reference: recording while the panel is open, the Status and Time columns, and the Clear control (last verified September 2026).
Firefox Source Docs, Network Monitor section (last verified July 2026).
MDN Web Docs, HTTP overview and status code reference (last verified September 2026).

The journey of a request