How the engine works: search and games

The business decisions evaluate policy over the facts you send. These games show what the engine does when the answer has to be found rather than looked up: it searches ahead and certifies a move when it can, changes technique when the position allows an exact answer, and weighs two goals every tick to pick a strategy for the situation. Every request and response is shown in the API inspector.

PreviewDemo endpointsNo installEngine source: loading

What runs here

The games run on the playground service at /api/try/games/*. These are demo endpoints, not the product API. The four-in-a-row and Reversi engines are ports of the game adapters in the Helixor reasoning service, run only on the server, and are tested to return exactly what the reasoning service returns for the same positions; the badge above shows the source commit the service reports. The arena duel is written for the playground. Nothing on this page is simulated: when the service cannot be reached the page says so and shows no boards.

Examples#

Connecting to the playground service…

Search with proofs

First move

Drop a disc to start. After each engine move this panel shows what it searched and why it chose the column.

Which capability this shows

Search, and a proof when there is one. For every legal column the engine searches the replies four plies deep, up to 12,000 positions. When every line of play within that horizon ends in a win for it, the column is certified: a proof, checked by the tests of the playground against an independent full-width search, that the engine wins whatever you play. Otherwise the engine plays the column its search preferred and says so: the preference is a softmax over search values, not a calibrated probability.

Why rules alone cannot do this. A rule evaluates conditions over the facts it is given. Choosing a move means generating the replies to each candidate, and the replies to those, and a proof that a move wins has to cover every one of them. Rules can check that a column is legal, and the engine does that before it searches; they cannot produce or search that tree.

Not shown here. The engine does not learn across four-in-a-row games on this page. Beyond four plies it has no proof, so it can lose. See Ask the reasoning service, and handle abstentions for how answers with and without a proof are reported by the reasoning API.

Choosing the technique for the position

First move

Play a highlighted square. After each engine move this panel shows which technique produced it.

Which capability this shows

The engine picks its technique from the position. With more than 10 empty squares the game tree is out of reach within a request, so the engine runs a depth-limited search with a positional evaluation (corners, mobility) and plays its preferred move. From 10 empty squares down it searches to the end of the game. When that search finishes within its 150,000-node budget, the move is certified and the engine reports the exact final disc margin with best play by both sides. In the tests of the playground the exact search finished for 39 of 40 positions tried at 10 empty squares, in about a second; when it runs out of budget the move is labelled endgame_budget_exhausted and is not certified.

Why rules alone cannot do this. A rule set applies the same kind of logic everywhere. Here the engine moves from an estimate to an exact answer when the problem becomes small enough, and every move says which one you got. The margins it certifies are checked in the tests against an exhaustive search with no pruning.

Not shown here. No learning across games, and no opening knowledge.

Two goals, seven strategies, learning from outcomes

What it is doing

The objective: a kill is what scores; the longer you stay alive before making it, the more it is worth; just hiding scores almost nothing. A kill earns 0.5 plus up to 0.5 more for the time alive before it; no kill earns at most 0.1 for staying alive to the end.

Every tick, each player weighs two goals: Survive (keep health and armour, get out of the line of fire, recover) and Prevail (damage and eliminate the other player). Behind, hurt or reloading, it leans to Survive, because dying forfeits the kill; level or ahead, and more so as time runs out, to Prevail. It scores seven strategies against the current state, term by term, and plays the best. After each episode the engine updates its beliefs about which strategies did better than usual against this opponent. On this page that learning changes its choices but does not raise its objective; the numbers are below.

Why it matters beyond games

The same loop, goals to strategies to constraints to outcome learning, runs the sales assistant digital worker and business decisions: weigh the goals for this situation, score the options within the rules, act, and record what worked.

How it differs

Fixed-priority game AI, behaviour trees. Hand-ordered priorities: the same situation always gets the same answer, and it does not adapt. The opponent here is one of these.
A language-model agent. Seconds and tokens per decision; its reasons are generated text, not a score breakdown.
A trained reinforcement-learning policy. Needs very many episodes to learn; its reasons are opaque weights.
Helixor. Every decision carries its score term by term. Beliefs change its choices after a handful of episodes and can be read and reset (here they do not yet improve the result). A decision takes well under a millisecond of compute and no model tokens; the time is measured below.

Opponent prefers Engine keeps what it learns

Paired run

Is it getting better over time? Not here.

Against the seven opponents

Against the camper (one fixed habit)

The engine's mean objective J by tens of episodes, with learning carried from episode 1 to 100 and without it, from the playground's tests (three seed blocks; the left chart also averages the seven opponents). Neither learning line rises above the other: over these 100 episodes learning does not make the engine better at the objective, including against an opponent with a fixed, exploitable habit.

Run an episode: the engine (blue) against an opponent (coral) with a fixed preference for the strategy you picked. Under each player you see its two goals, whether each decision moved it closer to them, and how long each decision took on the server.

How it is measured

The objective J of each player for an episode of up to 120 ticks: with a kill, 0.5 + 0.5 × ticks alive before the kill / 120; without one, 0.1 × ticks alive / 120. A player eliminated in tick t was alive for t − 1 ticks, and dying forfeits the kill: when both fall in the same tick, neither gets the kill credit. The live panel shows J so far; the last tick shows the episode's J. Win, draw and loss are shown as a secondary reading.

Goal weights. Survive weight = 0.45 + 0.30 × deficit + 0.25 × wounded + 0.15 × empty clip − 0.25 × stalemate pressure, kept between 0.1 and 0.9; Prevail gets the rest. The deficit compares effective health (health plus half the armour) with the opponent's. The pressure pushes a level or leading player to engage when nobody has fired for a while, and more and more through the second half of the episode, since a kill after the cap counts for nothing; it is zero for a player trailing by 10 points or more, so it never overrides a losing player's survival.

Goal attainment, from 0 to 1 at the end of each tick. Survive = 0.75 × health + 0.10 × armour (up to 50) + 0.15 when out of the line of fire. Prevail = 0.75 × the damage done to the opponent's health + 0.25 when it can fire right now. Eliminating the opponent sets Prevail to 1.

Decision impact. The change in the player's goal score (its two attainments, weighted as it weighted them when it decided) from the moment it decided to three ticks later. Above +0.02 the decision helped, below −0.02 it hurt, otherwise neutral.

Decision time is measured on the server: the time to weigh the goals, score the seven strategies and choose, for that player on that tick. Decisions per second is one second divided by the mean. The playback speed in your browser is a presentation choice and has nothing to do with it.

Episode counts. An engagement is a run of ticks with shots fired, ended by two quiet ticks. A retreat is two or more ticks in which a player that is behind moves away from the other. A lead change is the lead in effective health passing from one player to the other.

Learning. After each episode the engine credits each strategy with what it contributed to the objective while it was in control: each tick, the value of a kill at that moment times the damage it dealt, minus the same times the damage it took (both as a share of full health, armour counting half). A kill adds its J; being eliminated subtracts the kill value it forfeits; both are shared by the strategies of the last three ticks. Regaining health earns nothing by itself; it pays off only if it keeps the player alive to make a kill. Each strategy is judged against its own typical contribution against this opponent: better than usual is confirmed, worse is contradicted, weighted by how much of the episode it was used. The ledger is a Beta posterior per strategy and opponent. Here a contradiction weighs the same as a confirmation, because both are noisy readings of a symmetric game (the runtime's default weighs contradictions three times, for rules where one counter-example matters most). At least two strategies always stay in play, and a retired one comes back on new confirming evidence. The next episode adds (belief − 0.5) × 40 to each score. This is the same ledger the runtime ships as HelixorBeliefLedger; see Track outcomes and confidence.

What learning does here: it does not raise the objective. In 2,100 paired episodes in the playground's tests (seven opponent strategies, three blocks of 100 seeds) the engine's mean J was 0.349 without learning and 0.338 with it, a difference of −0.011 with a 95% interval of −0.026 to +0.004: no gain. Without learning it eliminated the opponent in 846 episodes (median kill at tick 54) and was eliminated in 568; with learning, 793 (tick 58) and 573. Against the camper, which holds the same spot every episode, mean J was 0.467 without learning and 0.440 with it (−0.027, 95% interval −0.069 to +0.016): it does not learn to exploit that habit either. The learning does change what the engine chooses (against the cover opponent, at least one choice in 79 of 100 episodes), but the credit each episode gives a strategy is noisy next to its effect, so the changes do not add up to a better result within 100 episodes. We show this as measured rather than tune the arena until learning looks good. A paired run of 10 or 20 episodes is noisy; the interval shown with it says how much.

Not shown here. The arena is a two-dimensional simulator. The learning is outcome memory only: there is no proposal, golden regression gate or admitted policy version here; that loop is in Close the learning loop. What the engine learns lives in your browser tab: each request sends the ledger back, and the service stores nothing.

API inspector#

Every call this page makes, newest first: method, path, headers, the exact JSON body, the response with its status and timing, and what each field means.

Demo endpoints and the product API#

This page calls	Kind	What it illustrates in the product
`POST /api/try/games/connect4/move` `POST /api/try/games/othello/move`	Playground demo endpoint, anonymous, rate limited	Game goals `game.connect4.v1` and `game.othello.v1` on the reasoning service's `POST /v1/decide` Preview. The reasoning service is not publicly deployed and needs a caller credential. The inspector shows the equivalent decide request for the current position.
`POST /api/try/games/arena/duel` `POST /api/try/games/arena/compare`	Playground demo endpoint	Outcome memory with `HelixorBeliefLedger` in the runtime: `record`, `belief`, and `snapshot` / `restore` Next release. The inspector shows the equivalent calls.
`GET /api/try/games`	Playground demo endpoint	The catalog of these examples: budgets and the source commit of each ported engine.

Known issue in the reasoning service (Preview)

For game goals, POST /v1/decide currently reports a move that has no proof as an answer whose p_correct is the search preference, which is not a calibrated probability, and a certified four-in-a-row win fails with HTTP 500. Treat a game answer as certified only when proof.kind is solver_certificate. The demo endpoints on this page label both cases correctly.

Limits#

Budgets are fixed on the server. Four in a row: depth 4, 12,000 positions per move. Reversi: depth 4 and 15,000 positions per move, or an exact endgame search of up to 150,000 positions from 10 empty squares. Arena: 120 ticks per episode, 20 episodes per arm of a paired run.
Shared limits. These calls share the playground's per-address rate limit and 8 KB request cap. A request that does not finish in time returns GAME_TIMEOUT.
Nothing is stored. Positions come from your browser with each request. The arena's learned beliefs come back in each response as a helixor.belief_ledger.v1 snapshot and go back with the next request; closing the tab forgets them. The service logs the game, status and outcome only.