- the answer, before the archaeology
- how to build a 608-row answer
- the tournament ends; the roster narrows
- the second cut: seven routes, twenty-eight assignments
- secrecy is not specification
- the roster becomes a workflow
- the power check cuts 144 to 72
- one result, two denominators
- reviewers are instruments
- the missing control arrives last
- quality refuses to be a token column
- the committee that kept paying rent
- one mind, several hands
- what the machinery bought
- the crown has a half-life
- winners, dated
The King Is Dead. Long Live the King. Until Tuesday.
What a 608-Row Tournament, a 28-Assignment Shakeout and 96 Follow-Up Executions Taught Us About Building an AI Workshop at Frontier Speed
The question was small: when the main agent delegates a piece of coding work, which model should do it?
Four days later the answer lived inside a repository containing 608 completed tournament rows, several protocol revisions, route characterisation, frozen synthetic tasks, hidden evaluators, blind review, a repair round, hash-chained ledgers, an invalidated-run genealogy, a six-model council and enough credential-isolation machinery to make a bank vault feel it had perhaps been a little casual about things.
This is what happens when a screwdriver is asked a difficult question and responds by becoming a particle accelerator.
The four-day programme produced several hundred patches, rather more provider calls than rows, two capacity incidents, one evaluator scandal, three changes to how we review code and no single winner across every job. It did produce clear winners for this workshop, on these routes, in July 2026. Enough candidates landed on the Stage 1 boundaries to exercise all thirty-six tie-break rows, so the tournament ledger reached the protocol maximum rather than borrowing its largest number for the title.
The 608 rows made the first cut. Seven remaining routes then faced a twenty-eight-assignment shakeout, which made the second. Only then did we carry the useful roles forward. A 72-execution study put Terra solo, Fable solo and the Sol-plan, Terra-build, Sol-integrate, Fable-review workflow across twelve unseen task families twice. Finally we added the control the whole enterprise had somehow managed not to contain: twenty-four direct Sol implementations on those same frozen tasks.
Together, those experiments revealed that we had been running several races under one banner. The largest current result was operational: for small cohesive work, direct Sol became the clear authorship choice.
The result was a workshop, its current winners and the awkward discovery that every result needed an expiry date.
// the answer, before the archaeology
As of 13 July 2026, the production workflow has one centre of judgement and a named route for each job.
Sol owns the contract, implementation decisions, integration, evidence and final claim. On cohesive work, Sol implements and Terra independently attacks the contract and diff. Where the repository contains a real seam, one or more Terra hands implement bounded packages in isolated workspaces. Sol integrates everything and runs deterministic, regression and boundary checks. Fable reviews the actual combined patch from a fresh read-only context. Non-trivial or high-risk work gets a second blind Luna review. Every actionable defect claim receives a recorded disposition: reproduced, refuted, inconclusive or deferred. Only reproduced findings can change code. A fresh Terra normally repairs confirmed ordinary findings; Sol owns the repair decision on dangerous boundaries. Sol retests, reads the final diff and obtains another fresh semantic review.
Council remains in the building, with a deliberately low threshold when the premise is uncertain or the boundary is dangerous. It handles strategy, architecture and research; complex feature pre-flight; and code where money, privilege, persistence, concurrency or recovery makes one extra real finding worth a roomful of false leads. It has also helped features land in one shot by finding the missing condition before Sol implements the wrong complete answer. It still does not convene because a seven-line patch would look lonely without a committee.
Opus 4.8 is the semantic fallback when an independent Claude route is available. It is not a capacity fallback when it shares Fable's exhausted route; Luna or another independently provisioned reviewer takes that case. If Luna authored or repaired the candidate, Luna cannot review itself; another independent route takes that seat.
Those adjectives are not interchangeable. “Fresh” means a new context without the author's conversation. “Blind” means the identity and topology are withheld where the review allows it. “Capacity-independent” means a different authentication and quota boundary. High-risk review seeks all three; opening another session on the same exhausted account supplies only optimism.
In operational terms, the routing rule is:
| Review condition | Required route | Delivery rule |
|---|---|---|
| Normal | Fresh Fable; blind Luna also reviews non-trivial or high-risk work | Sol adjudicates every actionable claim |
| Fable unavailable | Luna takes first review; an independently provisioned Opus 4.8 or another heterogeneous route takes the required second seat for non-trivial or high-risk work | A shared exhausted Claude route is not a fallback |
| Reviewer authored or repaired | That route is excluded; another independent route takes its seat | No self-review by model, context or repair instance |
| Required independent seat unavailable | Wait or provision a genuinely independent route | Non-trivial or high-risk work does not merge until the required review exists |
That is the result. The rest of this article is how the machinery argued its way there.
// how to build a 608-row answer
The protocol family was magnificent. It had separate new-code and bug-fix roles, eleven worker families represented by twelve route-and-effort configurations, two controls, provider gates, harness-conformance tests, task banks, reviewer calibration, sealed finals, historical-defect registries, independent adjudication and a schedule large enough to require its own weather system.
It was not stupid. Almost every individual requirement had a good reason. Provider route and adapter behaviour are part of an agent configuration. Hidden-test isolation matters. A raw completion is not comparable to a coding agent with tools. Failed calls must not quietly disappear. Reviewers need calibration. If a task touches private code, the privacy boundary should be dull, explicit and difficult to wave through while tired.
The trouble was multiplication. A sensible number of candidates met a sensible number of roles, tasks, repetitions, judges and repair states. They introduced themselves. The base design reached 572 execution rows; the screening boundary consumed all thirty-six available tie-breaks. The spreadsheet became 608.
This is a familiar engineering failure because it feels excellent while it is happening. Every safeguard makes the document more defensible. Only the cumulative object takes four days, several hundred patches and a scheduler which begins to exhibit opinions. One can spend a fortnight constructing a benchmark with excellent internal validity and no results. We chose the neighbouring failure mode and ran all of it.
The 608 rows arrived in five acts and an encore:
| Stage | Purpose | Rows |
|---|---|---|
| 0 | Harness and route characterisation | 22 |
| 0.5 | Design-power pilot | 64 |
| 1 | Common-tournament worker screen | 102 |
| 2 | Sealed worker final | 192 |
| 3 | Common-tournament system-policy arms | 192 |
| tie-break | Stage 1 boundary resolution | 36 |
| Total | 608 |
Stage 1's screen and Stage 3's policy comparison both belonged to the completed 608-row tournament. Neither was the later 28-assignment shakeout or the 72-execution workflow study.
The common field contained Terra, Luna, Gemini 3.5 Flash, Gemini 3.1 Pro, Sonnet 5, Opus 4.8 at two effort settings, DeepSeek V4 Pro, Kimi K2.7 Code, Grok 4.20, GLM 5.2 and Mistral Large 3. Sol and Fable were controls. That is eleven worker model families and twelve worker configurations because Opus entered twice. All of them entered and contributed to the 608-row tournament. The number is the completed tournament total, not 608 private rows issued to each contestant like towels at a particularly vindictive spa.
Every configuration meant the deployable route: model, provider, reasoning setting, adapter, tools, context behaviour and failure modes. The design was staged and adaptive, not a fourteen-arm round robin. All twelve worker configurations and both controls entered, but frozen internal gates changed which configurations were eligible for later banks, so exposure was not equal across the whole 608. Within each matched eligible block, candidates received identical task bytes and capability classes in fresh synthetic repositories. Hidden evaluation ran outside the workspace. Candidate identities became opaque seats before review. A timeout, refusal, empty patch, parser failure or route error stayed in the relevant denominator.
The 608 is therefore a programme-workload count, not a common sample size for each route. Route comparisons use only matched eligible blocks and their own intention-to-treat denominators; later-stage estimates are conditional on surviving the earlier internal gate. A single percentage over all 608 would reward or punish configurations for rows they were never assigned, which is how a leaderboard becomes decorative fiction.
Task families were disjoint across the power pilot, screen, sealed final and Stage 3 system-policy bank. Every package bound the source snapshot, worker brief, visible context, editable paths, commands, rubric, hidden probes, oracle patch and targeted incorrect mutants. The base had to fail. Two independently acceptable implementations had to pass. Reverting the behaviour had to fail again. Five repeated evaluator runs had to agree, and every declared mutant had to die.
Behaviour supplied sixty points; blind semantic and scope review supplied forty. Acceptance required at least 75 total, at least 48 automated points, every mandatory group and no confirmed high, critical or integrity defect. A high defect capped the score at 69 because an average is not allowed to purchase forgiveness for a security boundary.
The review layer had its own calibration: forty labelled patches followed by a sealed 140-patch validation holdout. A route could score candidates only after clearing at least 0.85 agreement on acceptable versus unacceptable, severity-weighted kappa of 0.65, score correlation of 0.75 and a one-sided 95 per cent upper confidence bound on the critical false-negative rate below five per cent. Calibration and holdout patches were licensing evidence, not tournament rows. Disagreement above eight points, every high or critical claim and every proposed winner went to a separate adjudication path. Reviewers were measurement instruments, not electronic magistrates.
// the tournament ends; the roster narrows
The broad tournament discovered several races and supplied the evidence for the first cut. It had not yet selected the production workflow.
Stage 1 kept the field broad. Its frozen internal gate determined which configurations were eligible for Stage 2, which began again on thirty-two sealed task families with two fresh repetitions, split between new code and bug fixing. Screening scores did not carry forward. The tasks which nominated a finalist were not allowed to measure its final advantage, because winner's curse is still winner's curse when the winner has an API name. These were allocations inside one completed tournament; the production-roster decision came only after the full 608-row ledger had frozen.
Terra and Luna finished the new-code bank inside the predeclared three-point operational co-winner band. That band was a decision rule, not a confidence interval proving population equivalence. Terra had the cleaner first-attempt operational profile; Luna's different misses made it useful as an independent implementer and reviewer. In bug fixing, Terra and Opus 4.8 formed the leading group without establishing a broad population difference. Opus was strongest when the defect required sustained semantic reading. Terra was easier to dispatch repeatedly and did not make every modest repair feel as though the Royal Commission had opened evidence.
Stage 3 tested three system policies on fresh families. One arm had Sol dispatch the canonical brief and verify the result. The second allowed Sol to plan and rewrite the worker package first. The third added Fable before dispatch and after integration. The planning arm looked better on tasks with genuine seams and mostly ceremonial on small indivisible changes, but that subgroup was descriptive rather than a frozen estimand. The bundled Fable arm did not isolate pre-dispatch advice from postfix review; inspection of its outputs merely showed that most actionable findings arrived after the patch existed. Those are process observations, not causal estimates of the individual components. This was the broad policy comparison inside the 608 rows, not the later matched workflow study.
Once all 608 rows were frozen, the first cross-experiment roster cut removed Grok 4.20, GLM 5.2, Mistral Large 3 and DeepSeek V4 Pro. They had run in the common field and they did not pass the composite first-attempt, route-reliability and review gate. Removing them from advancement did not erase their outputs, and it did not prevent some of those model families appearing later in Council, where the job is to widen a search rather than own a patch.
Opus had entered the common tournament at two effort settings; its higher-performing setting carried the family forward and the duplicate ended there. Twelve configurations minus four cut routes and one duplicate left seven: Terra, Luna, Sonnet 5, Opus 4.8, Kimi K2.7 Code, Gemini 3.5 Flash and the tested Gemini 3.1 Pro Vertex configuration.
That cut was an operational roster decision under the frozen route-specific gates, not a pooled twelve-way effect estimate. The companion methods record must carry configuration-by-stage eligibility, assignments, failures and gate values; the aggregate 608 alone cannot do that work.
// the second cut: seven routes, twenty-eight assignments
The next gate was a twenty-eight-assignment shakeout: four public-synthetic Python tasks by seven routes. One fresh workspace and session per assignment, one bounded tool surface, no second attempt and no repair during scoring. Every run kept its failure, duration, native token usage, patch and checks. Fable reviewed the mechanically surviving patches anonymously. Findings counted only after reproduction.
Three tasks remained valid for comparative scoring; the fourth was invalidated for hidden specification, as the next section explains. The raw block remains twenty-eight assignments, while the comparative denominator is twenty-one: seven routes across three valid tasks. Terra, Luna, Opus 4.8 and Gemini 3.5 Flash passed three out of three deterministic evaluations. Sonnet 5 and Kimi K2.7 Code passed two. The Gemini 3.1 Pro Vertex configuration passed none because all three route attempts ended at capacity before a comparable patch existed.
Then Fable read the patches which had survived deterministic evaluation and changed the shape of the apparent tie.
Every accepted Terra, Luna, Opus, Sonnet and Kimi patch passed blind semantic review. Flash had passed all three deterministic tasks. Fable returned FIX on all three Flash patches. Two production modules ran self-tests at import time. The third globally monkeypatched the unittest loader. The requested functions worked; the patches had left small pieces of laboratory equipment wired permanently into the building.
We reproduced all three findings.
| Shakeout route | Mechanical on three valid tasks | Blind review of accepted patches | Decision |
|---|---|---|---|
| Terra | 3 / 3 | 3 PASS | Advance |
| Luna | 3 / 3 | 3 PASS | Advance |
| Opus 4.8 | 3 / 3 | 3 PASS | Advance |
| Kimi K2.7 Code | 2 / 3 | 2 PASS | Retain as specialist |
| Sonnet 5 | 2 / 3 | 2 PASS | Remove |
| Gemini 3.5 Flash | 3 / 3 | 3 FIX, reproduced | Remove |
| Gemini 3.1 Pro | 0 / 3 | No comparable patch | Remove |
The second cut removed Sonnet and both Gemini routes. Pro failed operationally. Flash demonstrated why behavioural success cannot waive semantic and scope review. Sonnet and Kimi both scored two out of three, so the mechanical result did not separate them. Retaining Kimi was an explicit portfolio decision made after the scored gate: Opus and Fable already supplied stronger Anthropic routes, while Kimi preserved a materially different provider and failure profile. That is not evidence that Kimi beat Sonnet. Neither became the default; one remained as a specialist and one left the active roster.
The durable methodological result was that deterministic checks answer whether specified behaviour occurred, while semantic review can notice that the patch achieved it by putting a bad idea somewhere the checks were not looking. They are different instruments. A hidden-test-only shakeout would have tied Flash for first and produced a numerically clean, operationally silly answer.
// secrecy is not specification
The fourth shakeout task was a paginated synchronisation function. It had to validate cursor chains, consume retries without advancing the cursor, reject cycles, merge records by version, preserve first-seen order and terminate cleanly. The visible brief required malformed input and premature exhaustion to be rejected. An addendum called out Python's bool-versus-int trap.
Six shakeout routes produced patches: Terra, Luna, Sonnet, Opus, Kimi and Flash. Every patch passed the visible suite. Gemini Pro produced no comparable patch. We brought the already-eliminated GLM back for one explicitly unranked diagnostic extension; it passed the visible suite too. All seven patches then failed the same two hidden assertions.
For input that ended before terminal success, the hidden oracle expected RuntimeError; the patches used ValueError. For max_retries=False, the oracle expected TypeError; most patches again used ValueError.
The mismatch was caught mechanically. The evaluator called the function, observed the exception class and compared it with a frozen expected value. Actual did not equal expected. Red light.
The light was correct about the mismatch and wrong as a basis for ranking workers. The visible contract required rejection but never named those exception classes. The evaluator knew which interpretation it wanted because we had written the preference into the evaluator and nowhere the worker could see.
Scoring stopped when we invalidated the task. Cut one was already frozen; the task was excluded from comparative scoring and from the second-cut decision. Everything that followed was diagnostic.
Fable received the six shakeout patches plus GLM's unranked extension, the complete visible task and the repository, but no hidden cases, evaluator output or model identities. It did not infer either secret exception preference. A six-seat Council did not infer both either. It found other real defects and several claims which dissolved when we ran them.
Once the six patch-producing shakeout routes and GLM's unranked diagnostic route received the two concrete mismatches, Terra, Luna, Sonnet, Opus, Kimi, Flash and GLM repaired both in one fresh attempt.
Seven models failed information they had not been given. Strong reviewers could not reconstruct it. Seven models fixed it as soon as it became information.
Hidden tests are essential. Hidden specification is an ambush wearing a clipboard.
From that incident onward, an evaluator mismatch needed lineage back to a visible clause before it could count as a worker defect. The task block was invalidated. The original patches stayed frozen, and the labelled repair round remained outside scoring. The invalidation was not a blemish to remove from the report. It was the report beginning to work.
- The visible briefReject malformed input and premature exhaustion. No exception class is named.
- Seven patches passSix shakeout routes and an unranked GLM diagnostic all pass the visible suite.
- Same two hidden failuresInput ending before terminal success: RuntimeError expected, ValueError raised. max_retries=False: TypeError expected, mostly ValueError raised.
- Reviewers cannot see itFable inferred neither preference; a six-seat Council did not infer both.
- Told, all seven fix itBoth mismatches repaired in one fresh attempt, in a labelled round outside scoring.
- Task invalidatedA mismatch now needs lineage to a visible clause before it counts as a worker defect.
Six-step sequence. One: the visible brief says malformed input and premature exhaustion must be rejected, but names no exception class. Two: six shakeout routes (Terra, Luna, Sonnet, Opus, Kimi and Flash) and an unranked GLM diagnostic all pass the visible suite. Three, highlighted: all seven fail the same two hidden assertions; for input ending before terminal success the oracle expects RuntimeError and the patches raised ValueError, and for max_retries=False it expects TypeError where most patches raised ValueError. Four: Fable, given the full visible task but no hidden cases, inferred neither preference, and a six-seat Council did not infer both. Five: once told the two mismatches, all seven repair both in one fresh attempt, in a labelled round kept outside scoring. Six: the task is invalidated, and from then on an evaluator mismatch needs lineage back to a visible clause before it counts as a worker defect.
// the roster becomes a workflow
Two cuts had now reduced a model list to a provisional set of jobs. Terra, Luna and Opus had advanced cleanly. Kimi remained a useful specialist where patience and a different route mattered, but did not displace a primary. Sol and Fable had been controls in the tournament; the next question was where those controls belonged in a working system.
The provisional matrix entering the workflow study looked like this:
| Working role | Selected route | Evidence entering the follow-up |
|---|---|---|
| Accountable orchestrator | Sol | Control route in the tournament's Stage 3 policy comparison |
| Independent implementation | Terra | Strong sealed-final result, clean operational profile and three mechanically and semantically accepted shakeout patches |
| Adversarial contract and diff coverage | Terra | Adopted independence policy; not a calibrated head-to-head reviewer result |
| Blind second semantic verifier | Luna | New-code operational co-winner with a distinct failure profile |
| Fresh semantic verifier | Fable | Found material scope defects missed by deterministic checks |
| Semantic fallback on an independent route | Opus 4.8 | Adopted fallback supported indirectly by bug-fix reading quality; not a reviewer-tournament win |
| Strategy, complex pre-flight and dangerous-code discovery | Council | Separate production evidence; heterogeneous seats widen the search, and no claim changes code without reproduction |
Those were the roles carried into a cleaner follow-up: Sol, Terra and Fable in the treatment; Terra and Fable as direct controls; Luna outside the treatment as a blind outcome reviewer; Opus 4.8 as the declared semantic fallback.
// the power check cuts 144 to 72
The 608-row tournament supplied the first cut; the 28-assignment shakeout supplied the second. The next 72 executions isolated the selected production workflow.
A cheap or fast implementation hand can sit inside an extravagant process. Planning may reread more context than implementation. Integration can repeat the same exploration. Review may consume more tokens than a small patch. A second agent can save effort on genuinely separate packages and add pure handoff overhead to an indivisible one.
So the workflow study used twelve unseen public-synthetic task families, balanced across Python and Node, new code and bug fixes. Each family had two fresh repetitions and three matched arms:
- Terra completed the task end to end.
- Fable Max completed the task end to end.
- Sol planned; one or two Terra workers implemented bounded packages; Sol integrated; deterministic checks ran; Fable reviewed the combined patch; confirmed findings could receive one Terra repair. Opus 4.8 was the declared verifier fallback.
Luna then reviewed the six anonymous candidates for each task family from a fresh context. It could not alter the frozen primary outcome. Every assignment started in a fresh workspace and session. Empty patches, provider failures, tool violations and verifier failures stayed in the denominator. Completed rows were hash-bound and skipped, rather than rerun, on resume.
The unit that mattered was the task family. Two repetitions measured within-family variation; they did not turn one engineering problem into two independent incidents. Six reviewers would still be six measurements of the same patch, not six new patches. Administrative rows are remarkably keen to masquerade as sample size if left unattended.
The first workflow design proposed four repetitions: twelve families by three arms by four, or 144 executions. Before inference, we simulated the frozen decision rule. In the representative scenario—0.80 pass probability in every arm, a true treatment-to-control token ratio of 0.80 against both controls and the declared latent family correlation and block structure—the fixed-sequence rule cleared both quality gates and then the corresponding token-superiority gates in roughly six per cent of 2,000 simulated studies. The quality bootstrap also had poor operating characteristics near pass-rate floors and ceilings. Doubling the repetitions had purchased a large run and almost no authority.
We disabled formal superiority and non-inferiority fields before the first evaluated call, kept the twelve independent families, and reduced to two repetitions. Seventy-two executions. Enough to observe the proposed coordination mechanism and expose operational failure; not enough to announce a natural law while wearing a lab coat.
Statistics was the reviewer with a key to the brakes.
// one result, two denominators
The seventy-two executions required 153 provider calls and reported 20,973,989 provider-native tokens. An execution was a frozen arm result, not a provider call: the orchestrated arm could require planning, worker, integration and verification calls.
Twelve blind Luna reviews added 880,168 reported tokens, taking the observed study total to 21,854,157. Unreconciled verifier usage remains missing rather than becoming a convenient zero, so this is an observed lower workload bound, not a claim of complete consumption. These units are useful for workload accounting, not as equal measures of thought across different tokenizers.
The frozen end-to-end result was Terra 21/24, Fable 16/24 and the Sol-orchestrated arm 17/24.
Those delivery counts used each arm's frozen policy, not one symmetric semantic-review gate. Terra solo and Fable solo were single-route controls; only the orchestrated arm required a separate Fable verdict. The 17/24 can be compared as arm-level delivery, but not read as a like-for-like comparison of patch quality after identical review.
The implementation result was different. Terra produced 21 patches that passed both deterministic layers. Every one of the twenty-four Sol-integrated patches passed them. Seven of those twenty-four then failed the mandatory delivery gate because Fable exhausted its five-hour allocation and returned no verdict; the nominal Opus fallback used the same Claude route and met the same capacity boundary. Five of the seven later received Luna PASS; Luna raised two claims on the others, and both claims were mechanically refuted.
The 17/24 therefore measured the whole frozen delivery policy. It did not mean Sol had produced seven bad patches. The pipeline had wired its backup light switch to the same power supply.
| Arm | Mechanical patch boundary | Frozen arm-policy boundary |
|---|---|---|
| Terra solo | 21 / 24 | 21 / 24 |
| Fable Max solo | 16 / 24 | 16 / 24 |
| Sol plan + Terra build + Sol integrate + Fable review | 24 / 24 | 17 / 24 |
The distinction is not statistical throat-clearing. It is the difference between repairing code and repairing the route policy. Without lineage, a dashboard would have blamed the carpenter because the inspector's telephone stopped working.
// reviewers are instruments
Across the frozen candidates from the 72-execution study, Luna's blind outcome review returned twenty-two findings across nineteen FIX candidates. We replayed each claim against the exact frozen candidate, contract and evaluator.
Eighteen were real. Four were not.
Seven of the confirmed findings were contract defects missed by both deterministic layers, spanning six defect categories. They included an unusual valid Mapping; explicit null values swallowed by defaults; sparse arrays skipping validation; array-valued options; inherited required fields; and a route grammar that had quietly decided dollar signs were letters.
One refuted finding claimed a Terra patch accepted array options when the code explicitly rejected them. Two demanded prototype restrictions absent from both contract and evaluator. Another invented an exception class for an input whose required exception type had never been specified.
A separate contradiction scan of Luna's PASS dispositions found the reverse failure too: two empty patches had been marked PASS even though their supplied visible tests failed.
The outcome review could not alter the frozen primary result. It did establish the rule the workflow kept: a review finding is a hypothesis until the code reproduces it.
// the missing control arrives last
The workflow study still lacked the obvious control: Sol doing the same task directly.
We ran it next. Same twelve frozen families, same two repetitions, same task prompt, sealed base, visible suite, hidden evaluator, integrity gate, tool ceiling and timeout. Each assignment used one fresh ephemeral gpt-5.6-sol call at maximum reasoning. No planner. No worker package. No integration call. No retry, repair or semantic reviewer inside the measured implementation boundary.
The historical comparison contained twenty-four Sol planning calls, twenty-six Terra worker calls and twenty-four Sol integration calls. Seventy-four calls for the same twenty-four task-repetition pairs. Both topologies produced twenty-four of twenty-four mechanically acceptable patches.
Then the tokens arrived and the implementation-overhead result stopped being ambiguous.
Horizontal bar chart of reported implementation tokens, with semantic review excluded from both topologies. Direct Sol: 5,918,653 tokens in 24 calls, 24 of 24 mechanically accepted. The historical Sol plus Terra topology, shown as its parts and then its total: Sol planning, 2,255,460 tokens in 24 calls; Sol integration, 6,647,336 tokens in 24 calls, which with planning makes 8,902,796, already 2,984,143 more than the complete direct arm; Terra workers, 5,236,513 tokens in 26 calls; and the total, 14,139,309 tokens in 74 calls, also 24 of 24 accepted and 2.389 times the direct total. Direct Sol is cyan and Sol's two historical passes are highlighted in amber.
| Topology | Calls | Accepted | Reported gross tokens |
|---|---|---|---|
| Direct Sol | 24 | 24 / 24 | 5,918,653 |
| Sol planning + Terra work + Sol integration | 74 | 24 / 24 | 14,139,309 |
Direct Sol used 8,220,656 fewer tokens, a reduction of 58.14 per cent. The historical topology consumed 2.389 times the direct total. Direct Sol was lower in every one of the twenty-four matched pairs. The paired geometric-mean ratio was 0.414; the median pair used 314,492.5 fewer tokens. Individual reductions ranged from 11.98 to 78.26 per cent.
The location of the overhead matters. Terra used 5,236,513 tokens. Sol's separate planning and integration passes alone used 8,902,796, already 2,984,143 more than the complete direct arm, without counting any Terra tokens. The result does not say Terra is a poor worker. It says that asking Sol to understand a small cohesive task, write a package for somebody else, then understand the integrated result again is an expensive way to avoid letting Sol type.
Twenty-two of the twenty-four historical assignments used one Terra package. The experiment had mostly measured handoff, not parallelism.
That established the implementation-efficiency winner. The two topologies tied at twenty-four mechanically accepted patches, while direct Sol used fewer reported implementation tokens in every matched pair. Quality still required a separate check.
// quality refuses to be a token column
The direct comparison answered the operational efficiency question for these cohesive tasks. It did not license us to remove the review layers.
The direct patches had not received the same blind patch-level semantic audit as the earlier 72-execution workflow study. Equal deterministic outcomes are not proof of equal latent quality. We therefore probed every previously confirmed contract gap against each applicable direct candidate: fourteen assignment-by-gap checks covering unusual Python Mapping behaviour, explicit JavaScript null, array-valued options, sparse arrays, inherited required fields and route-parameter grammar.
Direct Sol passed fourteen out of fourteen. The matched Sol-plus-Terra candidates from that workflow study had missed one of the same probes. That strengthened the decision to make Sol primary on cohesive work. It did not prove that unknown defects had applied for leave.
The production choice was deliberately quality-first. We kept independent Terra coverage, deterministic checks, Fable review, blind Luna review for every non-trivial or high-risk change, mechanical adjudication, fresh repair and fresh re-review. Those reviewer and repair assignments are an operating policy, not the result of a calibrated head-to-head reviewer tournament. The token result chooses who holds the pen. It does not dismiss the proofreaders.
Fable provided another example while reviewing the direct-Sol report. It flagged an evidence pack which claimed zero visible-check calls while the report claimed fifty. The finding was correct about the contradiction. Reproduction against the raw events found the extractor was reading arguments.check_id; the events stored arguments.name. There were exactly fifty visible-test calls. We fixed the extractor, sent a corrected pack to a fresh Fable session and received PASS.
The reviewer had not failed. It had identified a real inconsistency and proposed the wrong side as ground truth. That is precisely why Sol reproduces instead of obeying.
Tests catch exact behaviours reviewers do not infer. Reviewers catch semantic and scope defects tests do not encode. Both miss things. The production safety property is not that one instrument is magical. It is that independent instruments fail differently and every asserted defect must become an observable one before it can change the code.
| Tests caught it | Review caught it | |
|---|---|---|
| Flash's patches | passed 3 / 3 | Fable: FIX on all three |
| Secret exceptions | flagged the mismatch | not inferred |
| Contract gaps | missed by both layers | Luna found seven |
| Empty patches | visible tests failed | Luna marked PASS |
| Evidence pack | n/a | right about the conflict, wrong side |
Grid of five incidents from the programme, with a mark for whether deterministic tests caught each one and whether semantic review did. Flash's patches, which ran self-tests at import time or globally patched the unittest loader: tests missed them, passing 3 of 3; review caught them, with Fable returning FIX on all three. The secret exception classes on the invalidated task: tests flagged the mismatch; review missed it, as Fable inferred neither preference and a six-seat Council did not infer both. Seven contract gaps: missed by both deterministic layers; caught by Luna. Two empty patches: caught by their failing visible tests; missed by Luna, which marked them PASS. An evidence pack claiming zero visible-check calls against a report claiming fifty: tests not applicable; review partly caught it, as Fable was right about the contradiction but proposed the wrong side as ground truth.
// the committee that kept paying rent
We nearly promoted Council away from code review. That was too neat, and neatness is where facts go when they would like to be left alone.
The strongest argument for keeping it close was not a research memo. It was a production privilege boundary.
One Council seat noticed that a SECURITY DEFINER credit RPC revoked execution from named application roles but not PostgreSQL's default PUBLIC grant. An authenticated caller therefore retained direct execute permission and could bypass the route's ownership and rate-limit checks. The path guarded paid credits and real production authority. A database test reproduced the bypass. We removed the grant.
Had every other claim in the session turned out to be a cupboard insisting it was a portal, that one bypass would still have justified opening the room. A false lead we test costs a reproduction. A missed money or privilege boundary can cost the product, the customer and rather more of the afternoon.
A retrospective audit makes the bargain visible. We triaged ninety private Council findings against the exact pre-fix bundles the panels had seen. Twenty-one were refuted, seven inconclusive, four outside scope and three disputed because the first verifier had accidentally time-travelled into already-fixed code. Fifty-five remained plausible pending reproduction. We selected nineteen priority cases for mechanical testing. Nineteen reproduced with failing tests.
Horizontal bar chart of 90 private Council findings, triaged against the exact pre-fix bundles the panels had seen: 21 refuted, highlighted in amber; 7 inconclusive; 4 outside scope; 3 disputed because the first verifier had accidentally time-travelled into already-fixed code; and 55 plausible pending reproduction. A final cyan bar shows the 19 priority cases selected for mechanical testing, all 19 of which reproduced with failing tests.
That selection was deliberately aimed at the claims most worth falsifying, so nineteen out of nineteen is not a precision estimate for the whole pile. It is still nineteen real defects we now know how to reproduce. Noise does not cancel discoveries. It creates a sorting job, which is why the workflow never lets a vote edit code.
This does not make every Council seat a good default verifier. On the labelled historical code-review record, Grok 4.20 asserted 33 findings: 20 confirmed and 13 refuted, or 60.6 per cent precision. GLM 5.2 asserted 17: 13 confirmed and four refuted, or 76.5 per cent. Those are operational histories, not model benchmarks, but they explain the roles. Grok is a useful dissent generator and a noisy final judge. GLM failed the worker advancement gate; its later unranked repair did not reverse that result. It can still be useful in Council because Council seats propose hypotheses rather than owning code or verdicts.
Council often pays rent before a patch exists. It has turned incomplete plans into one-shot tasks and features by exposing the boundary condition, recovery case or false premise while those things are still sentences. That matters more now that Sol is so good at implementing exactly what it has been asked to implement. A frontier author can produce the wrong complete feature with extraordinary efficiency if the brief is wrong. Council improves the question before Sol makes the answer expensive.
After the direct-Sol control, a six-seat blind strategy panel reviewed the resulting architecture. It asked whether mandatory Terra implementation should remain a safety rule. Three seats said proceed with a pre-test, two proceed with changes, one pause and test. All six attacked the same assumption: delegation had been treated as safety without evidence that handoff and reintegration risk were lower than direct authorship risk. The panel ranked independent review and mechanical adjudication above ceremony in the implementation topology.
That changed the workflow. Sol may write cohesive code. Terra supplies independence where independence is useful. Review depth stays.
This is consistent with the Council's older jobs. In Six LLMs Walk Into My Codebase, heterogeneous seats found an Origin-header redirect and a mass-assignment path that other reviewers missed. In Sharpening the Workshop, Council improved strategy and disaster-recovery decisions, while a later audit found that two of eight sessions had been driven by a synthesised premise presented as fact. The remedy was not to abolish Council. It was to label and ground load-bearing premises, and to prevent any Council claim from changing code or a decision until it survived the appropriate falsifying test.
Council is unnecessary ceremony for routine postfix review. That is not a reason to reserve it for constitutional crises. We convene it when the premise is uncertain, when a feature crosses several important boundaries, or when one missed defect can cost more than a roomful of false leads. Fable examines this patch. Council asks whether everyone has been examining the wrong thing.
That is a more permissive rule than "strategy only" or "security emergencies". The noise is real. So are the one-shot features, the corrected architectures, the Origin-header redirect, the mass-assignment path and the production credit bypass. The Council is a map of possible swamps. Grounding and the cheapest appropriate falsifying test tell us which ones contain water.
// one mind, several hands
There is an apparent contradiction. In March we killed Anthill, a ten-agent autonomous colony, and replaced it with one context, one conversation and one decision-maker. Four months later we are keeping Terra hands, two semantic reviewers and a committee. Has the colony returned wearing model aliases and hoping nobody recognises it?
No, although it is exactly the sort of thing a colony would try.
Anthill distributed ownership. A manager agent decomposed work, specialists held partial context, messages crossed boundaries, and the orchestration layer accumulated retry logic until coordinating the workers became the work. The system had several centres of judgement and none held the complete task.
This workflow keeps one centre. Sol owns the contract, understands the repository, decides whether a seam is real, reads every returned patch, runs the evidence and makes the final claim. Terra returns bounded work or an adversarial view, not organisational policy. Fable and Luna return findings, not verdicts that apply themselves. Council returns a pressure-tested decision surface. Facts flow back through Sol before the repository changes.
Parallelism follows the dependency graph. Separate packages can proceed together. A semantic review cannot inspect a patch which does not exist. A repair cannot begin until a finding survives reproduction. Fresh review cannot approve a repair that has not passed its tests. The boxes do not run in parallel merely because the diagram looks more prosperous that way.
One mind, several hands. The hands still do not need Slack.
// what the machinery bought
The 608-row protocol ran. This was absurd. It was also useful.
It forced us to define the unit under test as model plus route plus adapter plus tools. It required identical worker-facing bytes and sealed evaluators. It kept failures in the denominator. It made invalidated runs part of the lineage rather than inconvenient ancestors. It separated a repair result from first-attempt quality. It taught us to distinguish delivery acceptance from patch correctness and reviewer claims from confirmed defects.
The completed repository now preserves frozen plans and task packages, patches and summaries, reviewer and repair outputs, invalidated-run lineage, environment and version metadata, hash-bound ledgers, a README and licence. One command validates the public manifest and reproduces the 28-assignment shakeout route, assignment and task tables without calling a model:
./scripts/reproduce_publication_analysis.sh
That command is deliberately scoped to the shakeout. The 72-execution workflow study has its own ./scripts/reproduce_confirmatory_analysis.sh; neither command pretends to reconstruct the 608-row tournament from a later experiment's tables. The reusable method is now published separately as Beyond Model Leaderboards, with its own operational supplement.
The seventy-two-execution study has the same separation between human report and machine evidence. Its analysis uses fixed seeds and resamples task families, not rows pretending to be families. Native token components remain native. Missing usage is missing, never zero. The direct follow-up binds every raw call, result, summary, patch, check and final report through a ledger which an independent audit reproduced.
The overengineering had two species. One ran hundreds of rows before a later four-task shakeout demonstrated how much earlier a sharp gate could have pruned the field. The useful kind preserved enough evidence that, when the later experiments complicated the lesson, nobody had to trust our memory.
We can live with the second kind.
// the crown has a half-life
On implementation efficiency for small cohesive tasks in this workshop, Sol wins by a mile now. Combined with the deterministic tie and known-gap probes, that makes Sol the current authorship choice. A few weeks earlier, Sol was not available to us and Fable was landing work in one shot.
On 28 June, we wrote that Fable was landing work in one shot which Opus 4.8 needed two or three passes to finish. That was the operational truth of the workshop then. Sol was not available to this workshop, so there was no earlier Sol defeat waiting in the ledger and no honest head-to-head result to revise. There was a different winner on the routes we could actually use.
By 10 July, a retrospective coverage audit of thirteen fixed production issues had turned the workshop table over. Sol found all thirteen completely. The earlier review performed through the Fable/Claude setup found five completely, signalled three without the exact placement or method, and missed five. The five complete misses were unique Sol findings.4
| 10 July fixed production set | Complete | Partial | Missed |
|---|---|---|---|
Sol (gpt-5.6-sol) | 13 / 13 | 0 | 0 |
| Earlier Fable-side review | 5 / 13 | 3 / 13 | 5 / 13 |
Five issues were found by both. On three, the earlier review noticed the neighbourhood but Sol supplied the actionable placement or method. Five belonged to Sol alone: computation-version drift in a fingerprint, a silent-success ICE watcher, swallowed kitty-events outside process_frame, replay that was not deduplication-safe after bail-out, and the wider position-96 enforcement surface. This was production work, not a toy benchmark. The paths touched live system behaviour, operational recovery and controls around real authority.
It was also a retrospective fixed-set audit, not a randomised tournament arm or a model-family accuracy estimate. We do not use thirteen issues to write a natural law. We do use a 13-to-5 complete-finding result to decide that Sol leads repository inspection and owns adjudication tomorrow morning; independent semantic review still comes from another context.
The same thing happened to our internal test bank. Sol reached 100 per cent deterministic acceptance on the current bank, so we had to rewrite the tests. That is not moving the goalposts after an inconvenient result. The old suite remains part of the record; it had simply stopped separating frontier configurations. We versioned a harder successor because a ruler on which every current candidate reads exactly one metre is now a souvenir.
The model had not broken the test. It had eaten the ruler.
This year alone the workshop has changed hands several times. Opus gave way to Fable at the centre. Fable's one-shot advantage made the fallback feel slow. Sol then arrived, made mandatory delegated authorship look like an expensive constitutional relic and won the fixed production review set thirteen to five on complete findings. At the current pace of the AI wars, one can leave for a fortnight's holiday and return to discover that the foreman has changed, the drawers have been reorganised and the old benchmark is being used to steady a table.
A model name is not a preserved specimen. Providers continuously alter the machinery behind it: inference effort or “juice”, serving routes, speed, decoding policy and, at times, the effective weights behind a stable product label. Some changes are announced and versioned. Others arrive as Tuesday. A result therefore belongs to the service that produced it, not merely to the name printed on the menu.
So the experimental unit needs more than a model label: model plus route plus exposed build or snapshot, inference setting, adapter, tools and date. We will not rerun 608 rows every Tuesday. We will keep a lean matched screen, requalify after a material model or route change—or an unexplained behavioural shift—and replace a test bank when it saturates. A workshop which never retests its winners is not stable. It is stale.
// winners, dated
The experiments produced clear workshop choices. The completed 608-row tournament made the first roster cut; the 28-assignment shakeout made the second; 72 executions tested the selected workflow; and 24 direct controls made the current operational choice for cohesive authorship plain. These are workshop decisions, not hereditary titles.
As of 13 July 2026, Sol wins direct authorship on small cohesive work and owns orchestration as the workshop's accountable centre. On twenty-four matched assignments, direct Sol and the Sol-plus-Terra implementation topology both passed twenty-four deterministic evaluations; direct Sol used 58.14 per cent fewer reported implementation tokens and was lower in every pair. Direct Sol also passed all fourteen selected known-gap probes. Terra wins the independent-implementation slot: it implements genuinely separable packages. It also attacks cohesive Sol work and devises adversarial tests, but that review assignment is an adopted policy rather than a calibrated Terra-versus-reviewer victory. Fable takes first semantic review. Luna adds the blind second view on every non-trivial or high-risk change. Opus 4.8 is the semantic fallback only when an independent Claude route has headroom; an independently provisioned route handles capacity. Every actionable reviewer claim receives a disposition, and only reproduced findings can trigger repair. Fresh Terra normally repairs confirmed ordinary findings; Sol owns dangerous-boundary repairs. Sol retests, inspects and sends the result through fresh independent review.
The exclusion ledger matters too. After the 608-row common tournament, Grok, GLM, Mistral and DeepSeek failed the first cross-experiment roster cut; the lower-performing of the two Opus effort configurations also ended there. In the seven-route shakeout, Gemini 3.1 Pro left after repeated route-capacity failures, Flash left after three mechanically passing patches produced three reproduced semantic failures, and Sonnet left in the role-based second cut. Kimi remained a specialist rather than a default. The eliminated worker families remain eligible for Council seats when a heterogeneous search benefits from them, because Council proposes hypotheses and no hypothesis may change code or a decision until it is grounded and survives the appropriate falsifying test. Those are decisions about this workshop, not universal rankings of the weights.
Council gets called whenever the map or blast radius matters: strategy, research and architecture; complex feature pre-flight; and production code where money, privilege, persistence, concurrency or recovery lowers the price of another pair of eyes. One reproduced security boundary is worth a stack of refuted hypotheses. A feature which lands in one shot because the room found the missing premise has paid rent too.
Those are winners. They are not permanent appointments.
The tournament ate the weekend, the calendar and four days of perfectly serviceable July. In return it gave us one accountable mind, independent coverage, several useful sceptics and a small bell that rings only when a finding has actually been reproduced. A few weeks earlier, the table looked different. Sol then began returning perfect deterministic scores on the current bank and we had to build a harder ruler.
At the present speed of the frontier, a fortnight's holiday is enough time for the workshop to acquire a new foreman. The crown is real. It simply comes with a best-before date.
That's the take.
The chronology contains a 608-row common tournament, a separate 28-assignment shakeout, a 72-execution workflow study and 24 direct-Sol controls: 732 recorded assignments or execution rows in bookkeeping terms. They are not one pooled sample. The shakeout's scored comparison contained 21 assignments after its fourth task was invalidated; the GLM diagnostic extension, repair calls, semantic reviews and Council seats retain their own denominators because they are different experimental events, not missing rows.
The direct comparison is post-hoc and historical rather than a concurrent randomised trial. Sol had already processed the same contracts in earlier planner and integrator roles, and service, cache and time conditions were not randomised concurrently. It is strong operational evidence about small cohesive tasks, not a claim about latent-quality superiority or large changes with several independent packages. That is why Terra's implementation role is conditional rather than abolished.
The Council retrospective is separate private-project evidence, not part of the public-synthetic tournament. Its job here is to calibrate Council's role: hypotheses first, mechanical reproduction second, with a lower threshold for convening when the boundary is dangerous.
The 10 July table was a retrospective audit of one fixed thirteen-issue production set, not a preregistered or randomly sampled benchmark. Its first review column was labelled "Claude" and records the Fable-side review in the working setup. "Complete" means the issue and actionable placement or method were present; "partial" means the area was noticed but the placement or method was not. The set construction and unmatched historical conditions limit inference, so we use it for a dated workshop decision rather than a permanent model-family accuracy estimate. ↩