Standing Against Large-Scale Compute on Thousands of GPUs with One Desktop and a Few Dollars — TANREN, a Model for Autonomously Evolving Code

Introduction: Why Evolve Code, and Why Now

Modern AI development has entered a contest of large-scale compute run on thousands of GPUs. You train a giant frontier model for months, and at inference time you spend enormous numbers of tokens to make it think longer and deeper. That is the current trend. But behind it stand thousands of GPUs and millions of dollars — a wall of capital that is out of reach for an individual or a single company.

TANREN (鍛錬, “tempering through discipline”) is a methodology for the “democratization of AI” — something an individual can actually do — born from the wish to break out of a situation that presumes this scale of compute.

What we aim for is not to spend a fortune training an LLM’s “weights.” It is an approach that uses a cheap LLM, which does no additional training, as a “mold for code,” and then automatically “evolves” the programs it emits. The ceiling that large-scale compute reached after training on hundreds of millions of frames — we reach it with a single desktop, a few days of search, and only a few dollars of API cost. That is what the “TANREN model” makes possible.

To be precise about that figure: most of those few dollars go to the lightweight LLM that mass-produces mutations. On top of that, the “diagnostic loop” described below calls a frontier model a handful of times to put the facts of a failure into words. Because the number of calls is small, the effect on total cost is minor — but it is a step you cannot skip if you want to reach the ceiling.

---

Lineage and Boundaries, to Avoid Misunderstanding

This concept is built on top of an accumulated body of work.

TANREN’s basic structure — frozen LLM × deterministic verifier × genetic algorithm — is a direct fork of DeepMind’s FunSearch (2023) and AlphaEvolve. What TANREN adds is a lightweight implementation recipe an individual developer can run on their own machine, and its own “diagnostic loop” that states the moment of failure as fact. We position it as a development and application of the FunSearch line of work.

This method also has a clear boundary between what it can and cannot do.

• What it can do: problems where value concentrates in “a few structural insights” — discovering algorithms, rule-based optimization, deterministic scheduling.
• What it cannot do: problems that need countless micro-adjustments, human subjectivity or perception, or “reflex” — image recognition, smooth continuous physical control, grading an essay.

This method does not work for every problem. But within the domains where it applies, it produces a result equal to, or better than, continuing to run a frontier model.

---

The Essence Is the Same: Maximizing ROI / VOI Through “Absolute Evaluation of the Result”

What is truly needed in business and in practice is not the scale of an AI model or the number of tokens it consumes. It is only this: “Did it achieve the goal / KPI it was set?”

• In a game environment: the final “score.”
• In a data center or infrastructure: cache “hit rate,” or the “load-reduction rate” of tail latency.
• In logistics or packing: the “number of bins” saved.

The axis of evaluation does not change at all, whether you use a frontier model costing millions of dollars or a few dozen lines of Python that TANREN forged.

If that is so, then in a domain whose essence is “discovering structure,” there is little reason to call an expensive model on every request and keep accumulating inference cost.

What TANREN prioritizes is ROI (return on investment), and VOI (Value on Invest: maximizing the value returned on the investment).

Metric	Frontier model / large-scale RL	TANREN model (evolving code)
Achievable result (KPI)	Reaches the ceiling (theoretical maximum)	Draws level at the same ceiling (theoretical maximum)
Development / training cost	Thousands to tens of thousands of dollars + weeks	≈ $5 of API cost + a few hours (lightweight-LLM mutations plus a handful of frontier-model calls in the diagnostic loop)
Inference (operating) cost	Per-request token billing (expensive, slow)	Just running a Python function (≈ $0, fastest)
Operational safety	Hallucination / quality-regression risk	Fully deterministic code (safe, readable, auditable)

Against the trend now sweeping the AI world — “add reasoning steps and, above all, burn tokens” — TANREN proposes a different approach: “once you have tempered the code for a few dollars, the operating inference cost is nearly zero, forever.” This is the smart way to use AI that we propose from here on.

---

---

How It Works: “Three Parts” and “One Path” That Forge a Fine Blade at Low Cost

The structure of the TANREN model is extremely simple. Instead of rewriting a giant model’s parameters (weights), we treat “a single Python function” as a gene and evolve it.

The apparatus consists of just three components and one powerful feedback path (the diagnostic loop).

flowchart LR
    A["Frozen LLM<br/>gemini-2.5-flash-lite"] -->|emits code| B["Hundreds of<br/>candidate programs"]
    B -->|deterministic evaluation| C["Verifier<br/>(pure Python)"]
    C -->|winners survive| D["Winner becomes the<br/>next generation's 'parent' code"]
    D -->|back to the mutation prompt| A
    C -.->|measure the moment of failure| E["Diagnostic loop<br/>(facts only, run once)"]
    E -.->|inject the measured facts| A

Role	Concrete implementation	Idea and intent
Creation (mutation)	Frozen lightweight LLM (gemini-2.5-flash-lite)	No additional training at all. A mold that mass-produces “variations” of code at low cost and high speed.
Judgment (verification)	A deterministic scoring program in pure Python	An LLM is never used. A human-defined formula or simulator leaves zero room for cheating or hallucination.
Memory (selection)	Behavior-signature archive + island model	Rather than cramming intelligence into one black box, it accumulates as a diverse “population (pool)” of code.

Concretely, the smallest unit of evolution — the “gene” — is a source-code string describing a single Python function (act(ram, ...) for a game, priority(now, ...) for a cache).

We dynamically compile this in a restricted, safe namespace and pass it to the verifier. The evaluation procedure applies the same discipline as machine learning: Train / Validation / Holdout (unseen validation data) environments are strictly isolated by seed. On top of that, “improved on the current best code” is defined as a significant difference confirmed by a sign test in a Holdout environment never referenced during the search.

---

The Breakthrough That Broke the Plateau: the “Diagnostic Loop”

If you simply run this kind of code-evolution script naively, the AI always hits a dead end (a local optimum) somewhere. In Pong, for example, the needle of evolution stops dead at around 16 out of a possible 21 points.

The mechanism that got past this plateau and reached the theoretical ceiling for about five dollars is TANREN’s own diagnostic loop.

1. Automatic measurement of the decisive failure: millisecond-level tracing. The verifier (Python) runs the code and captures, pinpoint, the raw log of “the moment a point was lost” or “the moment a cache miss occurred” (128 bytes of Atari RAM, or the recent access history for a cache).

2. Putting only the facts into words: a one-time run by a diagnostic model. The captured raw log is handed once to a frontier model (a powerful LLM). What the model is allowed to do here is state only the measured facts, objectively. (e.g., “This function always returns 0 on frames where the ball’s Y coordinate changed sharply.”) Across the whole search, this call is made only a handful of times, when a plateau is detected. The cheap model alone cannot break out of that plateau, so a frontier model — limited as its role is — is a necessary part of the method.

3. Sealing off the prescription, and injecting: joining it to the prompt. It is absolutely forbidden to write how to fix the code (a prescription) or any guess. Only the extracted facts are dynamically injected at the end of the mutation prompt.

4. Mass production of variations, and selection: cheap LLM ✕ deterministic verification. The cheap LLM (Flash-Lite), given those facts, generates hundreds of code variations premised on them. Final correctness is judged not by a human and not by an LLM, but only by the score of a deterministic test.

---

A record of where a hand-written fix fell short One episode illustrates what this division of labor means in practice. Working from the same measured facts, the fix I — the developer — wrote by hand, reasoning that “in theory this should fix it,” dropped the score to $-15$ when run. My domain knowledge was not sufficient to capture the structure behind the environment. The evolutionary loop, given the same facts, reached $21.0$ (a perfect game) through code mutations I had not anticipated. The facts narrow the range of the search, the large volume of LLM-generated mutations fills that range in, and the verifier selects on results alone. Had any one of the three been missing, I do not believe this result would have been reachable at this cost.

---

Highlights: Pong and Cache

Of the “fine blades” TANREN has actually forged, here are two representative ones, in brief. The code and the full verification protocol are written up in each article of the series.

1. Atari Pong — Drawing Level at the Theoretical Ceiling (21–0 across 40 games)

The input is only the game console’s 128 bytes of RAM. The evolved code scored 21–0 in all 40 games — including 30 start positions never seen during evolution — and discovered on its own a serve angle the opponent physically cannot reach (a kill-shot). Random play scores −20.7, a human tester 9.3, DQN’15 18.9, and the theoretical ceiling is 21.0. The details are in Part 1.

2. LLM Cache Eviction — Beating 20-Year-Old Classics

Metric	Value
Holdout (future window of a real trace)	11 wins, 1 loss · sign test p = 0.003
Hit rate	84.3% → 86.6% (+2.3pt)
Misses avoided	−932
Opponents	ARC / LIRS / W-TinyLFU (20-year classics)

We forged the decision of “what to evict” for a RAG server’s KV cache. On the future window of a Twitter real trace, it beat the strongest classics — ARC / LIRS / W-TinyLFU — 11 wins to 1 (sign test p = 0.003). It is a few-dozen-line policy that reads each document’s “access rhythm” and “co-occurrence.” The details are in Part 2.

---

Deep Dives (Blog Series)

What “fine blade” this mechanism forged in each domain, and where it met its limit — each record is published, with code and measured numbers, in the articles below.

• Part 1. Atari Pong — From 128 bytes to the theoretical ceiling; the self-discovered “kill-shot” → read
• Part 2. LLM Cache Eviction — Beating 20-year classics on the “future” of a real trace (coming soon)
• Part 3. Atari Breakout — The self-discovery of the “tunnel strategy,” and where readable code stops (coming soon)
• Part 4. vLLM on Real Hardware — Patching an evolved policy into a production server (L3 scheduler / L1 prefix cache) (coming soon)
• Bonus. Where It Did Not Win — A math record (within one step) and continuous control (the wall of reflex): measuring the method’s range (coming soon)