Much of the code and writing on this site and in these repositories was drafted with Claude models from Anthropic, working in Claude Code under the maintainer's direction. Tests and the maintainer decide what is kept, and some code was written by a small model running on the maintainer's own machine. Statements about cystic fibrosis are checked against the cited sources before they are published, and nothing here is medical advice. The lab is independent of Anthropic; Anthropic has not reviewed or endorsed it. Product names belong to their owners.
We use three tiers. A model's seat depends on the task, not on its name.
Work that touches security needs a reviewer from a different maker than the model that wrote it; the local worker is used for that review today. We have measured it as a reviewer once, on an 808-line script with 17 known defects. In eight runs it never found more than 5 of the 17 in one run, and 9 were found by no run. Each run called two to five real defects correct. So its findings count only when a failing input reproduces them.
How a small edit goes to the local worker: one file, the change written as numbered steps, the current file, and a test. The test is written first and shown to fail on the unchanged file. The worker's reply goes to that test. If it fails, the failing test lines and the best attempt so far go back; after three attempts the loop stops and says so. Every accepted result is still read by a person or another model. Larger jobs, such as a checker written from a specification, work the same way with the specification in place of the steps.
The record, from one machine in an early benchmark pass, covers nine bounded edits to the site generator and the skills repository's helper scripts. Five passed all their tests on the first attempt, and a sixth did once a fault in our own test setup was fixed. The other three used all three attempts without being accepted by the loop. In two of them our own test was wrong; in the third the worker added a line nobody asked for, which we removed. A larger checker, about 800 lines written from a specification, passed its 72 tests in seven of twelve runs (three on the first attempt, one on the second, three on the third). A review by another model, reading it line by line against the specification, then found 17 defects that those tests could not see. These counts are small. We think they say the route is worth continuing, not that it is reliable.
Are we distilling models? Not in the machine-learning sense: we train and fine-tune nothing, this work downloaded no model, and nothing in the loop downloads one by itself. Our "distill loop" means turning a lesson into a test that must pass. What we do try is simpler. A stronger model writes down how it solved a task: here, notes on the mistakes it expected a small model to make, and a code outline. We hand that to the local worker as instructions. We have tried it once, on one task, six runs each: with such notes the worker's checker was accepted in three runs, without them in four. That shows no sign that the notes help, and six runs each cannot show that they do not, so the question is still open.
How the loop grew: four repositories, 1,094 commits, and a diverse council
The paragraphs above record where the loop started as a single-worker prototype. From that baseline, the loop grew into an autonomous four-repository open research workshop totaling 1,094 commits (463 + 246 + 63 + 322 = 1,094). Those commits span 463 in cf-lab, 246 in cf-research, 63 in cf-skills, and 322 on this website. On the public task board, 328 of 419 tasks are complete (78.3%), with 186 carrying deterministically measured verification outcomes.
Three architectural changes made that pace possible without relaxing verification:
Three-layer execution separation and dual-maker frontier review
Layer 1 orchestrators and subagents combine Anthropic Claude Opus 5.5 and Google Gemini 4 Argon or Flash. Every pull request gets an independent blind review from an opposing model maker. Layer 2 local workers run statelessly on loopback HTTP (127.0.0.1:11434) with zero tools and zero file-write permissions. Layer 3 runs 134 deterministic check suites and 44 security linters.
Frozen verifiers (V2-02) and thinking-trace salvage
Before delegate.ps1 calls a local worker, it copies the verifier script and test fixtures into an isolated folder and checks their SHA-256 hashes. It runs the verifier against an empty stub first to prove the test fails when nothing is done. If a thinking run hits its token ceiling after finishing a valid code block, the harness salvages that block and verifies it.
Random-nonce diff boundaries and Trojan-Source defense
When review-diff.ps1 sends a code change to Qwen 3.8 and Gemma 4 31B for blind review, build-review-packet.py wraps the diff inside a random-nonce tag (<untrusted_diff_NONCE>). It folds Unicode homoglyphs (NFKD) and escapes invisible directional characters as <U+XXXX> so hidden instructions inside a diff cannot steer the reviewer.
