About this project

AI notice: This text is created with the support of AI systems; it is reviewed editorially and taken responsibility for before publication.

This reference is a by-product. It came out of an attempt to play Core War seriously — with the help of AI, and with the ambition of measuring every claim.

This page explains where the numbers come from, what worked and what did not. Especially the latter, because there is too little of that to read in this scene.

The short version

March 2026 — rank 654. The first approach was a classic evolution system: populations of warriors, mutation, selection through tournaments. The first submission to the historic 94nop Koenigstuhl landed at rank 654 out of roughly 1100 at the time.

July 2026 — rank 1. After a complete restart with a different approach, our warriors led all three standings of the same hill.

How that went in detail is covered in a separate article:

→ Three crowns on the Koenigstuhl

What works with AI, and what does not

Large language models can read, write and explain Redcode. As a tool they line up alongside optimisers and evolvers, with a profile of their own.

What blind evolution cannot do. Rank 654 was instructive. In a forty-year-old, highly optimised ecosystem, random mutation gains no foothold — the gap between "runs" and "competitive" is too large to cross by chance. More computing time would not have changed that.

What helped was something else: understanding proven architectures, following them instruction by instruction, and rebuilding them with our own parameters. The breakthrough came when we stopped breeding warriors and started analysing them.

Where AI is genuinely strong:

• taking foreign mechanics apart and translating them into comprehensible descriptions
• building measurement tools, rather than writing warriors directly
• evaluating large measurement series and finding patterns in them
• reconstructing an architecture from a description

Where it does not help: finding good constants. That is the job of number tools and measurement, not of language understanding. No model "knows" that step size 2667 beats 2000 — you compute that, or you measure it.

The honest balance: progress did not come from a model writing better warriors. It came from the measurement infrastructure that emerged, which made answerable questions nobody had asked before.

What got built along the way

rmars — a rebuild of the pMARS 0.9.6 simulator in Rust, result-identical to the original and verified against a frozen test corpus. The reason for rebuilding was not dissatisfaction with pMARS but measurability: the engine has channels that exist nowhere else — heatmaps, kill attribution, memory snapshots and complete single-round traces.

The narrated battle on this site was recorded with it. Being able to say which cell was written in which step by whom, and when it strikes, is not something you get for free.

A hill server of our own, computing three standings in parallel, and an analysis toolkit from which the figures on these pages come: the class matrix from 349,866 pairings, the rounds study from 1.17 million battles, the style tagging of 1104 warriors.

What we failed at

And now the part that matters most to us.

We hold three crowns — but with two different warriors. Arvon leads the main hill, Kaitain the other two standings. The obvious question: can one warrior do all three?

The answer is no, and the road there was instructive enough to write down in full.

The underlying conflict

The two warriors are not accidentally different but oppositely built:

Anti-paper demands aggression — find the opponent and clear it away by area. Anti-scanner demands resilience — spread out and absorb hits. Across all our warriors these two abilities are anti-correlated. You move along that frontier, not beyond it.

Four attempts, all negative

Constant tuning, imp patches, a second attack mode, and finally the most obvious attempt: boot both bodies into one warrior and run them in parallel. All net ≤ 0.

The co-boot fails structurally, not in execution: a core-wide clear inevitably damages a core-wide silk. The two cannot coexist because they use the same memory in opposite ways.

The only remaining architecture

If they cannot run simultaneously, then in sequence: classify the opponent early in the battle and then commit to clear or silk, never both.

We computed what that would gain with perfect classification — that is, with an omniscient oracle instead of a real detector:

+14.6 points over the current leader. And the detector would not even need to be good — around 60% accuracy would already win it.

So the ceiling is enormous. It still does not work.

Why it fails

Ruled out in order: it is not the ceiling (that is vast). Not the switching mechanism (that could be built interference-free). Not the cost of the chassis (about 5 points, comfortably covered by the gain). Not opcode ambiguity (that separated cleanly).

It fails on the locality and latency of observing.

A detector must find cells of the opponent in order to classify it. Early in the battle the opponent is spatially tiny and the core is vast — the detector would have to probe hundreds of cells sequentially. As a single process. And in exactly that window, a scanner whose entire job is searching kills it.

We built seven Redcode variants. They found between 30 and 112 occupied cells before dying — too few for a reliable decision. A distributed detector swarm meant to sidestep the latency did not help either: passive observers get bombed, and active ones share execution time with the main body and make the latency worse.

Two horns with no path between them: decision first means death by latency. Silk first with a detector in the background means interference.

What that means

Within the rule set, the one-warrior split is blocked by a fundamental conflict of aims: observing and surviving demand the same scarce resource, namely the early cycles. Whoever looks does not run. Whoever runs does not look.

We consider that a genuine result rather than an omission. It is documented in full, including every dead end and measurement series — if anybody sees a route we missed, we would like to hear about it.

Why we publish negative results

In the Core War scene a lot of knowledge is passed along and little of it is recomputed. That is understandable — measurements at this scale were impractical for a long time. The consequence is that some rules have survived although the field moved out from under them. The rock-paper-scissors triangle is the best example.

Our position is the mirror image: we have measurement tools and computing time but not thirty years of experience. So we write down what we measured — including and especially where it goes against our own assumptions.

These pages contain several places where we were wrong and left the correction standing. That is deliberate.

Contributions and feedback

If you find an error, measure a number differently, or think one of the dead ends described here is passable after all: we would like to hear from you. Contact via the imprint.

All example warriors shipped with these pages are either common property of the scene or our own work and freely usable. Foreign warriors are described and linked here, not shipped — details on the attribution page.

Related pages

• Three crowns on the Koenigstuhl — the project report
• Tools and engines — what we work with
• The strategy classes — the measured matchups

← Core War overview