Generate outcomes
Code simulates every legal move, before the random spawn.
Why I built this
I started this because I was curious how Jev would play 2048. Jev makes quick probabilistic choices, and 2048 repeats the same decision hundreds or thousands of times. Every move has a visible result, but the random tile afterward means there is not always one obviously correct answer.
My first version gave Jev the board and asked it to choose up, down, left, or right. That was not a good use of the model: it had to work out what each move would do before it could compare them. I changed the setup so the game calculates every legal resulting board, hides the direction names, and lets Jev choose between anonymous outcomes.
Then I wanted to see how its choices changed with more information. One version sees the boards and rules. Another gets empty-cell counts, available merges and tile organization. Others get expectimax search results, learned values from a pretrained n-tuple model, or both.
Neither specialist tells Jev which move to make. They provide measurements for every outcome, and Jev makes the final choice. The numbers can still make one option look better than another. I want to see how much those different inputs change the same classifier’s decisions.
How each bot chooses
Every Jev version uses Jev 1.13.0 without project-specific training or fine-tuning. Only its inputs change.
| Bot | Information used | Who chooses | Search | Learned values | API call |
|---|---|---|---|---|---|
| Jev | Board, rules and anonymous legal outcomes | Jev | No | No | Jev |
| Jev + board analysis | Calculated features and two-step structural summaries | Jev | Bounded enumeration | No | Jev |
| Jev + expectimax | Normalized search values and outcome summaries | Jev | Three player plies | No | Jev |
| Jev + n-tuple | Normalized pretrained values and board features | Jev | No | N-tuple | Jev + hosted native if configured |
| Jev + both experts | Separate search summaries and learned values | Jev | Three player plies | N-tuple | Jev + hosted native if configured |
| Expectimax | Board and fixed evaluation function | Search algorithm | Three player plies | No | No |
| N-tuple | Board and pretrained pattern tables | Greedy reward + afterstate value | One-ply evaluation | TD learning | Local: no; hosted: native service |
What Jev sees, and what we record
Every Jev version sees the current board and each legal outcome before a new tile appears. Board analysis adds empty space, possible merges, tile ordering, corner stability and mobility. It also measures how possible random spawns affect those features. Expectimax adds estimates from a short search; n-tuple adds learned board values. These are estimates of an outcome’s usefulness, not instructions to pick it.
Inspect shows the exact information sent for a move, Jev’s choice probabilities and which specialists agreed. Probabilities describe its preference among the options, not its chance of winning. We also record score, largest tile, moves, preparation time, request time, API attempts and tokens. Those measurements describe the game and the work needed to run it; they are not extra hints sent to Jev.
What we observed
Calculated board information helped
Jev did better when code calculated useful board properties and left the choice to it. In a snapshot of three earlier matched seeds at move 500, Feature Jev averaged 7,333.3 points, slightly above expectimax’s 7,297.3. Search-assisted Jev averaged 7,988. More expert information did not establish a general advantage in the arbitration tests.
These are legacy versions and a post-hoc 500-move snapshot, not complete-game rankings or results for the current bots. Scores and source hashes.
N-tuple led this five-seed comparison
The pretrained n-tuple bot won 5/5 matched games. Its mean score was 222,849.6, versus 45,553.6 for this expectimax implementation.
Arbitration did not add a demonstrated benefit
I also tried asking Jev to settle disagreements between the two specialists. Those tests did not show an advantage over sticking with one specialist. I used only ten states and four short rollouts per move, which was too little to confidently label any of those comparisons.
Final scores · five matched seeds per bot · descriptive results
View chart values
| Observation | Expectimax | N-tuple |
|---|---|---|
| Seed 1 | 37,288 | 150,852 |
| Seed 2 | 37,900 | 477,420 |
| Seed 3 | 15,116 | 177,436 |
| Seed 4 | 56,788 | 132,924 |
| Seed 5 | 80,676 | 175,616 |
Both bots received the same tile-value and shuffled cell-priority streams. Actual spawn cells can differ after their moves change board occupancy.
What happens during one Jev move
Shuffle labels
Candidates receive anonymous labels. Direction names are hidden.
Add information
Each Jev version receives only its documented features or expert values.
Request a choice
One Jev request returns a choice and probabilities over candidates.
Validate and map
Code checks the label and maps it back to a legal direction.
Move and spawn
Apply the move, score it and use the deterministic seeded spawn stream.
Jev sees no direction names, specialist recommendation or actual future spawn. Numeric expert values can still reveal relative preferences. Specialist agreement audits run asynchronously after the move.
Decision time
Each Jev version makes one API request per move, but the complete decision also includes preparing its inputs.
In one warm diagnostic, plain Jev took 656 ms, board analysis 999 ms, and both experts 711 ms. These are single samples, not benchmark averages or isolated inference times.
Plain Jev 656 ms
Local preparation: 2.43 ms
Jev HTTP wait: 583.06 ms
Parsing: 0.80 ms
Other / unisolated overhead: 69.29 ms
Local preparationNative model workJev HTTP waitParsingOther / unisolated overhead
Jev with board analysis 999 ms
Local preparation: 801.93 ms
Jev HTTP wait: 176.18 ms
Parsing: 0.44 ms
Other / unisolated overhead: 20.13 ms
Local preparationNative model workJev HTTP waitParsingOther / unisolated overhead
Jev with both experts 711 ms
Local preparation: 117.42 ms
Native model work: 171.35 ms
Jev HTTP wait: 402.66 ms
Parsing: 0.23 ms
Other / unisolated overhead: 19.34 ms
Local preparationNative model workJev HTTP waitParsingOther / unisolated overhead
| Input version | Features + formatting | Expectimax | Native queue¹ | Native transport¹ | Jev HTTP wait | Body read² | Total |
|---|---|---|---|---|---|---|---|
| Board and rules | 2.0 | 0.0 | 0.0 | 0.0 | 583.1 | 0.80 | 656 |
| Board analysis | 801.5 | 0.0 | 0.0 | 0.0 | 176.2 | 0.44 | 999 |
| Both experts | 2.0 | 114.8 | 19.0 | 152.3 | 402.7 | 0.23 | 711 |
Board analysis spent about 801 ms on two-step structural features. Expectimax evidence took about 115 ms in the both-experts sample. Native n-tuple computation took 0.009 ms, while its queue and transport took about 171 ms. Native compute is not hosted response time.
More supplied information did not always produce a slower decision. The largest delay came from calculating two-step board features, not from the number of Jev questions.
¹ Native queue and transport are upper-bound residuals. ² Body read was measured; JSON parsing was not isolated. The bar leaves other time in overhead. Workers were warmed first. Browser transport, deferred audit and UI delay are excluded from these saved totals. Normal mode’s configured delay occurs between decisions. Live Inspect labels each measurement separately. Lower latency does not imply better gameplay.
Limitations and sources
These are small tests, and random spawns change how games turn out. A high Jev probability does not mean a good move or a likely win. I still need to test the current versions across a fixed set of seeds. When n-tuple runs on a hosted server, its displayed time also includes the network request and sometimes waking the server. The verified native encoding supports tiles up to 32,768. If any legal outcome would exceed that, n-tuple-dependent bots stop with an explicit error; they never switch to another bot.
- TypeSafe Jev · classifier API
- TDL2048+ by Hung Guei · MIT license · checkpoint provenance
- 2048-ai by Robert Xiao and contributors · adapted expectimax · MIT license
Development notes and saved results
Legacy direction-based Jev, strategy instructions, the fixed heuristic, uncertainty gates, tail-risk tests and both arbitration studies remain in the saved artifacts. They are distinct experiments, not results for the current bots. Download the recorded results and original artifact hashes.
The native checkpoint was validated at commit a99f620aec0d30a75943a4c9646743f1f53b0197. This project adds Jev requests, comparison orchestration and UI; upstream repositories do not contain that integration.