When you use a coding agent, you see its answers and its work in the terminal. We can also inspect the messages its harness sends to the model. We'll run a small program called a reverse proxy, look inside a captured request, and find the system prompt supplied by the harness.
The terminal shows the agent's answers and reports its tool activity. Behind that display, the harness exchanges messages with the model service. Seeing the answer alone does not tell us everything that went into the request.
The request includes the conversation, instructions supplied by the harness, and descriptions of the available tools. We want to see those messages directly. That lets us examine the input to the model instead of trying to infer it from the answer.
A reverse proxy is a program that receives a request on behalf of another server and forwards it there. We put ours between the harness and the model service. The harness sends its request to the proxy, and the proxy passes it on.
The model service sends its reply back through the proxy, which returns it to the harness. The agent can carry on working through this extra step in the connection.
We wrote this proxy as a small Python script, proxy dot py, which comes with this video. It forwards each message unchanged and prints the requests and replies as they pass through. That is all we need to understand about its implementation here. It gives us a view of the exchange while the agent continues its work, and we can later build a more convenient way to inspect the same traffic.
Download the supplied Python script and run it in one terminal with the port option shown here. It uses Python three and needs no extra packages. The script is now listening for requests on your own computer.
In another terminal, start Claude Code with the base URL set to the proxy's local address. This environment variable sends Claude Code's model requests to our proxy.
Send a short message to the agent. In our recorded example, we asked what a reverse proxy does. As Claude Code handles that message, the first terminal prints the traffic passing through the proxy. Let's look at the request carrying our question.
Here is our question inside the captured request. The harness has placed it in a much larger body of information, about ninety kilobytes for our one-line question. The excerpt shows where our message appears, but most of what the harness sent is outside this small view.
The messages field carries the conversation. The system field contains the system instructions, and the tools field describes the tools available to the model. These are parts of the actual request that the proxy lets us inspect.
We typed one short question, but the harness supplied much more than that. Let's open the system instructions to see a small part of what it added.
This is part of the system prompt from that request. It describes an agent that helps with software engineering, tells it where its text will appear, and asks it to match the style of the surrounding code.
We did not type these instructions. The harness included them alongside our message. The proxy makes that text available for us to read, so we can see the instructions directly. Later this week, we'll examine the system prompt in more detail. The prompt in this capture was sent to Haiku. Below this video there is a page from a later capture. It puts the Haiku prompt next to the prompt the same harness sends to Fable, with the differences marked word by word. Fable, the more advanced model, gets a much shorter system prompt, less than half the length.
The same script also works with Codex. Codex has a configuration setting for its model service's base URL. Point that at the local proxy, and tell the proxy which upstream service to forward to. The request format differs, but the idea is the same.
The accompanying setup instructions give the complete commands for both agents, including Codex with a ChatGPT login. You can use that route with the supplied script too.
Printing the traffic is enough to reveal what the harness sends, but a growing conversation quickly becomes awkward to read in a terminal. We would like a view we can use while the agent works, where we can open a request and find the parts that interest us.
In the lab, you will use this Python script as the basis for a more useful live traffic monitor. You will build an interface for inspecting the exchange, with views for things like the system instructions and tool calls and results. The proxy already provides the connection. Your program will make the traffic easier to explore than a stream of printed text.
We can now put a proxy between the harness and the model service and inspect the messages passing through it. We found our question, the tool definitions, and instructions supplied by the harness. That gives us a concrete way to look inside the exchange and a starting point for building a monitor we can use ourselves.