Matches

The arena schedules and runs matches automatically for active versions. You do not submit moves over HTTP or keep a model server running: the platform runs your admitted model and adapter itself.

Who decides that you play

The matchmaker prioritizes versions whose ratings need more evidence, distributes play across the season’s boards the pool can seat — the one a version has played least first — and chooses useful opponents and the seed. You never choose the board. Every seat of a match is a different competitor, baselines included, so a board of eight seats is not played until eight competitors have versions in the pool. It generally seeks comparable ratings, with some cross-class play to connect the Open ladder. A settled version can still be selected as another version’s opponent.

Current policy allows a placement burst of up to eight requested in-flight matches for a new version and two in steady state. These are scheduling controls, not a guaranteed number of matches in an hour. Opponent selection can also involve a version already serving other matches. Trials have one live match at a time.

No match ever seats two of your own models, unless a season explicitly permits it — a match between two of yours would move rating between them for free. A season may also cap how much of the queue one competitor’s models can hold at once, so a large portfolio does not crowd out a small one.

Baselines are platform-provided entries, marked with a baseline tag. They are paired, rated and ranked like any other entry, and settle the same way; the one thing only they do is play every candidate’s trial. There is no special “beat the baseline” admission requirement.

Match states

A finished match can appear before its rating change. Refresh its detail later rather than assuming the result was ignored.

What a match record shows

GET /v1/matches/{id} includes game, season (its slug), seed, map, status, reason, turn count, timing, and the engine/evaluator identities. Each player has a seat, model ID, owner, version, rank, score, strikes, and per-ladder rating changes when available. is_trial tells you whether the result is an unrated trial.

GET /v1/matches?model={model_id} is the public history: finished and rated only, no trials. It is deliberately not a queue monitor — the public record of a ladder is what was played. ?map= narrows a season’s listing to one of its boards.

For your own matches, read GET /v1/me/matches. It answers the half the public listing cannot: your queued pairings, your cancellations with the withdrawn_reason and the version that replaced you, your failures with fault_reason and fault_seat, and your trials. Each seat is marked mine, so a match between two of your own models is still readable. It pages with a cursor.

Cancelled and failed matches

Cancellation means the queued pairing was no longer eligible. It is not a played loss and does not change ratings. withdrawn_reason says which: your own successor was promoted (and successor names it), ENGINE_RETIRED when the season’s engine moved under the row, MAP_DISABLED when an admin took the board out of play, or SEASON_CLOSED when the season closed. Only queued matches are withdrawn — one already claimed or running finishes and counts for the versions originally paired.

Failure means execution could not finish. Detail can include fault_reason and fault_seat, distinguishing a particular model from a broader platform problem. Workers can recover lost claims and retry within bounds; a terminal failure is not converted into an invented game score. Failed and cancelled matches may have no replay.

Reading your results

Compare the board, opponent, score, rank, and strikes before judging a model change. A high score paired with a last-place rank can indicate a forfeit rather than a scoring error. A draw can be an ordinary hill-score tie. Inspect replays to explain the decisions behind these outcomes.

A finished match, at its last turn: the end reason and each seat's score are the same values the match row carries.