Debug ML while it's training.

A finding carries a check id, a variable, a severity, its numbers and a confidence. It is deduplicated on (check, variable), so "spiked to 4.12" and "4.13" aren't two problems. A check must hold for two consecutive evaluations before it is raised, except NaN and Inf, where waiting is itself the damage. Findings clear when the condition goes away and can fire again. Detection runs whether or not auto-fix is on.

After each model turn the brain asks when to come back, and why. A fix that just landed, a metric heading the wrong way or anything uncertain pulls the next look in to minutes; a smoothly descending run is left alone for an hour. A NaN, a critical finding or a fix brings the next look forward immediately, and the schedule survives a brain restart.

It is handed the whole run: every curve downsampled into min/mean/max buckets (a two-step spike survives), current findings, tensors, what was fixed, earlier audits, and how many samples were dropped. It is asked for what deterministic checks can't see: a loss decreasing far slower than it should, two metrics that disagree, a plausible-but-wrong value.

Deterministic code-level checks: incompatible loss/metric combinations, redundant activation/loss combinations, backward() without the expected optimizer update, train/eval mode issues, suspicious learning rates, and other ML-specific static patterns.

Expanded mllint checks · minimal-fix-first behaviour · whitespace-tolerant patch matching · retry-on-mismatch patching · stronger verification of correctness and patch scope · more agentic debugging workflows.

Some shell commands the agent wants need an OK first: ones that delete files, rewrite git state, reach outside the project, start a background process or overwrite a file. So a long run never stops to wait, a model answers that y/N. By default it is the agent's own model, asked separately.

Or set "approver": "<model>" to pick a different model. The same commands are flagged either way; only who answers changes.

Only the command, why it was flagged, the project folder, and what the agent was working on, never the agent's reasoning. It answers APPROVE or DENY with a reason that goes back to the agent. It is told to deny anything that could destroy work that can't be regenerated, touch files outside the project, handle credentials or use sudo, and to deny when unsure.

It also answers "apply this change?" for each edit the agent proposes, judging the diff against your request. Every applied change stays one /undo away. If it can't be reached, Pulse asks you (or declines in a non-interactive run). Every decision is printed and recorded in the agent log.

Nothing is installed into the loop: no sys.settrace, no callback into user code. A background thread reads the training thread's variables a few times a second. It never converts data to answer a question about its shape; only 0-d and few-element values cross the device boundary, on a schedule; and it holds no references, so tracking a tensor doesn't keep it alive.

Under backpressure the oldest frame is dropped and the loss is recorded, so the brain knows its view has a hole rather than the loop being slowed. It is an append-only file, not a socket, so the brain can attach late, crash or restart without the run ever waiting.

Add Python's scripts folder to PATH (see Installation), or use python3 -m pulse.

Pulse falls back to line-by-line screens without a real terminal (a pipe, CI), on a very small one. On Windows it needs a console that understands escape sequences: Windows Terminal, or the console of Windows 10 and later.

Don't put API keys in source code or commit them. A pasted key is never written to disk.