Looking at a language model through its measurements
A learning project where I recorded part of a local model run and built a viewer for the tokens, vector magnitudes, routing weights, and output scores.
Recorded investigation · Working viewer
Inspect the recorded measurementsThe problem
I wanted to connect the idea of a language model to operations I could inspect. How does text become tokens? What do vector magnitudes and routing weights look like? How do output scores relate to an agent’s tool use? I recorded a small part of one execution to explore those questions.
What I built
I added the capture hooks, wrote checks for the recorded data, and built the viewer.
- Instrumentation around model execution and token sampling, linking request, forward-pass, and sample records.
- Residual values and expert-routing measurements at layers 0, 23, and 47, at the final input position of captured forward passes, alongside input tokens and output-token scores.
- Verification that checks artifact integrity, recorded numerical relationships, the returned tool result, and the final answer against a neutral fixture.
- A viewer for token positions, token IDs, text, and measured values. The public excerpt below shows three input tokens and one generation step from that capture.
The engineering decision
Starting with a task I could check
I asked the agent to read a neutral JSON fixture and return its four fields. I linked requests, forward passes, and token samples to the file read, returned data, and final answer, then checked the saved artifacts and recorded numerical relationships.
The small task gave me a known answer and identifiable records to inspect. The viewer keeps input tokens, vector summaries, selected experts, and candidate-token scores separate so each measurement can be read in its own terms.
Real recorded measurements · Controlled test fixture
Follow the evidence through one run.
The agent read a neutral file, received its contents, and returned the requested fields. This public excerpt connects that interaction to one recorded generation step.
A simple task I could check exactly.
Read a neutral JSON fixture and return its four fields exactly.
I used a neutral fixture so the answer could be compared with known data. The agent execution and neural measurements are real; the test content was deliberately invented.
The random marker identifies this test fixture. It is not a credential or a personal record. Private file paths and the full prompts are omitted.
The controlled fixture
{
"fixture_id": "same-run-mlx",
"nonce": "7d194f3f-3f0e-4b12-b3e6-21f0c45b61c8",
"color": "cerulean",
"item": "wooden compass"
}Recording details and scope
- Model
- Qwen3-Coder-30B-A3B-Instruct-MLX-4bit
- Runtime
- MLX-LM 0.31.3 / MLX 0.32.0
- Captured
- 2026-09-16
Public completion labels replace runtime identifiers. Token IDs, positions, and measurements are unchanged. Values in the tables are rounded for reading; the downloadable excerpt retains their recorded values.
The excerpt was rechecked against the saved artifacts without rerunning the model. It omits the original full prompts, local paths, full vectors, other samples, and a separate title request. It contains no attention probability matrices and is not a throughput benchmark.
These selected observations helped me study tokens, vector magnitudes, routing weights, and output scores. They do not explain why the model produced its answer. Probe training and activation patching remain proposed work.
What the measurements showed me
Tokenization, vector norms, and weighted selection became concrete quantities I could inspect. In this input, “cerulean” is three tokens; each displayed residual summary describes a 2,048-value vector. The L2 norm reduces that vector to a magnitude, so it leaves out its direction and individual coordinates.
The capture also made the limits of a summary clearer. A larger norm does not tell me what a layer contributes to the answer; an expert ID does not name a skill. Raw logits, router probabilities, and selected weights describe different quantities. Checking the final answer establishes that this fixture matched, not why the model produced it.
What I checked
- The post-tool input contains “cer”, “ule”, and “an” at positions 3034–3036, with token IDs 3828, 1111, and 276.
- At producing position 3148 of forward pass 55, the recorded layer-output L2 magnitudes are 1.4953, 11.1243, and 97.1942 for layers 0, 23, and 47 respectively (rounded).
- That generation step emitted “cer” (token 3828), with a raw output logit of 49.5. The viewer retains the routing selections and candidate-token scores for inspection.
- The agent called read_file and returned a final JSON answer matching all four fixture fields. The downloadable excerpt preserves the selected measurements and the fixture check.
Limits
- The task used an artificial fixture, but the measurements came from a real agent execution.
- The capture samples layers 0, 23, and 47 of 48 at the final input position of captured forward passes. The public excerpt narrows this further to one generation step; it omits full vectors and other samples.
- No attention probability matrices were captured. These observations do not establish causal explanations or general task reliability; instrumentation overhead also makes this unsuitable as a throughput benchmark.
- I did not train probes or run activation-patching experiments. This is a learning project, not a new interpretability method or model capability.
Tools and foundations
I built the capture hooks, integration, verification, and viewer. Hermes supplies the agent runtime; MLX and MLX-LM supply local inference; the Qwen3-Coder model and its weights are third-party work.