Everything in the ARC-AGI-3 toolkit ran on a 48 GB M4 Pro without complaint: 25 games downloaded and played at 60,000 random actions each in six minutes, a hand written game loaded beside them, recordings, scorecards, all of it offline. Then a 31B model was asked for one move, and the machine spent between 67 seconds and seven and a half minutes on it depending on how the board was written.
That is the honest shape of ARC-AGI-3 on a Mac. The benchmark is light. The thinking is not. Here is where the line falls on this hardware, with numbers.
What ARC-AGI-3 on a Mac runs with no model at all
The games are plain Python on numpy, and they are fast. The 25 game survey stepped each game 60,000 times at a median of 14.0 seconds per game, which is over 4,000 actions a second including a reset after every death. The toolkit’s install is pip install arc-agi with Python 3.12 or newer, MIT licensed, and offline mode needs no key and no network once a game is on disk.
Nothing about that part touches the GPU or cares how much unified memory the machine has. A random agent, a search agent, a replay of a recording, a custom game, all of it would run identically on a much smaller Mac. The 48 GB matters only for the model, and the model is where the time goes.
How fast a 31B reasons on an M4 Pro, in tokens per second
The model throughout was gemma-4-31b-qat served by LM Studio at a 64K context, the one model this stack keeps loaded. Across the measured runs, output throughput was steady at roughly eleven tokens a second on short prompts: 4,103 output tokens in 361.7 seconds, 1,563 in 135.5, 1,097 in 94.7. On the full 64 by 64 board, where the prompt was 4,179 tokens, the run produced 4,281 output tokens in 442.7 seconds, or a little under ten a second once prompt processing is included.
Eleven tokens a second is the number to plan around. A move that needs 2,000 tokens of thought is three minutes. A move that needs 4,000 is six. The reasoning a board demands scaled from 692 tokens at 8 by 8 to 4,274 at 64 by 64, so the same arithmetic gives the move cost at every resolution: about a minute, three minutes, four minutes, and seven and a half.
Against a human who needs 22 moves for the first level of ls20, those are 25 minutes, 70 minutes, 90 minutes and two and three quarter hours for one level of seven, assuming every move is the right one.
How much memory the model held during the runs
The measurement queue sampled the resident size of LM Studio’s llama-server process after each call. It sat between 18.9 GB and 21.5 GB across the session, with the model loaded at 64K context and prompts of a few hundred to a few thousand tokens. On a 48 GB machine that leaves room for the toolkit, the games, and a browser, and not for a second model of the same size; we have measured that co-pinning two large models thrashes this machine.
A smaller board does not reduce that footprint in any way that matters. The 18.9 GB reading came after a 343 token prompt and the 21.5 GB reading after another 343 token prompt later in the session. The model’s weights and its context allocation are the cost; the prompt size moves the number by less than the session drift did.
What a move costs at each board size on Apple Silicon
Putting the throughput and the reasoning counts together, for one model on one machine:
| Board sent to the model | Reasoning tokens | Wall clock per move |
|---|---|---|
| 8 by 8 downsample | 692 | 66.9s |
| Colour summary, nine lines | 990 | 89.2s |
| 16 by 16 downsample | 2,136 | 191.9s |
| 32 by 32 downsample | 2,673 | 249.3s |
| 64 by 64, full | 4,274 | 442.7s |
One setting is worth carrying forward from those runs. A JSON schema on the 16 by 16 board gave the shortest run of the session, 1,078 tokens and 94.7 seconds, and made the answer parseable at the same time. It is a single run, and identical prompts on this stack have varied by more than four times, so treat it as the setting to test first rather than a measured gain. Reasoning effort, temperature and tool calling did nothing that survived that spread.
So on this hardware the practical envelope is a 16 by 16 board with a schema, somewhere between a minute and a half and twelve minutes a move depending on how long the model decides to think. That is playable for a few dozen moves per session. It is not playable for a full game: the median public game takes a first time human 638 actions end to end, which at 95 seconds a move is seventeen hours at human efficiency.
What an M4 Pro cannot do for ARC-AGI-3
It cannot run a per move language model agent at anything like the action rate the benchmark’s own human baseline implies. A person’s 7.4 minute median attempt is a few hundred moves; a 31B on this machine makes two or three in that time.
It cannot, at this model size, run two things at once. One model at 64K fills the memory budget that matters, and two agents sharing the one endpoint each get half its speed; the toolkit’s own processes are small enough not to notice.
It cannot run the competition’s Kaggle track directly, since submissions execute in Kaggle’s environment rather than yours, though everything about a submission can be developed and tested here first.
What it can do is the part that the winning entries actually did. The first milestone went to agents that had the model write a player rather than be one: a Python console the model programs, or a rendered frame it reads a few times per level rather than every move. On a Mac that turns a seven minute move into a seven minute program that then plays at four thousand actions a second. The technical report describes one such harness, which lets the model “execute arbitrary Python code to selectively retrieve and transform information from its action history”, and that design is the one this hardware is good at. The engine is fast. The model is slow. Build so that the fast thing does the work.