Seetrex Warden on the Ground Control scenario of CivBench

This is a pilot: one game per arm. We played two games of Ground Control with Claude Opus 4.6 in a Claude Code loop. The comparison game ran with Seetrex Warden, a gate that rejects the end of a turn while an obligation is overdue. The control game ran without it, on the same model, scenario, harness and setup (differences in the report). It asks whether the comparison game's higher querying rate came from our setup or from the gate; at one game per arm it cannot settle it.

What the paper found

CivBench (arXiv:2609.02459) has LLM agents play full games of Civilization VI through MCP tools; nothing enters the agent's context unless it asks. The victory-progress tool was called in 0.05–0.29 % of calls (the paper does not state how the range aggregates; our per-game recount of the six reference games gives 0.089–0.315 %). The playbook asked for it every 20 turns; the agents checked every 30 to 75 turns. The authors suggest commitment enforcement and do not build it.

Our reading, not the paper's: the diary entry, imposed by software, was written every turn; the check, only instructed, was not.

What Seetrex Warden does

Seetrex Warden is an MCP proxy between the agent and the game server. At each end_turn a deterministic rule engine checks the turn's facts; while an obligation is overdue, end_turn is rejected with the obligation named. Every decision goes to a ledger that can be verified under agreement.

Two rules fired: R01 makes a status check due after 20 turns without one, the CivBench playbook's cadence; R04 rejects end_turn while it is overdue. No rule may name a move. It forces the check; what the agent does with what it sees is the agent's.

The figure

Figure 1 plots each get_victory_progress call by turn.

Each game ran in takes, one agent process each. The agent saw two things of Seetrex Warden: three extra tools, commit, dispose and ledger, whose descriptions say end_turn is rejected while a commitment is overdue, never called in 18 takes; and the text BLOCKED by Warden in the 9 rejected end_turn results, echoed once in a Claude Code compaction summary (take 13). Nothing else: no prompt text, no operator message.

Nine of the 21 counted queries are forced, the first after a rejected end_turn.

The numbers

Up to turn 255, the control game queried victory progress in 4/3,728 = 0.107 % of its calls, the comparison game in 21/4,236 = 0.496 %, and the highest reference game at that horizon in 5/2,059 = 0.243 %. Four verdict rows were fixed before the control game, with the comparison result already known: row 1, control at or below the reference; row 2, between; row 3, at or above the comparison; row 4, invalid. The result is row 1, "sustained": only not falsified at one game per arm. Its sentence reads:

Without Seetrex Warden, on the same setup, Opus 4.6 queried victory progress in 0.107 % of its calls up to turn 255, within the range of the paper's 6 games at the same horizon (0.243 %); with Seetrex Warden, 0.496 %, outside it.

Its note: at turn 255 the 12 non-forced queries give 12/4,236 = 0.283 %; they are above the reference at every horizon from 140 to 255, at none from 121 to 139, and below another reference game's whole-game rate, 10/3,179 = 0.315 %. They are no baseline without Seetrex Warden: the agent that made them had the gate in front of it. Row 1 does not exclude that the comparison game queried more because of its own trajectory.

To leave row 1, the control game would need g_R = 10 in-window queries, six more; to reach row 3, g_E = 19, fifteen more. These measure distance from the other rows, not likelihood.

Both games ended in a Babylonian science victory, seen on screen. The comparison game's victory is not attributed to Seetrex Warden: the control game also won.

Limits

One game per arm, with no statistical inference; temporal order is not cause. The arms were not simultaneous: comparison game 2026-09-25 to 2026-09-27, control game 2026-09-27 to 2026-09-28; the state of the served model between those dates is neither controlled nor observed. Both ran with resumptions: 17 resume messages in 18 takes, and 7 in 9. Of the 12 non-forced queries, 4 are among the first 30 calls of their take and 4 at indices 46-48. Other declared differences include operator reloads after game crashes, in the comparison game only, and one control take started without a resume message. Two earlier starts of the comparison arm were abandoned and not analysed. The control protocol was written after the comparison game had been measured.

Against the reference games, Seetrex Warden and the setup (a Claude Code loop, its compaction, resumptions between takes) change at once; only the control game separates them. Reference turns come from the CivBench dataset's turn column, a different instrument from our turn tag; the two agree on 96.15 % of reference calls. The report lists the seven validity checks made outside the published data and the deviations from the comparison game's criterion (90cb986); the protocol is internal.

Each criterion was committed before its game started: 90cb986 on 2026-09-25 for the comparison game, a9f2eb4 on 2026-09-27 for the control game. The dates come from a private repository's git history, with no third-party timestamp.

What is published

• The technical report
• Figure 1, SVG and PNG
• The data package (CC BY 4.0; the game text it contains is not covered, see its README)
• The measurement scripts, MIT
• The two ruleset files

The Seetrex Warden engine and the ledger verifier are not published. Scenario, harness and reference games come from CivBench, its repository and its dataset. Seetrex Warden is unrelated to the warden-agent MCP proxy and to other projects named "Warden".

Pilot requests for your own long-horizon agents are open: pilot form.