Batchwatch MCP server

Client libraries

batchwatch only works if people instrument their pipelines, and nobody writes raw HTTP calls to donate data. These are the libraries that make it two lines.

All nine expose the same surface, and a conformance check fails CI if any language falls behind — see The same surface, in all nine.

client/batchwatch.py in the repo root is the original single-file client and is left untouched. clients/python/ is the packaged version of it, plus spooling.

A note on TLS (Rust and C++). Every client except Rust and C++ gets TLS from its standard library and talks to https://batchwatch.dev directly. Rust's and C++'s standard libraries have no TLS, and both are written with zero external dependencies on purpose, so their transport is http:// only. Pointed at the default https:// URL they spool rather than deliver (the measurement is kept, not lost) until you point them at an http:// endpoint or a local TLS-terminating proxy. Their READMEs say so.

What every client does the same way

It fails open. A batchwatch outage must never stop a user's job. Every submission happens off the caller's thread with a short timeout, every error is swallowed and logged at debug level, and the only call you await — shouldbatch() — returns your* default when it cannot answer, never a guess. The default is "run it synchronously": being wrong that way costs money, being wrong the other way blows a deadline. Each package has a test that runs against a dead port and a hung socket.

Two lines to adopt. should_batch() before you submit, track() around the call.

It never sends content. No prompts, no completions, no file names. The body is built from one allowlist — provider, model, mode, endpoint, request count, token counts, timestamps, status — and everything else is dropped by a single function - _scrub in Python, Scrub in Go, clean in TypeScript, sanitize in PHP, Ruby and Java, strip in Rust and C++ - on the way out. Each package has a test that asserts this on what the server actually received, with a positive control so it cannot pass by sending nothing at all.

outputtokens defaults to null, never 0.** Output costs five to six times as much as input, so a saving computed on zero output is systematically too low — 3.4x too low in the case that led to this rule — and nothing in the response reveals it. Absence must stay absence all the way to the server. Explicitly passing 0 still sends 0: zero is a measurement.

It spools to disk. An undeliverable completed measurement is appended to a JSONL file and replayed later via POST /v1/calls/complete. Losing measurements when the network is bad means losing them exactly when they are most interesting.

Shortened. The full README is on GitHub.