ARC Prize 2026 closes for submissions on 2 November. The first milestone, judged on 30 June, went to three entries that ran open weight models locally, a 27B and two 31Bs, and every one of them had to publish its code to collect. If you have a local model and a laptop, this is the competition that was built for you, and the rules say so in writing.
Here is what an entry has to be, what it cannot do, and how to prepare one on a Mac before it ever touches Kaggle.
What ARC Prize 2026 pays, and for what
The ARC-AGI-3 competition page lists three kinds of prize. A grand prize of $700,000, “awarded to the first eligible agent that scores 100% on the ARC-AGI-3 evaluation.” Top score awards of $40,000, $15,000, $10,000, $5,000 and $5,000 for the first five places. And two milestone prizes of $25,000, $10,000 and $2,500 each, the first already paid on 30 June and the second closing on 30 September.
The 2026 overview fixes the calendar: milestone two on 30 September, submissions due 2 November, papers due 8 November, results on 4 December. The whole competition carries $2 million across three tracks, of which ARC-AGI-3 is one.
None of the milestone winners so far were frontier API systems. The milestone post names Tufa Labs first with an agent that “runs Qwen 3.6 27B FP8 locally”, Reki second with one that “feeds them to Gemma-4-31B locally, and asks for a single JSON object”, and a third entry also on Gemma 4 31B. That is the same class of model this stack runs, and it placed.
What an ARC Prize 2026 entry has to open source
The overview is exact about licensing: “all code and methods authored by the submitter must be made open source under a permissive public domain license (eg. CC0 or MIT-0)”, and third party code must be “available under, at least, an open source license which allows public sharing (eg. Apache-2.0, GPLv3)”. The competition page adds the timing: participants “opening source solutions by milestone deadlines” become eligible for that milestone’s money, and solutions must be public before the private evaluation score is issued.
That rule shapes the field more than the prize does. A team cannot win with a closed harness, and a team cannot win by wrapping a closed API in a way nobody else can run. The public domain requirement means the winning method becomes everyone’s, which is why the first milestone’s code is on Kaggle for anyone to read, and why entering with a local open weight model is not a handicap but the design.
What the Kaggle track does not allow
Two constraints from the competition page decide the architecture. Submissions “must occur through Kaggle competition”, and there is “no internet access during evaluation.”
No internet means no API calls of any kind at scoring time. A model has to be inside the submission, which is exactly why the milestone winners ran 27B and 31B open weight models: those fit in a Kaggle environment, and a hosted frontier model does not exist there. Hardware and compute limits for the Kaggle environment are, per the page, “announced with the competition launch”, so check the current notebook constraints rather than assuming.
The toolkit’s competition mode is the other set of rules, and it is enforced by the software: it is “REQUIRED to show up on the Unverified leaderboard”, environments “must be interacted with via the API”, each environment may be created “a single time”, “Only Level Resets are permitted, Game Resets are not allowed”, one scorecard per run, and “Scoring is against all available environments, even if you choose not to interact with them.” An agent that relies on resetting a game from the top, or on retrying an environment from scratch, will not score under those rules, and a game it never touches counts as zero.
How to prepare an ARC Prize 2026 entry on a Mac first
The toolkit runs the same games, the same engine and the same scorer locally, so almost all of the work happens before Kaggle. The sequence that has worked on this studio test stack:
Build the loop first, with no model in it. A 40 line agent that converts action ids correctly, handles click coordinates, checks state after every step and never sends a game reset is the skeleton competition mode expects. Run it random across all 25 public games and read the death counts and clears; that is your floor.
Then put the model in, and measure what a move costs. On this machine a 31B needs about 95 seconds a move on a 16 by 16 board with a JSON schema, which rules out asking it for every move and rules in the design the milestone winners used: the model writes or refines a player, and the player makes the moves. Test that design offline, with recordings on, so a failed game can be replayed rather than repeated.
Then score it locally. The scorecard the toolkit computes uses the same per level formula the leaderboard describes, and it will tell you, before you submit, whether your agent is efficient or merely finishing.
Finally, run it in competition mode against the API with an anonymous key. That exercises the one make per environment rule and the level reset rule against real server behaviour, and it produces a scorecard on the Unverified leaderboard if you register a key first.
What the public set tells you about the private one, and what it does not
The 25 public games are a development set, and the technical report is direct that they are “intentionally easier for both humans and AI” and do “not comprehensively represent the mechanics found in the private” sets. An agent tuned to the public games is tuned to games the competition does not use.
What does transfer is everything structural: the ten action subsets, the click games that need coordinates, the two kinds of reset, the frame format, the human baseline per level, and the fact that efficiency rather than completion is the score. An agent that generalises across the 25 public games without knowing which one it is in has the right shape. Whether it generalises to the 55 fully private ones is the question the 4 December results will answer, and the only way to be in that answer is to have open sourced the attempt by 2 November.