Available to paid subscribers
Agent Failure Lab
Kit files are in English.
Find out how your agent recovers before it fails overnight, then save a before-and-after report about your own runner.
macOS or Linux, POSIX shell, Python 3.10+. Offline drills need no API key.
- Rehearse eleven failures in a disposable local lab.
- See completed work, repeated outputs and measured recovery time.
- Change one repair and compare two saved runs from your setup.
Local Python kit | ZIP, guide and reports in English | Offline demo
View sample recovery reportAvailable now to paid subscribers. One-off purchase opens later.
I'm a subscriber: claim itComing soon: one-off purchase.
Yearly: every kit included. Monthly: one new kit per billing cycle.
View full-size sample ↗Access, downloads and refund policy
Yearly: every available kit and bundle, unlimited downloads.
Monthly: one new standalone kit per billing cycle, no bundles. Re-downloads are free and do not use a new claim.
Monthly subscriptions started before February 28, 2026 keep all-access, including bundles and unlimited downloads.
Monthly access currently allows three downloads per kit. Need another? Contact joozio@hey.com.
Download access while subscribed. Keep the files you download.
Limits
Measures mechanical recovery, not output quality.
- Your command can write anywhere your user can.
- A recovery that produces the expected number of placeholder files can still pass.
Inside the kit
- Run: eleven drills, seven repair modules and your own runner replay
- Examples: failed and recovered reports, Claude Code receipt
- Guide: seven chapters and recovery worksheets
How it works
Your unattended agent will fail one night: it will hang without exiting, write half a checkpoint, leave a lock behind that nothing clears, or report SUCCESS having produced nothing at all. This kit lets you watch all eleven of those happen in a disposable lab that deletes itself, then practise the recovery while it costs you nothing. Each drill runs twice: the broken half shows the failure, and the repaired half has to finish the work rather than just notice it, with a measured recovery time and every unit accounted for. Then the same eleven failures are injected into a disposable copy of your own job and your recovery command is graded on each one: a pass needs the failure really delivered, the kill proven against the whole process group, a checkpoint that matches the files on disk, a resume that exits 0, and every expected artifact present exactly once, with contents hashed. A replay that quietly does nothing fails. Offline, standard library Python, no account and no API key for the drills.
Real Claude Code 2.1.268 run, shipped as a receipt you can check: killed at 13.18 seconds, resumed in 25.34 seconds, rewrote nothing, 6 of 6 artifacts present.
Latest update: 2026-09-13
v1.0.3 (2026-09-13). The sample runner now stands down on a claim whose owner it cannot read, instead of unlinking a live one, with the four incomplete-owner payloads as self-test checks.
How the checks work: detail and full file inventory
Best for
- +Anyone who leaves an agent, a scheduled job or a batch worker running overnight and has never tested what happens when it hangs
- +People who have detection (a log, a dashboard, an exit code) but have never measured the distance between something noticed and the work being done
- +Anyone whose job sends, posts, charges or deploys, where a recovery run that repeats itself is more expensive than one that fails
- +Teams writing their first escalation and stop rules and wanting the questions rather than a template
Not for
- -Anyone looking for a sandbox. Containment here is a declared watch list plus a sentinel beside the workspace, re-hashed and reported path by path; your command runs as you and can write anywhere you can, and paths outside that list are not observed. For a boundary rather than an observation, run it inside a container
- -Anyone hoping to measure model judgment or content. Every failure here is mechanical: a hung process, a torn file, a dead lock. The recovery grade is a count contract (resume exited 0, finished work untouched, the declared number of artifacts exists); it does not judge what is inside them
- -People who want a one-click fix. This is drills and worksheets; you run them and you write down what you found
What you get
Package includes
- •START-HERE.html: five-minute install, what to run first, and what a pass looks like
- •guide/01 to 07: disposable lab, detection vs recovery, timeouts and checkpoints, monitoring the monitor, enforcement and blast radius, handoffs and duplicate work, transferring a fix to your own agent
- •drills/: eleven JSON drill definitions, each naming the incident shape, the observable detection point, the repair and the trap in the obvious fix
- •lab/: clock, ownership proofs, allowlist enforcement, loopback provider fixture, fault-injecting worker, evidence monitor, driver and grader
- •repairs/: seven runnable repair modules, each self-testing
- •rehearsal/: rehearse.py, drill_replay.py (eleven failure replays against your command), a sample runner and two runner guides
- •worksheets/: system map, escalation and stop rules, recovery record
- •answer-keys/: expected-results.json plus a walkthrough for all eleven drills
- •examples/: two report files generated from real runs, plus the unedited JSON receipt of a real Claude Code rehearsal with artifact hashes and machine paths replaced
- •tests/: 22 tests across isolation, recovery and repeatability, runnable with python3 or pytest
- •MANIFEST.txt, CHANGELOG.md, LICENSE.txt
FAQ
What does this lab not measure?
The grade measures mechanical recovery; the expected number of placeholder files can still pass.
Technical detail
Mechanics, not judgment and not content. Containment is a declared watch list plus a sentinel beside the workspace, re-hashed and reported path by path: it catches an escape into the kit, your project, your real CLI config files and one level up out of the disposable copy, and fails the run when any changed. It is not a sandbox; your command runs as you and can write anywhere you can, and paths outside that list are not observed. For a boundary rather than an observation, run it inside a container. The recovery grade is a count contract: it proves your resume exited 0, did not rewrite or delete finished work, and that the declared number of artifacts exists at the end. It does not judge what is inside them, so a resume that writes the right number of placeholder files passes.
Do I need an API key or an account?
Not for the drills. All eleven run against a loopback fixture with a synthetic key, and the fixture refuses to start on any key that does not begin with sk-lab-fake. The only part that touches a real provider is the optional Claude Code rehearsal preset, which says so before it runs.
Is it safe to run on my machine?
Your command runs with your permissions; only declared paths are watched.
Technical detail
Every drill runs in a fresh directory under your system temp dir, and the lab refuses to run anywhere else. Each run re-hashes a declared watch list and fails if any watched path changed. The allowlist revert can only touch paths under the lab root, resolved after symlinks: an absolute path or a .. in a violation record aborts the whole revert before anything is written, and a file swapped for a symlink is unlinked and rewritten inside rather than followed out. It signals only processes it spawned, verified by pid and process start time, and it kills the whole process group. The rehearsal copies your project rather than running in it, leaves credential files behind, does not follow symlinks out, and one shipped test runs rm -f important.txt through the rehearsal against a real directory and then asserts the file is still there. What it does not do is watch your whole filesystem: your command runs as you, so it can write anywhere you can, and the output states that next to the watch list on every run. For a boundary rather than an observation, run it in a container.
Does it work with something other than Claude Code?
Yes. The rehearsal takes any command that produces files as it works: a cron job, a Python worker, a Makefile target, a different agent CLI. Tell it how many artifacts a finished run leaves behind and it grades every recovery against that contract; without that number it reports unproven rather than a pass, because it cannot otherwise tell a finished job from one that did nothing. One of the eleven replays needs a command that calls a provider through ANTHROPIC_BASE_URL, and says so instead of inventing a pass when yours does not.
How long does it take?
Ten seconds for the demo, about forty for all twenty-two drill runs, and roughly four minutes for both test suites (the second one now replays all eleven failures against two different runners). The guide is seven chapters and about ninety minutes if you run the drills as you read. The worksheets are the slow part, and they are the part that pays.
What is actually verifiable here?
Every runnable module carries its own --self-test, the drills are graded against a committed answer key, and the two suites check the isolation claims, rerun every drill twice and replay all eleven failures against a good runner and a deliberately sloppy one. The grader refuses impossible evidence: a run record with no containment observation fails, an empty set of records is never a pass, and a repaired drill that detects the failure without finishing the work fails. Unzip it and run tests/test_recovery_and_repeat_run.py before you read a single page of the guide.