How this arena works — a walkthrough
This page is the guided tour. It assumes no background in forecasting, statistics, or machine learning, and builds up to the point where the Findings and Data pages read as arguments rather than dashboards. If you only want the formulas, the methodology page is the terse version.
Contents
- 01The problem with benchmarks
- 02The pipeline, end to end
- 03What each forecaster is allowed to see
- 04But the models' training data is old
- 05Scoring: what a Brier score actually measures
- 06Calibration vs. being right
- 07Why the ensemble is the real experiment
- 08Log-odds, and why the blend lives there
- 09How to read the results honestly
Part 1
The problem with benchmarks
Why measure a language model against a betting market instead of a test set?
Almost every well-known way of scoring a language model is a fixed set of questions with fixed answers — MMLU, HumanEval, GSM8K. They share a structural weakness: once a benchmark exists on the public internet, it eventually gets scraped into the next model's training data. After that, a high score is ambiguous. Did the model reason its way there, or did it remember the answer key? You cannot tell from the score alone, and the ambiguity gets worse every year.
A question about next month has no answer key. Nobody knows whether a ceasefire will hold or a bill will pass, so there is nothing to memorize. To do well, a forecaster has to actually combine what it knows about how the world usually works with what it can find out about this particular situation — and then commit to a number.
Prediction markets give us those questions with two useful properties attached. They resolve unambiguously against a public rule, and they come with a price, which is itself a forecast made by people with money at stake. That price is our benchmark: not a leaderboard of models against each other, but a standing bet against the crowd.
A note on what "beating the market" would mean
It would be a surprising result, and you should be suspicious of anyone who claims it casually. Polymarket prices are set by people who lose real money when they are wrong. The honest question this project asks is narrower and much more interesting: does a $0.001 language model call know anything the price has not already absorbed — even a little, even if the model on its own is worse?
Part 2
The pipeline, end to end
What actually happens between a Polymarket question and a number on the leaderboard?
Twice a day a scheduled job picks twelve markets and asks every forecaster for a probability. Most of the engineering is in the filtering: which markets are worth asking about at all.
The selection gate is doing real work. Sports and daily-weather markets are excluded on purpose — not because they are uninteresting, but because a same-day game resolves in hours and a web search just fetches the score. That is lookup, not forecasting. The horizon window (one to forty-five days) is the same idea from both ends: at least a day out so the outcome is genuinely undetermined, and inside six weeks so the forecast-to-score feedback loop actually closes while the project is running.
The price filter matters too. A market trading at 97¢ tells you almost nothing about a forecaster — everyone says 97%, everyone scores well, and the comparison is noise. Keeping to the 5¢–95¢ band means every market in the sample still has something to be right or wrong about.
Where this lives in the code
src/lib/polymarket.ts— the tag exclusions and the selection gatesrc/lib/prediction.ts— round assembly, concurrency, budget capsrc/lib/openrouter.ts— the prompt and the per-model API callsrc/lib/settlement.ts— resolution checking and scoring
?Why cap the round at three markets per category?— click to reveal
Because a single hot news cycle can spawn a dozen related markets, and forecasts on related markets are not independent observations. If ten of twelve markets in a round are about the same election, the round measures one correlated bet rather than twelve. That would inflate any apparent skill (or lack of it) and quietly break the sample-size arithmetic on every downstream chart.
Part 3
What each forecaster is allowed to see
Why go to the trouble of hiding the market price from the models?
Nine rows get written for every market: six model forecasts, plus three computed ones. The design decision that everything else depends on is which of them can see the price.
If a model could see that a market trades at 62¢, the cheapest way to get a good score would be to answer "62%" and stop thinking. It would look well-calibrated. The ensemble of six such models would look well-calibrated too — and would have measured nothing except the models' ability to read a number off a page. Blinding them is what makes the six forecasts independent of the crowd, and independence is the precondition for the entire ensemble argument in Part 7.
The three computed forecasters are not models and cost nothing to run:
- Ensemble — the plain average of whichever model forecasts came back valid. No weighting, no tuning.
- Market × Models (hybrid) — the one forecaster that does see the price. It starts from the price and nudges it 20% of the way toward the model consensus. This is the live test of "do the models add anything?"
- The Crowd — the price itself, scored exactly like any other forecaster. This is the bar.
And in practice, the blinding leaks
The prompt withholds the price. The web search does not. Exa indexes Polymarket and the sites that quote it, so a model can read the number it was never told — and measured against their own stated reasoning, most forecasts show signs of having done exactly that. Within the same market, the forecasts that cite market odds sit measurably closer to the price than the ones that don't.
Keep that in mind for Part 7. The ensemble argument needs errors that are independent, and forecasts partly anchored to a shared price are correlated by construction. The Data page measures the size of the problem and what it does to the results.
Failures are data, not noise to be cleaned
When a model times out, returns malformed JSON, or errors, the row is written with ok = 0 and the reason, and it is excluded from scoring. It is never quietly replaced with 0.5. A default value would flatter unreliable models by handing them a free coin-flip forecast on every question they failed — and 0.5 happens to be a decent score, which is exactly what makes the shortcut so tempting and so wrong.
Part 4
But the models' training data is old
A model frozen in the past is being asked about next month. How is that not nonsense?
This is the first objection almost everyone raises, and it is a good one. The answer has two halves, and keeping them separate is most of the insight.
Pretraining supplies the prior. A model that learned nothing after its cutoff still knows how the world tends to behave: how often announced mergers actually close, how central banks respond to inflation prints, how long a coalition government survives a scandal, how frequently a ceasefire announced in week one is still holding in week four. That is base-rate knowledge, and it does not go stale the way facts do. The system prompt asks for it explicitly — "think in terms of base rates, then adjust for specific evidence."
Retrieval supplies the current state. Every call runs a web search first and the results land in the context window before the model answers. The weights are frozen; the context is not. So the model is not remembering the answer, it is reading today's news and applying an old, still-valid sense of how such stories usually end.
Where this genuinely breaks down is worth naming, because it is a real limitation and not a hypothetical one. With only four search results, a model can carry a stale premise — who holds an office, whether a company still exists independently — straight into its forecast, and nothing in the response will flag that it did. And if search silently returns nothing, the model answers from memory alone without saying so.
This happened here, and it is why the code looks the way it does
One provider's native search integration returned zero results on a specific model while still reporting success. Those forecasts were being made blind from training data and looked identical to well-grounded ones. The fix was to force the same Exa search engine for every model, which also equalizes cost and means the six forecasters differ only in reasoning — not in the quality of their search backend.
?If search does the heavy lifting, are we really testing the models at all?— click to reveal
Yes — but we are testing judgment, not recall. Every model gets the same four search results and the same question, so the differences on the leaderboard come entirely from what each one does with that identical evidence: which factors it weighs, how far it moves from its prior, and how confident it is willing to be. That is precisely the skill a forecaster is supposed to have, and it is the one thing a memorized answer key cannot supply.
Part 5
Scoring: what a Brier score actually measures
How do you grade a probability when the event only happens once?
You cannot grade a single probability. "30% chance of rain" is not wrong when it rains. But you can grade a collection of probabilities, and the tool for it is embarrassingly simple: take the distance between what you said and what happened, and square it.
Squaring is the whole trick. It makes the rule proper — a piece of jargon with a concrete meaning: your expected score is best when you report your honest belief. There is no way to game a Brier score by shading your answers. If you truly think something is 70% likely, saying 85% to look decisive raises your expected penalty. Saying 55% to play it safe does too.
Two reference points make the numbers legible. A forecaster that always says 50% scores 0.25 — that is the "knows nothing" line. A perfect oracle scores 0. Real forecasters on genuinely uncertain questions land somewhere in between, and the differences that matter are small: a gap of 0.01 between two forecasters is a meaningful edge, not a rounding error.
The arena also tracks log loss, which is the same idea with a harsher temperament. It punishes confident mistakes far more severely — being certain and wrong costs infinitely much, which is why probabilities are clamped away from exactly 0 and 1 before scoring. And the headline number on the leaderboard is neither of these but a difference: skill vs. crowd = the crowd's Brier minus yours, on the same markets. Positive means you beat the market. Comparing on the identical resolved set is what makes it a fair fight; a forecaster that skipped the hard questions would otherwise look brilliant.
Where this lives in the code
src/lib/scoring.ts— Brier decomposition, ECE, skill vs. crowd, Kelly P&Lsrc/lib/settlement.ts— where each forecast's brier and log_loss are written
?Why is 0.25 the score for always saying 50%?— click to reveal
Because the error is 0.5 every single time — whether the event happens or not — and 0.5 squared is 0.25. It is the same for any outcome, which is what makes it such a clean baseline: a forecaster scoring worse than 0.25 is contributing less than silence.
Part 6
Calibration vs. being right
A forecaster can be well-calibrated and still useless. How?
Calibration asks a narrow question: when you say 30%, does it happen about 30% of the time? Sort every forecast into confidence buckets, compare the stated probability to the realized rate, and plot it.
The trap is that calibration alone is cheap. Predict the base rate for everything and you are perfectly calibrated and completely uninformative. What you also need is resolution — the willingness to separate the likely from the unlikely and be right about which is which. The Brier score contains both, and the decomposition makes it explicit: Brier = reliability − resolution + uncertainty. Reliability is your distance from the diagonal above (lower is better), resolution is how much your forecasts actually spread outcomes apart (higher is better), and uncertainty is the irreducible difficulty of the questions themselves, identical for everyone.
That last term is why you should never compare Brier scores across different question sets. A forecaster working on easy questions posts better numbers than a better forecaster working on hard ones. It is also why every comparison in this project is restricted to a shared set of resolved markets.
Part 7
Why the ensemble is the real experiment
Six mediocre forecasters average to something better than any of them. When does that actually work?
This is the claim the project is built to test, and it is not obvious. Averaging six forecasts helps for a specific reason: each forecast is roughly signal plus error, and when you average, the signal reinforces while the errors partly cancel — but only to the extent the errors are independent.
That is why the roster is deliberately assembled from five companies across three regions rather than from six variants of the strongest model. Models trained on similar data with similar methods make similar mistakes, and correlated mistakes survive averaging intact. The error-correlation heatmap measures exactly this, and the ensemble-size curve on the same page shows how much each additional model is actually buying.
It also predicts a specific failure, which is what the data shows: all six models share a skepticism bias, systematically under-predicting YES. That bias is in the shared column, not the independent one, so the ensemble inherits it undiminished. No amount of averaging fixes a prior that everyone holds.
?If the errors were perfectly correlated, what would the ensemble's Brier score be?— click to reveal
Identical to the average model's. Averaging six copies of the same opinion gives you the same opinion back. The gap between the ensemble's score and the average individual score is, in effect, a direct measurement of how much genuine diversity the roster has.
Part 8
Log-odds, and why the blend lives there
Why does the hybrid forecaster average logits instead of just averaging probabilities?
Probabilities are a bad scale for arithmetic on beliefs, because equal steps do not carry equal meaning near the ends.
Log-odds fixes this. In that space, evidence adds: Bayes' rule becomes "prior log-odds plus the weight of the evidence." It also has no boundary, so averaging cannot pull results toward the middle the way probability-space averaging does — which matters because a mean of raw probabilities is systematically less extreme than its inputs, making the pool under-confident by construction.
The hybrid forecaster uses this to answer the project's actual question. It takes the market price as its anchor, converts both the price and the model consensus to log-odds, and blends them 80/20. The weight is not arbitrary — it comes from sweeping every weight from 0 to 1 across the settled history and reading off where the curve bottoms out. If the models carried no information the market lacked, the best weight would be 1.0 (all market) and the hybrid would be pointless.
The distinction that makes this honest
That sweep is a backtest: the weight was chosen with the outcomes already known, so of course it looks good. The hybrid forecaster on the leaderboard is the out-of-sample version — the same fixed 0.8 rule, applied going forward to markets that had not resolved when the rule was set. Those two numbers are reported separately on the Findings page, and only the second one is evidence.
Part 9
How to read the results honestly
What would make you stop believing any of this?
A tutorial that ends with the results is only half of one. The harder skill is knowing which numbers deserve weight, so here is the short list of things that should make you discount a finding on these pages.
- Small n. Brier differences of a few thousandths over a couple hundred markets are well inside noise. Every chart here reports its sample size; check it before you believe the ordering. The Data page puts confidence intervals on the headline gaps for exactly this reason.
- In-sample tuning. Any rule chosen by looking at outcomes will look good on those outcomes. Only the forward-looking version counts.
- Regime dependence. Forecast difficulty swings hard with the news cycle. A finding that holds in one half of the data and reverses in the other is a description of that period, not a fact about language models.
- Survivorship in the market set. These are liquid, mid-priced, non-sports markets on one platform. Nothing here generalizes automatically to illiquid markets, to near-certain ones, or to questions nobody is trading.
- Paper P&L. It ignores fees, slippage, and the fact that your order would move the price. It is a sanity check on the skill numbers, never a trading result.
There is a sixth item that deserves its own line, because it is the one that catches people who have already learned the other five: a significant result can be an artifact of your own plumbing. The arena ran a standard test for whether the models lead the market — do prices move toward a model that disagrees with them? — and got a clean, significant yes. It was false. The market prices in our database are only refreshed for markets that still rank highly by volume, so most forecasts are made against a slightly stale snapshot, and a model with live web search "predicts" the moment that snapshot catches up. Split the sample by whether the price was actually fresh and the entire effect evaporates. The write-up is on the Data page. No amount of statistical care would have caught that — only knowing how the data was produced.
The project has a second worked example of the same discipline: a learned bias correction that looked excellent in-sample made forecasts worse when fit on the earlier half of the data and tested on the later half. It was dropped, and the reason it was dropped is written up on the Findings page. That is the template — a result that fails the honest test is still a result.
Where to go next
The Data — a tour of everything the arena has collected: what it costs, what it forecasts, which topics defeat it, and how much of the headline edge survives a confidence interval.
Findings — the four claims the settled data supports, recomputed live. The Lesson — the ensemble argument in three charts. Methodology — every formula, stated once.