Chapter 13: jevprobe, one question, out loud

When the window's Jev panel says "off" or a choice falls back, there are four different things that could be wrong, and from inside the window they all look the same: the key never reached the process, TLS failed, the request was refused, or the response was not the shape the code expected. jevprobe separates them by asking one real question and printing everything.

op-env-run -- nix develop -c buck2 run //apps/jevprobe:jevprobe

It asks a single Choice, four things Link could do in a made-up position (just out of bed in his house, the staircase to the south), and prints the model, the round trip and how many attempts it took, the tokens, the cost, the confidence, every option's probability as a little bar chart, and last the raw response body.

Aside: why the raw body? The response is checked against research/jev-api-digest.md, a digest of the vendor's documentation. A field the digest does not know about is visible in the raw body and nowhere else, and finding one is a reason to correct the digest.

--headers asks the same question but prints every response header (anything credential-shaped redacted), the request id, the parsed rate limit and the token usage instead. It exists to check what the vendor's docs do not say (the digest's §10). Either way it is one real, billed request; run it sparingly.

Try it. Run it with the key, and once without: with no TYPESAFE_API_KEY it says so and exits, having sent nothing.

For the people who maintain it

In this folder

TYPESAFE_API_KEY must be in this process's environment; op-env-run is what puts it there. The request goes through jev-http, so it is admitted by the same shared spend ledger as the window's questions and counted there.

← Previous: Chapter 12, native/ · Up: apps · Next: Chapter 14, replay-probe/ →