How to see the JSON sent to the model and its answer

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

# How to see the JSON sent to the model and its answer

This guide shows how to keep, for every call to the model, the exact request mm sent and the exact response the server returned — to check a system prompt, the tool definitions, a sampling key, what another agent received, or what a model really answered. It assumes you already run `mm` with a configuration file.

## Steps

1. Turn the trace on, for one run:

   ```bash
   AGENT_TRACE=true mm agent.yaml
   ```

   or for good, in the configuration:

   ```yaml
   trace:
     enabled: true
     dir: .mm/traces   # the default
   ```

   The banner ends with `| trace: /abs/path/.mm/traces` while it is on.

2. Ask a question as usual. Each call to the model leaves a pair of files:

   ```text
   .mm/traces/20261007-123237.903-bob-0001.request.json
   .mm/traces/20261007-123237.903-bob-0001.response-200.sse
   ```

   One question can make several calls: one per round trip with the tools, plus a compaction summary. The agent's `acp.name` is in each name, so an agent called through `ask_agent` or `/ask` — it inherits `AGENT_TRACE` — writes its own files beside yours (`…-jan-0001…`).

3. Read the request. It is the body exactly as sent, indented:

   ```bash
   jq '{model, temperature, stream_options, chat_template_kwargs}' .mm/traces/*-0001.request.json
   jq -r '.messages[] | "\(.role): \(.content | tostring | .[0:120])"' .mm/traces/*-0001.request.json
   jq -r '.tools[].function.name' .mm/traces/*-0001.request.json
   ```

4. Read the response. A streamed one (`.sse`) is the server's lines as they came, one `data: {…}` chunk each; rebuild the answer text with:

   ```bash
   grep '^data: {' .mm/traces/*-0001.response-200.sse | sed 's/^data: //' \
     | jq -rj '.choices[0].delta.content // empty'; echo
   ```

   and its reasoning with `.choices[0].delta.reasoning_content`, its tool calls with `.choices[0].delta.tool_calls`, its token counts with `.usage` (the last chunk). A response that was not streamed is a `.json` file, indented. An error status is in the name (`.response-400.json`); a call that got no response at all leaves `.response-error.txt`.

5. Turn it off when you are done: the files hold your prompts, file contents and command outputs in full. `.mm/` is git-ignored in this repository; add it to your project's `.gitignore` too.

## Variants

- **In an editor (ACP).** A relative `trace.dir` is in the session's `cwd` — the project the editor opened — not in the directory the editor launched `mm` from. Set `AGENT_TRACE` in the editor's agent settings (`env`), or `trace.enabled` in the file: the editor does not see your shell's variables.
- **Somewhere else.** `trace.dir: /tmp/mm-traces` collects every project's calls in one place.
- **Only the agents you ask.** Put `trace.enabled: true` in that agent's own file instead of using `AGENT_TRACE`.
- **Before the files: what mm adds.** The request already carries what mm adds itself — `stream_options.include_usage`, `return_progress` for a llama.cpp server, `chat_template_kwargs.enable_thinking: false` on a summary — so the trace is also how to check those.

## See also

- The `trace` keys and the file names: [configuration reference](../reference/configuration.md)
- `AGENT_TRACE`: [command-line reference](../reference/cli.md)
- Why reasoning arrives in its own field: [Thinking models](../explanation/thinking-models.md)