🤓 Latest Submissions
Tablekeeper, built by a six-seat dark factory
Six Claude Code seats on Opus 5.5 built Tablekeeper, a restaurant booking service, in one Band Desktop room, through all four stages. The only human input was one task message per stage, prepared before the run: 4 of the room's 3,260 messages. An architect splits each stage into items. A critic reads every plan before any code is written, a builder writes the code, a verifier checks each item on its own fresh clone, a designer reviews every screen at phone, middle and desktop widths, and a release clerk packages the stage and runs the organizers' harness. BLOCKED from the critic, REFUTED from the verifier and CHANGES from the designer stop work and go to the architect, which routes it back. A check counts only after it has failed on a deliberately broken version, and every seat's commit names the seat. Review changed the result. In stage 3 the verifier re-timed a verified item: 7 of 9 runs went over the 5-second limit. The architect sent it back, and identical reads came down to 0.90 to 1.05 seconds. Different queries still took about 3 seconds, an open risk in the stage-3 report; in stage 4 that code went over the limit, and the band reopened stage 3 and corrected it. In all, the critic blocked 8 plan versions and the verifier refuted 3 items. Stage times (task to final report) add up to 23 h 40 min. Model use was $513 at API list prices; the run used a flat Claude Max plan, about 18.5 % of one weekly limit. On the organizers' harness, from a fresh clone, each stage folder claims its own stage and stage 4 passes every shipped check of suites 1 to 4. The judges run more tests than the shipped ones. Run 1 stopped in stage 4 at Band's 10,000-message room limit; run 2 kept four seats' tool activity out of the room and finished in 3,260 messages. FACTORY.md lists all 20 failures and what each changed. That, the six mandates (none names the track) and the stand-up scripts are what another team needs to point the factory at a different spec.
6 Oct 2026
minimum viable effort
minimum viable effort is a general-purpose task agent built around one idea: never pay for a token the container can verify for free. Every task from /input/tasks.json passes through a zero-cost regex router that classifies it into one of eight shapes (math, logic, sentiment, summarization, NER, code-gen, code-debug, factual) and assigns a response shape and budget. Two bundled llama.cpp models (a 1.5B coder and a 4B general instruct, served on localhost) produce candidate answers at zero proxy tokens — and nothing local ships unverified. Math runs program-of-thought: the model writes an arithmetic expression and a tiny program, both evaluated locally, shipping only on cross-method agreement. Code must pass execution self-tests in a hardened sandbox. NER entities are verified verbatim against the source text; summaries against their word limits and a content floor; logic puzzles are brute-forced by generated constraint-enumeration programs. Tasks that fail local verification escalate through FIREWORKS_BASE_URL as terse minimax-m3 calls — capped completions, no system-prompt mass. Factual recall always goes remote (small local models hallucinate on open-domain facts). Logic escalations run with thinking enabled: the extra completion tokens buy back accuracy the terse path measurably loses. A global watchdog fair-shares the runtime budget and results.json is written atomically after every task — always valid JSON, exit 0, all configuration from environment variables. Built solo, with a self-authored evaluation harness (fixed bench + blind fresh-variant corpora), adversarial review fleets, and container smoke tests at the grading resource profile (2 vCPU / 4 GB RAM).
13 Jul 2026
