Bold Mutator on Groq

Run 2 concluded the tool library never got a fair trial because the mutation prompt told the model to be conservative. If the prompt instead pushes bold, theory-primed mutations that explicitly reward using inherited tools, will the library finally show a real effect?

Two changes at once, a known confound I accepted for speed: (1) the mutation prompt was rewritten to explicitly ask for "cumulative invention," using inherited tools "like a craftsman," hybrids welcome; (2) the engine switched from the slow subscription CLI to a free, fast model — gpt-oss-120b on Groq — so runs took minutes instead of hours, at zero cost.

Prompt tone (conservative → bold) and inference engine (Haiku CLI → free Groq model), together.

Coverage, best and mean Elo, tool count, and — new for this run — how many times bots actually called inherited tools during evaluation matches.

Coverage landed at 61.1%, mean Elo 976, 7 tools extracted, 107 mutation calls. But the headline is adoption: prior arms barely touched the library (one tool, manhattanDist, sat at zero uses). This run, tool calls exploded — manhattanDistance alone was called 621,818 times, lineOfSight 45,381 times, roughly 726,000 inherited-tool calls total. Telling the model the theory behind the library, not just giving it access, was the actual adoption lever. This arm hit the best exploration of any evolved run so far, close to cold sampling's 69.4%.

Champion quality collapsed. Best Elo landed at 1029 — the worst champion of any arm run so far. Generations 51 through 100 were roughly 90% pure corpses: bots that went 0 wins–24 losses–0 draws because their code threw an error at runtime and forfeited every match. Autopsy of the replays found the real cause: bold mutations of already-complex, 100-line parents produce runtime-fragile children — the complexity death spiral. Once most children in a generation are crashing, selection has nothing left to select from. A live reproduction confirmed it: 1 in 5 fresh mutations crashed even against an empty library, ruling out a poisoned tool as the cause.

Ops gap found the same run: the run's abort tripwire watched for API failures, not for a streak of crashed bots — 50 calls were burned producing invalid bots with no warning raised.

Boldness bought real exploration and real tool inheritance, at the cost of viability. The fix is the one idea I'd proposed right after Run 1 and finally had a reason to build: feed a bot's own runtime error back into the next mutation prompt — "your last child crashed with this error, fix that and keep the strategy." Information pressure, not less boldness.

107 API calls · $0.12–$0.14 (gpt-oss-120b via Groq).

Series through Run 3: 520 calls · $3.24–$3.87. Call counts are exact, straight from each run's metrics file. Costs are a range rather than a figure because the provider bills cached input tokens at half price and does not report the cached fraction in the API response, only in the console dashboard, so the upper bound prices every input token as uncached and the lower bound prices all of them as cache hits. A sampled dashboard minute showed 68% of input tokens were cache hits, which puts the truth nearer the bottom of each range. Token counts are measured exactly from Run 8 onward; earlier runs additionally reconstruct tokens from Run 8b's measured per-call profile (3,642 in / 1,348 out), because the usage field was discarded before it was ever written down. A bound is not a measurement and a reconstruction is neither, so both are labelled.